GNOME Bugzilla – Bug 727742
hlsdemux: selects incorrect starting position for live streams
Last modified: 2015-02-21 12:38:19 UTC
When playing live HLS streams, the media playback starts from the beginning of the media playlist. When playing a live HLS stream, media playback should start from 3 fragments from the end of the playlist. See section 6.3.3. of the HLS draft [1] [1] http://tools.ietf.org/html/draft-pantos-http-live-streaming-12#page-29
Created attachment 273705 [details] [review] select 3 fragments from the end of live hls streams
What should it do when switching playlists? Currently it uses the media sequence to select the next fragment but that is wrong according to the spec (the sequence numbers can be different for different variants). Should it also use the 3rd fragment from the end then?
>Should it also use the 3rd fragment from the end then? No, I don't think so. It would be very annoying if while watching 30 minutes behind live hlsdemux suddenly jumped to 30 seconds behind live just because it moved to a different bitrate. How to correctly switch between bitrates should be a new bug ticket. The HLS spec is rather vague in that it says the client must use the timestamps in the MPEG-TS to correctly switch between variants, but there is nothing in the m3u8 to know which fragment contains a particular timestamp. Regardless of what the HLS spec says, there are plenty of implementations that make the assumption that sequence numbers match across representations. The patch associated with this ticket only kicks in when the first fragment is selected for the first selected variant.
Review of attachment 273705 [details] [review]: A minor fix below, also could you update it to merge cleanly against git master? Thanks ::: ext/hls/m3u8.c @@ +676,3 @@ + self->sequence = + GST_M3U8_MEDIA_FILE (g_list_nth_data (m3u8->files, + pos >= 0 ? pos : 0))->sequence; pos is a guint so it will never be negative. You need to make it a gint for this to work.
Created attachment 297397 [details] [review] static gboolean gst_m3u8_client_is_live_no_lock (GstM3U8Client * client); Re-based to master and fix guint bug that affects files with less than 3 fragments.
Thanks. From the spec: " The client SHALL choose which Media Segment to play first from the Media Playlist when playback starts. If the EXT-X-ENDLIST tag is not present and the client intends to play the media normally, the client SHOULD NOT choose a segment which starts less than three target durations from the end of the Playlist file. Doing so can trigger playback stalls." So picking any segment that is at least last-3 is ok according to the spec. As this is live, getting closer to the current recording position provides a better experience. If needed we can add a property to adaptivedemux to allow users selecting what would be best for them, selecting earlier or later fragments. For future patches, please run 'make check' to make sure your commit didn't break the tests. This patch had 2 tests failing because of the new starting position. I amended the fixes to your patch. commit a08dd856081a3fd79c8f24947a396f9a8638d1ca Author: Alex Ashley <bugzilla@ashley-family.net> Date: Fri Feb 20 13:55:05 2015 +0000 hlsdemux: select correct starting position for live streams When playing live HLS streams, the media playback starts from the beginning of the media playlist. When playing a live HLS stream, media playback should start from 3 fragments from the end of the playlist. See section 6.3.3. of the HLS draft [1] This commit changes the logic to select 3 fragments from the end when playing a live stream. [1] http://tools.ietf.org/html/draft-pantos-http-live-streaming-12#page-29 https://bugzilla.gnome.org/show_bug.cgi?id=727742