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 770075 - adaptivedemux: fix stream exposure condition
adaptivedemux: fix stream exposure condition
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.9.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-18 08:32 UTC by Michael Olbrich
Modified: 2016-08-22 16:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
adaptivedemux: fix stream exposure condition (2.01 KB, patch)
2016-08-18 08:32 UTC, Michael Olbrich
none Details | Review
adaptivedemux: fix stream exposure condition (2.01 KB, patch)
2016-08-22 07:32 UTC, Michael Olbrich
none Details | Review

Description Michael Olbrich 2016-08-18 08:32:01 UTC
Created attachment 333548 [details] [review]
adaptivedemux: fix stream exposure condition

The new streams should not be exposed until all streams are done with the
current fragment. The old code is incorrect and actually only checked the
current stream. Fix this by properly checking all streams.

Also, ignore the current stream. The code is only reached when the current
stream finished downloading and since
65f2ce3c2f1f26b30bbf807b35b1faf23504fe7c ("adaptivedemux: On EOS, handle it
before waking download loop") download_finished is set after
gst_adaptive_demux_stream_advance_fragment_unlocked() is called.

Without this HLS playback with multiple streams is broken, because the new
streams are never exposed.
Comment 1 Michael Olbrich 2016-08-18 08:40:38 UTC
Note: even with this change, switching bitrates with HLS doesn't work very well for me.

What I observe is, that audio plays without problems and video stops for several seconds. I think, what happens is this:
- the main stream contains only video
- audio is in a separate stream

When the first fragment of the main stream is done, it triggers a bitrate change.
At this point in time the audio stream is already at least on fragment ahead. By the time playbin switches to the new streams, the video is already too late.

I'm not sure how to fix this. Do we need to throttle the streams in some way?
Comment 2 Tim-Philipp Müller 2016-08-21 17:52:45 UTC
That would be commit 07f49f15 in master.
Comment 3 Michael Olbrich 2016-08-22 07:32:37 UTC
Created attachment 333860 [details] [review]
adaptivedemux: fix stream exposure condition

Right, I git the commit hash from the wrong branch. Fixed.
Comment 4 Jan Schmidt 2016-08-22 16:05:10 UTC
Thanks, pushed as 0a63569fd16354464df9b3e3629fb56c4f9b3c43!

I think some throttling of downloading of the audio streams would be good, but I'm not sure what the most sensible way to do it is. In general, we can't match up sequence numbers across streams. Something based on the timestamping code might work, but also requires extracting timestamps from the subtitle streams, and the audio id3 tag only provides a start timestamp for each fragment, not the end time.