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

Soft Works softworkz at hotmail.com
Mon Sep 6 10:21:03 EEST 2021



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Monday, 6 September 2021 08:53
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: Fix hardcoded
> input index
> 
> Paul B Mahol (12021-09-06):
> > 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.
> 
> Thank you for explaining this.
> 
> A filter with several inputs but no synchronization between them is a
> nonsense. If there is no synchronization, it should be two separate
> filters.

I'm not quite sure about this. When we look at the scale2ref filter:

It has two inputs and two outputs and allows passing through two 
independent video streams:

- in0 >> out0  (main)
- in1 >> out1  (ref)

Both streams could have different frame rates. Once you would start
synchronizing (like with framesync), how would it still be possible to 
pass-through both streams at different rates?

Of course there will be a random lag between those streams without 
synchronization, but not arbitrarily large, which might be fine for 
certain use cases - like scale2ref filter.


> It is possible to synchronize without activate, it was done before
> activate; but it is harder.
> 
> Anyway, the code that is changed by this patch is the fall-back code
> for
> filters without a request_frame() callback, and this was only ever
> allowed if there is a single input.

OK understood. Thanks.

As Paul suggested, it might be reasonable to add an assert to make 
it clear that this isn't a supported way.

softworkz


More information about the ffmpeg-devel mailing list