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 748369 - dashdemux: Excessive (96GB on 32-bit machines) memory usage on some dash streams
dashdemux: Excessive (96GB on 32-bit machines) memory usage on some dash streams
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other All
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-04-23 14:14 UTC by Andrew Oakley
Modified: 2015-05-13 16:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Andrew Oakley 2015-04-23 14:14:53 UTC
The mpdparser code tries to allocate a GstMediaSegment for each segment in the current timeline (in gst_mpd_client_setup_representation).  This doesn't end well if there is an element with a large number of repeats (e.g. <S d="10000" r="4294967295" />).

This occurs in some of the test vectors here:

The first one is Test Vector 11 in the Single Resolution Multi-Rate set, the manifest is here:

The actual repeat count here is "-1", I'm not sure what the correct behaviour should be in this case (currently it gets turned into UINT_MAX).

I don't think we actually need to build the segments array, we can calculate the relevant data on the fly when looking for a segment by index (gst_mpdparser_get_chunk_by_index) or time (gst_mpd_client_stream_seek).
Comment 1 Thiago Sousa Santos 2015-05-06 12:05:21 UTC
Is there any reference on what -1 for @r would mean? I don't see anything about it in the spec.

There are possible improvements. One that would be simple is to represent the repeated entries as a single entry with a repeat counter, just like mssdemux does. This is simpler than doing 'lookup on the fly' when needed and could be done as a first step.

Are you working on a patch?
Comment 2 Andrew Oakley 2015-05-06 12:22:35 UTC
I didn't manage to find anything in the spec either, I'm not sure what the right behaviour is.

I have not looked at mssdemux, but I think what you are proposing is actually fairly similar to what I was thinking.  I'm not currently working on this, I didn't get any further than investigating the issue.
Comment 3 Thiago Sousa Santos 2015-05-12 03:03:02 UTC
I'm going to try to improve this.
Comment 4 Thiago Sousa Santos 2015-05-13 16:48:18 UTC
commit 6344f86e44d0c31a169fd5942b61e9126b57027f
Author: Thiago Santos <>
Date:   Thu May 7 16:30:48 2015 -0300

    dashdemux: improve mpd parsing for repeated segment entries
    Use a single segment to represent it internally to avoid using too
    much memory. This has the drawback of issuing a linear search to
    find the correct segment to play but this can be fixed by using
    binary searches or caching the current position and just looking
    for the next one.

This should fix it.