Skip to content

hlsdemux: downloads same fragment of live playlist at different bitrates

Submitted by A Ashley

Link to original bug (#758387)

Description

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.