GNOME Bugzilla – Bug 769041
qtmux: Downscaling time value loses precision
Last modified: 2016-11-01 18:11:47 UTC
Created attachment 331889 [details] [review] [PATCH] Remove down scaling of time value, since it loses precision In qtmux, the frame rate nominator is divided by 10 if it does not fit into a range from 1000 to 10000 until it fits. But this division is wrong, as it throws away precision in time base representation. For example, a frame rate of 30000/1001 (very common NTSC frame rate) cannot be represented by a smaller time base. Currently, in this case the frame rate nominator would be scaled to 3000, and a wrong time base is thus written to the qt file. The attached patch removes time value division. The resulting files where tested in Final Cut X, which now detects frame rate correctly.
Instead of that, maybe we should also detect common rates directly and try them? We do that elsewhere too IIRC. That is: checking for the XX000/1001 framerates.
Created attachment 338109 [details] [review] qtmux: Be more clever with the default video track timescale Use the number of milliframes per second for integral and drop-frame framerates, as suggested by the QT file format specification and other places. We already did that for integral framerates before, but not for drop-frame framerates. This now keeps precision better. For all other framerates, check if it's close to a well-known framerate and use that instead.
Created attachment 338111 [details] [review] qtmux: Use a better default value for the movie header timescale Take the maximum video timescale, or if no video track is present the previous value of 1800.
Review of attachment 338109 [details] [review]: Looks good, I also like this alternative better.
Attachment 338109 [details] pushed as 727fa1c - qtmux: Be more clever with the default video track timescale Attachment 338111 [details] pushed as e0aec31 - qtmux: Use a better default value for the movie header timescale