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 743578 - qtdemux: Parse 'sidx' atom (for duration and indexing in fragmented files)
qtdemux: Parse 'sidx' atom (for duration and indexing in fragmented files)
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-01-27 13:38 UTC by Enrique Ocaña González
Modified: 2015-02-12 21:02 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch (3.84 KB, patch)
2015-02-11 14:34 UTC, Philippe Normand
none Details | Review
patch (13.27 KB, patch)
2015-02-11 14:35 UTC, Philippe Normand
needs-work Details | Review
updated patch (14.47 KB, patch)
2015-02-12 17:03 UTC, Philippe Normand
committed Details | Review

Description Enrique Ocaña González 2015-01-27 13:38:28 UTC
When playing car-audio-1MB-trunc.mp4[1] using gst-play-1.0, the stream duration is computed as "10s" in the begining and is updated later up to "60s" as qtdemux gets more data. For reference, the real stream duration when played using Chromium is ~65s.

As a curiosity, gst-play-1.0 stops at 10s, unaffected by the updated duration.

But the real problem this bug wants to highlight is the need of a way for qtdemux to process all the available data while it's still in the pause state. In my use case, the actual 1MB data buffer is fed to GStreamer by a browser, all in a row. In theory, GStreamer would be in conditions to compute the whole duration of the fed data when it reaches the pause state. However, due to the way qtdemux is implemented, the duration reaches the actual value only when GStreamer changes to play state, data starts to flow and the right data reaches qtdemux.

Needing the real duration of all the fed buffer is critical for the Media Source Extensions algorithms we're helping to implement in WebKit.

Comment 1 Edward Hervey 2015-01-28 08:24:10 UTC
Looks like the proper solution is to parse the 'sidx' atom (which is between the 'moov' and first 'moof') which describes all following fragments (along with duration).
Comment 2 Thiago Sousa Santos 2015-01-28 11:53:26 UTC
dashdemux already has code on a separate file for that
Comment 3 Philippe Normand 2015-02-06 18:08:18 UTC
Thanks for the hint Thiago!

Would it be worth moving the isoff parser in -good at some point? It could easily be used by qtdemux.
Comment 4 Philippe Normand 2015-02-11 14:34:41 UTC
Created attachment 296604 [details] [review]
Comment 5 Philippe Normand 2015-02-11 14:35:47 UTC
Created attachment 296605 [details] [review]

Now with the isoff parser :)
Comment 6 Thiago Sousa Santos 2015-02-12 15:15:47 UTC
Review of attachment 296605 [details] [review]:

Looks good, but I guess it also needs to be done for push-mode operation, right?

So it also needs to parse the sidx in the process_adapter() function.
Comment 7 Philippe Normand 2015-02-12 17:03:43 UTC
Created attachment 296694 [details] [review]
updated patch

Now working in push-mode too :)
Comment 8 Thiago Sousa Santos 2015-02-12 17:35:26 UTC
Thanks, the code is ok now.

But did you notice that the sidx points to 19 entries of ~10s while the file only has 7 moof entries. Meaning that this is a file cut from another one and the sidx wasn't updated.

So, duration is now reported as 3min, while it only contains about 1min of audio.
Comment 9 Philippe Normand 2015-02-12 17:37:41 UTC
Yes indeed, I think this file was produced from another one which had a (longer) video stream.
Comment 10 Thiago Sousa Santos 2015-02-12 21:01:30 UTC
commit 3a9b0188cd6efa03daa05190ccabebe5211ed4a5
Author: Philippe Normand <>
Date:   Wed Feb 11 15:30:44 2015 +0100

    qtdemux: Initial 'sidx' atom parsing support
    Parse the 'sidx' atom and update the total duration according to the
    parser result. The isoff parser code is imported from
    gst-plugins-bad's dashdemux and a gst_isoff_sidx_parser_add_data()
    function was factored out of the gst_isoff_sidx_parser_add_buffer()