Hi, 2011/5/13 Aℓex Converse <[email protected]>: > 2011/5/13 Aℓex Converse <[email protected]>: >> On Fri, May 13, 2011 at 1:49 PM, Ronald S. Bultje <[email protected]> wrote: >>> 2011/5/13 Aℓex Converse <[email protected]>: >>>> On Fri, May 13, 2011 at 1:32 PM, Ronald S. Bultje <[email protected]> >>>> wrote: >>>>> 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?... >> >> I can use a default to preserve the current voodoo values. > > Updated to preserve voodoo
I can live with this voodoo version. Unrelated to the patch itself, I wonder if we want to document such options somewhere. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
