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 797325 - dashdemux: SIDX reverse playback failure
dashdemux: SIDX reverse playback failure
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2018-10-23 12:46 UTC by Edward Hervey
Modified: 2018-11-03 14:36 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Edward Hervey 2018-10-23 12:46:10 UTC
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.
Comment 1 GStreamer system administrator 2018-11-03 14:36:36 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: