[FFmpeg-trac] #9814(undetermined:new): time_scale / num_units_in_tick is not infinite precision

FFmpeg trac at avcodec.org
Sun Jun 19 02:28:26 EEST 2022


#9814: time_scale / num_units_in_tick is not infinite precision
-------------------------------------+-------------------------------------
             Reporter:  Balling      |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:  git-
  undetermined                       |  master
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  1
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 Summary of the bug: as you can read here https://www.ffmpeg.org/ffmpeg-
 bitstream-filters.html#h264_005fmetadata H.264 has time_scale /
 num_units_in_tick in the VUI parameters. That is how one writes frame rate
 (besides timing SEI that is) in Annex B files. The problem is that (not
 touching very broken mkv here with only ms precision and only PTS in the
 form of duration, no DTS) when you go to mp4 you are supposed to make it
 CFR and use the nice tbn. But even if you will use vfrdet on annex b file
 it will not be CFR. This sample in fact has even fixed_frame_rate_flag
 set! So this is a bug, ffplay also cannot even seek in this annex b file!
 Sample is here: https://github.com/wang-bin/QtAV/files/1132086/example.zip

 How to reproduce:
 {{{
 ffmpeg -i  example.h264 -vf vfrdet -f null NUL
 ffmpeg version N-107098-g4d45f5acbd-20220613 Copyright (c) 2000-2022 the
 FFmpeg developers
   built with gcc 11.2.0 (crosstool-NG 1.24.0.533_681aaef)
   configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static
 --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64
 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug
 --enable-shared --disable-static --disable-w32threads --enable-pthreads
 --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype
 --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig
 --enable-libvorbis --enable-opencl --disable-libpulse --enable-libvmaf
 --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable-
 libaribb24 --enable-avisynth --enable-libdav1d --enable-libdavs2
 --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r
 --enable-libgme --enable-libass --enable-libbluray --enable-libjxl
 --enable-libmp3lame --enable-libopus --enable-librist --enable-libtheora
 --enable-libvpx --enable-libwebp --enable-lv2 --enable-libmfx --enable-
 libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264
 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-
 librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable-
 libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d
 --disable-libdrm --disable-vaapi --enable-libvidstab --enable-vulkan
 --enable-libshaderc --enable-libplacebo --enable-libx264 --enable-libx265
 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi
 --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-
 ldflags=-pthread --extra-ldexeflags= --extra-libs=-lgomp --extra-
 version=20220613
   libavutil      57. 26.100 / 57. 26.100
   libavcodec     59. 33.100 / 59. 33.100
   libavformat    59. 24.100 / 59. 24.100
   libavdevice    59.  6.100 / 59.  6.100
   libavfilter     8. 40.100 /  8. 40.100
   libswscale      6.  6.100 /  6.  6.100
   libswresample   4.  6.100 /  4.  6.100
   libpostproc    56.  5.100 / 56.  5.100
 Input #0, h264, from 'example.h264':
   Duration: N/A, bitrate: N/A
   Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive),
 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn
 Stream mapping:
   Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
 Press [q] to stop, [?] for help
 Output #0, null, to 'NUL':
   Metadata:
     encoder         : Lavf59.24.100
   Stream #0:0: Video: wrapped_avframe, yuv420p(tv, bt709, progressive),
 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn
     Metadata:
       encoder         : Lavc59.33.100 wrapped_avframe
 frame= 1082 fps=912 q=-0.0 Lsize=N/A time=00:00:36.10 bitrate=N/A
 speed=30.4x
 video:499kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
 muxing overhead: unknown
 [Parsed_vfrdet_0 @ 000001a582b7f900] VFR:0.799260 (864/217) min: 40040
 max: 40041 avg: 40040
 }}}

 What it should be as if -r 29.97002997 was before input.

 In fact Mediainfo can see all of it (both the timetamps of  mp4 and
 time_scale / num_units_in_tick) in -c copy to mp4 with -r 29.97002997 and
 without.

 There were quite a lot of simliar bugs in that regard, but Annex B to mp4
 is a clear case and is a clear bug.

 Patches should be submitted to the ffmpeg-devel mailing list and not this
 bug tracker.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9814>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list