dashdemux: SIDX reverse playback failure
Submitted by Edward Hervey
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.