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 658659 - qtmux: Fix ctts entries for streams that don't start with timestamps from 0
qtmux: Fix ctts entries for streams that don't start with timestamps from 0
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other All
: Normal normal
: 0.10.31
Assigned To: Thiago Sousa Santos
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-09 14:49 UTC by Thiago Sousa Santos
Modified: 2011-09-12 10:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch that fixes it (3.70 KB, patch)
2011-09-09 14:50 UTC, Thiago Sousa Santos
none Details | Review
qtmux: Fix ctts generation for streams that don't start at 0 timestamps (4.90 KB, patch)
2011-09-09 20:53 UTC, Thiago Sousa Santos
committed Details | Review

Description Thiago Sousa Santos 2011-09-09 14:49:49 UTC
When qtmux processes a stream that doesn't start at 0 timestamps it might generate a ctts table with all values offset by the timestamps of the first buffer (that is not 0). This is causing the resulting file to have a delay on playback (the same offset stored on ctts).

Example: If you push a stream starting at 2s on qtmux, the ctts entries will have 2s added. On playback, qtmux will start pushing buffers starting at 2s as well, causing a delay.

The attached patch fix this, making it start from the beginning. The question is if we want to push it, or make qtmux rely on newsegments to tell what is the first ts.
Comment 1 Thiago Sousa Santos 2011-09-09 14:50:20 UTC
By the way, this is easily reproducible with camerabin2.
Comment 2 Thiago Sousa Santos 2011-09-09 14:50:45 UTC
Created attachment 196116 [details] [review]
Patch that fixes it
Comment 3 Mark Nauwelaerts 2011-09-09 15:22:44 UTC
Patch looks fine, might only need a few pedantic checks to avoid ending up with negative ts when subtracting (though we are probably already lost anyway if that ever happens).

In general there is a lot to say for having "the outside" dictate some stuff, i.e. newsegment in this case.  However, particular formats have their limitations, e.g. avimux barely cares about incoming time at all.  In the case here, if no pts is written (which is configurable and not done by default until recently) then the first ts would basically be "0" (iirc).  Moreover, the dts and pts written may presently vary somewhat in being "0"-based or not depending on the dts-method.  So, all in all, better clarify/normalize all of this the same way.

If there is ever really a desire for a gap and nothing but a gap at the start, then we may hear about it and learn a new use case along the way ...
Comment 4 Thiago Sousa Santos 2011-09-09 20:53:22 UTC
Created attachment 196145 [details] [review]
qtmux: Fix ctts generation for streams that don't start at 0 timestamps

Patch improved: now checks subtractions and assigns result to 0 if it would
result in negative values
Comment 5 Thiago Sousa Santos 2011-09-12 10:37:49 UTC
Committed.

commit 261d11a6d7392f9231a4f32193d845ec26246581
Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk>
Date:   Fri Sep 9 09:12:56 2011 -0300

    qtmux: Fix ctts generation for streams that don't start at 0 timestamps
    
    Subtract the first timestamp of a stream from all input buffers to
    get 0-based timestamps for creating a sane ctts table. Without this
    patch the ctts could have larger values than needed, causing the
    playback to have a delay at startup.
    
    As the first timestamp is only found after a few buffers are queued
    (due to possible reordered buffers), once we find the first timestamp
    we subtract it from all buffers on the queue, from that point on,
    all buffers have their timestamps subtract when they are collected.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=658659