Hi, 2011/5/13 Aℓex Converse <[email protected]>: > On Fri, May 13, 2011 at 1:32 PM, Ronald S. Bultje <[email protected]> wrote: >> Hi, >> >> 2011/5/12 Aℓex Converse <[email protected]>: >>> 2011/5/9 Aℓex Converse <[email protected]>: >>>> The attached patch adds a command line option "-fpsprobesize" to >>>> specify the number of frames used in fps estimation. >>>> >>>> Currently some 29.97 fps FLV files are detected as 59.92 fps. >>>> >>>> Feel free to play with this spreadsheet to understand the issue: >>>> >>>> https://spreadsheets.google.com/ccc?key=0Ah8DDuo3xisxdDZOQWRWc3ZjLV9zdzZnM0hvVkZ2enc&hl=en&authkey=CKCX3v4D >>>> >>>> The "Lag" parameter adjusts where the file starts. When score is >>>> negative 59.92 fps is detected. Look how just playing with lag effects >>>> detection when only a few frames are used. >>>> >>> >>> Ping? >>> >>> FWIW lag=1 seems to be our most common case as we ignore the first >>> frame's duration. >> [..] >>> @@ -2217,19 +2217,12 @@ int av_find_stream_info(AVFormatContext *ic) >>> >>> /* check if one codec still needs to be handled */ >>> for(i=0;i<ic->nb_streams;i++) { >>> - int fps_analyze_framecount = 20; >>> - >>> st = ic->streams[i]; >>> if (!has_codec_parameters(st->codec)) >>> break; >>> - /* if the timebase is coarse (like the usual millisecond >>> precision >>> - of mkv), we need to analyze more frames to reliably arrive >>> at >>> - the correct fps */ >>> - if (av_q2d(st->time_base) > 0.0005) >>> - fps_analyze_framecount *= 2; >>> /* variable fps and no guess at the real fps */ >>> if( tb_unreliable(st->codec) && !(st->r_frame_rate.num && >>> st->avg_frame_rate.num) >>> - && st->info->duration_count < fps_analyze_framecount >>> + && st->info->duration_count < ic->fpsprobesize >>> && st->codec->codec_type == AVMEDIA_TYPE_VIDEO) >>> break; >>> if(st->parser && st->parser->parser->split && >>> !st->codec->extradata) >> >> I'm not sure if removing the *2 workaround for mkv is a good idea >> here, especially not if we didn't explicitely specify a value on the >> commandline. It'll basically break mkv fps detection again (at least >> 29.97) by default. > > MKV/FLV detection for 29.97 is still broken. It just happens to work > better now with a handful of files (and worse for many others. I have > many files that were being detected at 29.97 fps that are now being > detected as 59.91 fps). The spreadsheet can tell you more.
Ugh... This is a big problem. The more reason why we need a proper testsuite for this kind of stuff. So now what do we do? I can just see the insults flying around if we break this again. Is there some way to workaround it?... Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
