[FFmpeg-devel] [PATCH] avfilter/avfilter: Fix hardcoded input index

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Paul B Mahol
> Sent: Sunday, 5 September 2021 22:06
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix hardcoded
> input index
> 
> On Sun, Sep 5, 2021 at 9:56 PM Soft Works <softworkz at hotmail.com>
> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Paul B Mahol
> > > Sent: Sunday, 5 September 2021 21:51
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix
> hardcoded
> > > input index
> > >
> > > On Sun, Sep 5, 2021 at 9:44 PM Soft Works <softworkz at hotmail.com>
> > > wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On
> Behalf Of
> > > > > Soft Works
> > > > > Sent: Sunday, 5 September 2021 16:59
> > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > devel at ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix
> > > hardcoded
> > > > > input index
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On
> Behalf
> > > Of
> > > > > > Paul B Mahol
> > > > > > Sent: Sunday, 5 September 2021 11:01
> > > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > > > devel at 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