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

[Paul B Mahol]

On Mon, Sep 6, 2021 at 7:23 AM 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.
>
> Using .activate helped to solve another issue I had, so thanks again
> for the hint.
>
> Besides recommended usage patterns - would you disagree that this
> patch is logically correct?
>

Yes. Because .activate fixes numerous issues.
I see that only scale2ref is still using old way with multiple inputs. It
probably should be fixed,
and after that assert should be added in this file so new filters do not
expose same limitations and mistakes of the past.


> Regards,
> softworkz
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>