[FFmpeg-devel] [PATCH] Fix loss of precision for silencedetect on large files

Allan Cady allancady at yahoo.com
Fri Mar 29 13:47:25 EET 2019


Gaaaack! Sorry guys about the formatting. Yahoo Mail sucks for anything slightly out of the norm...

Let's try this again... if it doesn't work better, not sure what to do:
On Wednesday, March 27, 2019, 11:19:23 AM PDT, Michael Niedermayer <michael at niedermayer.cc> wrote: > this breaks make fate> > also if fate is updated it should be ensured it still checks enough precission> and that it does produce the same results (fate passes) on all relevant> platforms. This change may bring non significant differences into significance> > thanks
OK so I spent some more time familiarizing myself with the code and tests, and it's clear that making the change the way I did would probably break dozens of tests, because the function I changed, av_ts_make_time_string, is referenced (by its convenience macro av_ts2timestr) in many files (I count 21) and dozens of lines of code, in libavfilter, fftools, and libavformat.
As an alternative, I tried making a modified & renamed copy of av_ts_make_time_string/av_ts2timestr, and referencing that copy in af_silencedetect.c, leaving other references to the original function unchanged. In this case, FATE fails just a single test, filter-metadata-silencedetect. I then modified the reference output file (tests/ref/fate/filter-metadata-silencedetect) to match the changed output, and all tests then pass.
In looking at other uses of av_ts2timestr, it's clear av_ts2timestr was intended for general purpose use.
So at this point I could use some guidance from the wizards as to the best way to proceed. Not knowing any of the history or thinking that went into the design, I don't know if it makes the best sense to use the "%.6g" format for all those other timestamps, but I feel strongly that it's a poor choice for silencedetect (and probably other *detect filters), for the reason I explained originally. Is there possibly another way to get the result I want without modifying the code? I can imagine maybe a format specifier as a filter parameter -- is there any precedent for this?
Open to suggestions. Thanks all.
Allan


More information about the ffmpeg-devel mailing list