[FFmpeg-devel] [PATCH 2/2] fftools/ffmpeg_filter: Fix audio_drift_threshold check

[Anton Khirnov]

Quoting Michael Niedermayer (2022-07-06 00:36:25)
> On Tue, Jul 05, 2022 at 06:58:28PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2022-07-02 14:56:50)
> > > On Sat, Jul 02, 2022 at 10:38:26AM +0200, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2022-07-01 21:53:00)
> > > > > On Thu, Jun 30, 2022 at 10:55:46AM +0200, Anton Khirnov wrote:
> > > > > > Variant 2 is less bad, but the whole check seems hacky to me, since it
> > > > > > seems to make assumptions about swr defaults
> > > > > > 
> > > > > > Won't setting this unconditionally have the same effect?
> > > > > 
> > > > > it has the same effect but its not so nice to the user to recommand extra
> > > > > arguments which make no difference
> > > > 
> > > > Sorry, I don't follow. What is recommending any arguments to the user
> > > > here?
> > > 
> > > i meant this thing here:
> > > ./ffmpeg   -i matrixbench_mpeg2.mpg -async 1 -f null -  2>&1 | grep async
> > > 
> > > -async is forwarded to lavfi similarly to -af aresample=async=1:min_hard_comp=0.100000:first_pts=0.
> > > 
> > > vs.
> > > 
> > > -async is forwarded to lavfi similarly to -af aresample=async=1:first_pts=0.
> > 
> > I don't see a problem - why would the user care how it is forwarded?
> 
> The user may want to perform the equivalent operation inside a filter chain/graph
> or with a tool different from ffmpeg or even via the API
> its really a very minor thing if these defaults are displayed too, it just
> feels a bit cleaner to skip them

Then the correct thing to do is retrieve the swr default value via the
AVOption API. Though IMO it's extra complexity for marginal gain.

I also wonder if this option should exist at all, given that it does
nothing but set a swr option. It is also global, so you can't have
different values for different streams.

-- 
Anton Khirnov