[Bug 748369] New: Excessive (96GB on 32-bit machines) memory usage on some dash streams

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=748369

            Bug ID: 748369
           Summary: Excessive (96GB on 32-bit machines) memory usage on
                    some dash streams
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: andrew at adoakley.name
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.