[FFmpeg-trac] #10368(undetermined:new): Incorrect tbr importing h264 (default tbr?)

[FFmpeg]

#10368: Incorrect tbr importing h264 (default tbr?)
-------------------------------------+-------------------------------------
             Reporter:  slydiman     |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:
  undetermined                       |  unspecified
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Here is the h264 stream from MXF recorded by the camera Canon C300
 http://slydiman.me/ffmpeg/canon_c300_mxf_h264_25fps_wrong_tbr.h264

 Old ffmpeg 20200805 (libavcodec 58.101.101, libavformat 58.51.101)
 reports:
 {{{25 fps, 25 tbr, 1200k tbn, 50 tbc}}}

 {{{ffmpeg -i canon_c300_mxf_h264_25fps_wrong_tbr.h264 -c copy
 output.mp4}}}
 produces a correct file with 25 fps.

 ffmpeg 20230507 (libavcodec 60.10.100, libavformat 60.5.100) reports:
 {{{25 fps, 600k tbr, 1200l tbn}}}

 {{{ffmpeg -i canon_c300_mxf_h264_25fps_wrong_tbr.h264 -c copy
 output.mp4}}}
 produces an incorrect file with 239.998 fps.

 I agree that timing_info_present_flag=0 in SPS and it is hard to detect
 tbr in this case. But the reported fps is still 25 and it is correct. How
 was it detected? I see tbr=600k and it is totally wrong. Yes, it can be
 fixed adding -r 25. Note it is very useful when ffmpeg can detect the
 correct tbr itself (probably when timing_info_present_flag=1) without -r
 and uses 25 by default when timing_info_present_flag=0. 600k is ugly
 value. So the behavior of an old ffmpeg is much better. Hope it can be
 fixed or make the default tbr=25 back at least. Thanks.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10368>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker