[FFmpeg-trac] #1065(undetermined:open): H.264/AVC(BDAV BluRay codec family) incorrect framerate recognition

[FFmpeg]

#1065: H.264/AVC(BDAV BluRay codec family) incorrect framerate recognition
-------------------------------------+-------------------------------------
             Reporter:  L.H.V.F.     |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  h264,        |               Resolution:
  framerate                          |               Blocked By:
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by pross):

 Since August 2012, libav has correctly detected 25fps for the affected
 file (http://www.mediafire.com/?ojp54ym1mkaqkg4).

 Bisecting libav, points to the following patches. While these have been
 applied to FFmpeg, the dts and fps calculation logic does different
 between both libraries.

 ---
 commit aba232cfa9b193604ed98f3fa505378d006b1b3b
 Author: Anton Khirnov <anton at khirnov.net>
 Date:   Tue Jun 26 13:10:01 2012 +0200

     lavf: deprecate r_frame_rate.

     According to its description, it is supposed to be the LCM of all the
     frame durations. The usability of such a thing is vanishingly small,
     especially since we cannot determine it with any amount of
 reliability.
     Therefore get rid of it after the next bump.

     Replace it with the average framerate where it makes sense.

     FATE results for the wtv and xmv demux tests change. In the wtv case
     this is caused by the file being corrupted (or possibly badly cut) and
     containing invalid timestamps. This results in lavf estimating the
     framerate wrong and making up wrong frame durations.
     In the xmv case the file contains pts jumps, so again the estimated
     framerate is far from anything sane and lavf again makes up different
     frame durations.

     In some other tests lavf starts making up frame durations from
 different
     frame.

 commit f66eeff1c8fc5c1b2e5a563cf336865d52329006
 Author: Anton Khirnov <anton at khirnov.net>
 Date:   Fri Jul 27 14:04:07 2012 +0200

     lavf: round estimated average fps to a "standard" fps.

 commit fe1c1198e670242f3cf9e3e1eef27cff77f3ee23
 Author: Anton Khirnov <anton at khirnov.net>
 Date:   Thu Jun 28 15:49:51 2012 +0200

     lavf: use dts difference instead of AVPacket.duration in
 find_stream_info()

     AVPacket.duration is mostly made up and thus completely useless, this
 is
     especially true for video streams.
     Therefore use dts difference for framerate estimation and
     the max_analyze_duration check.

     The asyncts test now needs -analyzeduration, because the default is 5
     seconds and the audio stream in the sample appears at ~10 seconds.

 ---

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/1065#comment:14>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker