[Bug 758946] New: hlsdemux: change of playlist to the same playlist after first fragment, when connection speed is set

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Dec 2 04:27:32 PST 2015


https://bugzilla.gnome.org/show_bug.cgi?id=758946

            Bug ID: 758946
           Summary: hlsdemux: change of playlist to the same playlist
                    after first fragment, when connection speed is set
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: mx3ldev at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 316654
  --> https://bugzilla.gnome.org/attachment.cgi?id=316654&action=edit
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=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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list