> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Sunday, 5 September 2021 22:06
> To: FFmpeg development discussions and patches <ffmpeg-
> de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix hardcoded
> input index
>
> On Sun, Sep 5, 2021 at 9:56 PM Soft Works <softwo...@hotmail.com>
> wrote:
>
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
> > > Paul B Mahol
> > > Sent: Sunday, 5 September 2021 21:51
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix
> hardcoded
> > > input index
> > >
> > > On Sun, Sep 5, 2021 at 9:44 PM Soft Works <softwo...@hotmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On
> Behalf Of
> > > > > Soft Works
> > > > > Sent: Sunday, 5 September 2021 16:59
> > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix
> > > hardcoded
> > > > > input index
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On
> Behalf
> > > Of
> > > > > > Paul B Mahol
> > > > > > Sent: Sunday, 5 September 2021 11:01
> > > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > > de...@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix
> > > > > hardcoded
> > > > > > input index
> > > > > >
> > > > > > With what filters this happens?
> > > > > >
> > > > > > IIUC this is forbidden and such filters should use
> .activate
> > > > > instead.
> > > > >
> > > > > The hardcoded [0] is wrong, no matter what the use case is.
> > > > >
> > > > > But to answer your question: It's about a new
> overlay_textsubs
> > > filter
> > > > > where framesync cannot be used and incoming frames (video on
> > > input0,
> > > > > subs on input1) need to be processed independently: the
> subtitle
> > > > > events
> > > > > are fed into the ass library (you could practically feed all
> > > events
> > > > > in advance) while the overlay image generation is done based
> on a
> > > > > given
> > > > > time code.
> > > > > This works fine by having a separate .filter_frame function
> for
> > > each
> > > > > input (after applying this patch).
> > > >
> > > > BTW
> > > >
> > > > > > IIUC this is forbidden and such filters should use
> .activate
> > > >
> > > > The scale2ref filter is set up in the same way (two
> .filter_frame
> > > > functions, no .activate, no framesync), probably because - like
> in
> > > > my case - the filter must not sync frames across inputs.
> > > >
> > >
> > > FYI .activate does not sync frames across inputs.
> >
> > Thanks for the information, I wasn't aware of that; so far I had
> always
> > seen it used in combination with framesync, do you know an example
> > where it's being used without framesync?
> >
>
> Numerous examples across code base, grep for .activate.
Grep (lol..) - I asked because I thought you might
have an example in mind that would be similar to the discussed case.
Nevermind, I'll find one..
But if you don't mind, could you please elaborate on why .activate
would be a preferred approach when input frame processing is
meant to be totally independent between two inputs?`
Thanks,
softworkz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
