Skip to content

qtmux: do not base default timescale on centiframes

Mathieu Duponchelle requested to merge meh/gstreamer:qtmux-no-timescale-precision-loss into main

Instead, preserve the original denominator for well-known framerates (/1, /1001).

This means that no rounding error accumulates, eventually leading to outputting a packet with a different duration.

Some tools such as MediaInfo determine that a stream is variable framerate if any packet has a different duration than the others, and there is no reason I can see for not using the full 4 bytes of resolution that the mp4 timescale offers.

Example problematic pipeline:

videotestsrc num-buffers=5001 ! video/x-raw,framerate=60000/1001,width=320,height=240 ! \
videoconvert ! x264enc bitrate=80000 speed-preset=1 tune=zerolatency ! h264parse ! \
video/x-h264,profile=high-10 ! mp4mux ! filesink location="result2.mp4"

This results in a media file that MediaInfo detects as variable framerate because the 5000th packet has duration 99 instead of 100.

With this patch, the timescale is 60000 and all packets have duration 1001.

Related issue for context: https://bugzilla.gnome.org/show_bug.cgi?id=769041

Merge request reports