GNOME Bugzilla – Bug 758946
hlsdemux: change of playlist to the same playlist after first fragment, when connection speed is set
Last modified: 2015-12-02 12:48:10 UTC
Created attachment 316654 [details] [review]
If connection speed is set and we have variant playlist, current variant of main playlist is not updated and may not correspond to current playlist.
This causes changing of playlist to the same playlist after first fragment is downloaded because of not updated current variant, which causes minor stuttering(can be seen in frame 300).
GST_DEBUG=adaptivedemux:5,hlsdemux:6 gst-launch-1.0 playbin uri=http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8 connection-speed=4294 video-sink=glimagesink
0:00:00.482731429 20218 0x7f6e2c12d940 DEBUG adaptivedemux gstadaptivedemux.c:2334:gst_adaptive_demux_stream_download_uri:<hlsdemux0:src_0> Waiting for fragment download to finish: http://devimages.apple.com/iphone/samples/bipbop/gear4/fileSequence0.ts
0:00:05.309757198 20218 0x7f6e1c001f20 DEBUG adaptivedemux gstadaptivedemux.c:1894:_src_chain:<hlsdemux0:src_0> Received buffer of size 971. Now 971 on adapter
0:00:05.341336074 20218 0x7f6e1c001f20 DEBUG hlsdemux gsthlsdemux.c:555:gst_hls_demux_finish_fragment:<hlsdemux0> Data still on the adapter when EOS was received: 0
0:00:05.341543084 20218 0x7f6e1c001f20 INFO hlsdemux gsthlsdemux.c:1007:gst_hls_demux_change_playlist:<hlsdemux0> Client was on 200000bps, max allowed is 4294000bps, switching to bitrate 737777bps
0:00:05.362998326 20218 0x7f6e2c12d940 DEBUG adaptivedemux gstadaptivedemux.c:2334:gst_adaptive_demux_stream_download_uri:<hlsdemux0:src_1> Waiting for fragment download to finish: http://devimages.apple.com/iphone/samples/bipbop/gear4/fileSequence1.ts
As you can see, we have the same variant(gear4) selected when downloading first fragment(fileSequence0.ts) and after playlist change when downloading second fragment(fileSequence1.ts).
Before playlist change, we have current_variant bitrate = 200000bps, which corresponds to the first variant in manifest(gear1).
I think that current_variant should have been already set to 733777bps in gst_hls_demux_process_manifest when getting playlist according to connection speed.
Proposed solution in attachment
Author: Maroš Ondrášek <email@example.com>
Date: Wed Dec 2 11:01:53 2015 +0100
hlsdemux: update current variant if connection speed is set
If connection speed is set, playlist according
to connection speed is selected as current playlist.
Problem is that the current variant of main playlist still
points to previously set variant.
If previously set variant doesn't correspond to current
playlist, then it causes unnecessary change of playlist
to the same playlist after first fragment is downloaded,
because of not updated current variant.
To fix this, we need to make sure that current variant
of main playlist corresponds to the current playlist