GNOME Bugzilla – Bug 748369
dashdemux: Excessive (96GB on 32-bit machines) memory usage on some dash streams
Last modified: 2015-05-13 16:48:18 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: http://dashif.org/test-vectors/ The first one is Test Vector 11 in the Single Resolution Multi-Rate set, the manifest is here: http://dash.edgesuite.net/dash264/TestCases/1c/qualcomm/1/MultiRate.mpd 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).
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?
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.
I'm going to try to improve this.
commit 6344f86e44d0c31a169fd5942b61e9126b57027f Author: Thiago Santos <thiagoss@osg.samsung.com> 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. https://bugzilla.gnome.org/show_bug.cgi?id=748369 This should fix it.