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 758946 - hlsdemux: change of playlist to the same playlist after first fragment, when connection speed is set
hlsdemux: change of playlist to the same playlist after first fragment, when ...
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-12-02 12:27 UTC by Maroš Ondrášek
Modified: 2015-12-02 12:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch: hlsdemux-update-current-variant-if-connection-speed (1.38 KB, patch)
2015-12-02 12:27 UTC, Maroš Ondrášek
committed Details | Review

Description Maroš Ondrášek 2015-12-02 12:27:32 UTC
Created attachment 316654 [details] [review]
patch: hlsdemux-update-current-variant-if-connection-speed

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= 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:
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:

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
Comment 1 Sebastian Dröge (slomo) 2015-12-02 12:40:33 UTC
commit 905158a055d8020cf6be79a5a9fbfc6979e37639
Author: Maroš Ondrášek <>
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