After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769041 - qtmux: Downscaling time value loses precision
qtmux: Downscaling time value loses precision
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.11.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 769048
 
 
Reported: 2016-07-21 15:13 UTC by Georg Lippitsch
Modified: 2016-11-01 18:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[PATCH] Remove down scaling of time value, since it loses precision (867 bytes, patch)
2016-07-21 15:13 UTC, Georg Lippitsch
rejected Details | Review
qtmux: Be more clever with the default video track timescale (2.12 KB, patch)
2016-10-20 17:20 UTC, Sebastian Dröge (slomo)
committed Details | Review
qtmux: Use a better default value for the movie header timescale (2.97 KB, patch)
2016-10-20 17:42 UTC, Sebastian Dröge (slomo)
committed Details | Review

Description Georg Lippitsch 2016-07-21 15:13:01 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.
Comment 1 Sebastian Dröge (slomo) 2016-07-21 15:32:33 UTC
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.
Comment 2 Sebastian Dröge (slomo) 2016-10-20 17:20:57 UTC
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.
Comment 3 Sebastian Dröge (slomo) 2016-10-20 17:42:29 UTC
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.
Comment 4 Thiago Sousa Santos 2016-10-23 18:49:55 UTC
Review of attachment 338109 [details] [review]:

Looks good, I also like this alternative better.
Comment 5 Sebastian Dröge (slomo) 2016-11-01 18:11:26 UTC
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