[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