[FFmpeg-trac] #9322(undetermined:new): -r flag produces vfr mp4 and drops frames

[FFmpeg]

#9322: -r flag produces vfr mp4 and drops frames
-------------------------------------+-------------------------------------
             Reporter:  oba          |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  git-master   |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by BuccoBruce):

 This has been an issue for as long as I can remember...basic functionality
 that has never worked as intended. Any **100% CFR** H.264 (or H.265)
 elementary stream gets inexplicably muxed as VFR and has its timestamps
 destroyed.

 If you are only dealing with closed-GOP H.264, just use GPAC/mp4box. It
 will handle your raw .h264 streams properly and give you CFR .mp4 files.
 And if you're using something like a standalone x264 binary to create
 these streams, you can also pass `--force-cfr` to output CFR
 SEI/timestamps.

 Unfortunately, ''x265'' has no such option, and mp4box chokes on open-GOP
 .hevc resulting in unplayable (albeit still CFR) files.

 The only "solution" (it is anything but) I have found is to work around
 whatever is making ffmpeg ''think'' that raw CFR H.264/H.265 streams have
 a variable frame rate and "force" it every step of the way...e.g. for
 59.94 (60000/1001) FPS with a 600 frame maximum GOP (10 seconds):
 {{{
 ffmpeg -hide_banner -loglevel error -stats -r 60000/1001 -i
 "somestream.hevc" -i "someaudio.m4a" -map 0:v -map 1:a -c copy -vsync cfr
 -analyzeduration 20000000 -fpsprobesize 600 -avoid_negative_ts
 make_non_negative -c copy -movflags faststart "actuallygoodCFRoutput.mp4"
 }}}
 `-r 60000/1001` has to go **before** the input. `-loglevel error -stats`
 is an absolute necessity here on Windows or the "non-monotonous DTS"
 messages will be **so** numerous, nearly every frame, that it will
 actually slow ffmpeg to a crawl while using `conhost.exe`. If you're using
 Windows Terminal or a different shell it's only a cosmetic inconvenience.
 You'll also still get an erroneous `Duration_FirstFrame             :
 -3ms` too if you check in MediaInfo
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9322#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker