[Bug 797325] New: dashdemux: SIDX reverse playback failure

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 797325
           Summary: dashdemux: SIDX reverse playback failure
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: bilboed at bilboed.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

This can be reproduced with:
$ USE_PLAYBIN3 gst-validate-launcher -m -t
validate.dash.playback.reverse_playback.dash_exMPD_BIP_TC1

That test will attempt to do reverse playback. From an adaptivedemux/dashdemux
point of view what happens is:
* manifest is read
* streams are setup (using a certain bitrate variant for the video stream)
* playback is started, sidx is downloaded and parsed, data is pushed downstream
going forward
* a flushing reverse playback seek (with a specific start position) is received 
* playback is restarted from the end
* based on the sidx table, dashdemux starts downloading chunks of GOP
* adaptivedemux detects we can switch to a higher bitrate and requests
dashdemux to do so
* => The SIDX entries are wiped since they are no longer valid for that variant
and therefore the sidx entries need to be re-downloaded
* When the chunk for SIDX table is downloaded, the "position" for that stream
is updated to ... 0
* The next time the adaptivedemux loop is run (i.e. when a *chunk* is done
downloading), it compares the stream position (0) to the configured
segment.start (specified and non-0) ... and therefore assumes we're done
reading that stream
* => playback stops for the video stream (the audio one carries on because
there are no variants, but then the pipeline just hangs).

Note: With playbin2/decodebin2, the "switching to higher bitrate" happens quite
often before the seek is received. It seems to be due to the fact that
pre-rolling will consume more data downstream, and therefore adaptivedemux
switches to the higher bitrate *before* the seek is received.

My gutt feeling is that when downloading SIDX "chunks", no position whatsoever
should be reported/used/updated for the stream->segment. It's non-data really.

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