[Bug 758387] New: hlsdemux: downloads same fragment of live playlist at different bitrates

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Nov 20 03:28:50 PST 2015


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

            Bug ID: 758387
           Summary: hlsdemux: downloads same fragment of live playlist at
                    different bitrates
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: bugzilla at ashley-family.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

At startup of a live HLS stream, gst_m3u8_client_update will select a starting
position 3 fragments from the end of the file. If hlsdemux performs a bitrate
switch, gst_hls_demux_update_playlist incorrectly re-enforces the rule about
starting 3 fragments from the end, causing the wrong fragment to be selected.

For example, consider the case of two bitrates containing 6 fragments:

         800  0  1  2  3  4  5
        1500  0  1  2  3  4  5

At startup, the 800KBps stream is selected and fragment 3 is selected as the
start position. After downloading 3 and 4, hlsdemux switches to the 1500KBps
stream. At this point gst_hls_demux_update_playlist forces the position back to
three fragments from the end of the 1500KBps playlist. By the time this switch
takes place, the live playlist has moved on:

        1500     1  2  3  4  5  6

This means that hlsdemux will select fragment 4 when performing the bitrate
switch. This results in the following fragments being sent from hlsdemux:

         800/3.ts
         800/4.ts
        1500/4.ts
        1500/5.ts

There is no need for the code in gst_hls_demux_update_playlist because
gst_m3u8_client_update enforces the 3 fragment rule at start-up and
gst_m3u8_client_get_seek_range_no_lock enforces the rule for seeking.

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