[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