From 821320fbc4f978388a13d5862cf8872004dd26fd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= Date: Thu, 3 Dec 2015 11:46:10 +0200 Subject: [PATCH] hlsdemux: Resync live playlists to the 3rd newest fragment if we fall off the playlist As HLS does not provide any way of knowing the server's clock, and we do buffering of "live" streams, at some point we will fall behind the server in many cases and would have to advance to a fragment that is not in the playlist anymore. Previously we would've just resynced to the next oldest fragment that is still there, but this causes problems as from this point onwards we would always fall off the playlist again all the time. Instead we now resync and move to the 3rd newest fragment like we would do when starting playback of a live stream. https://bugzilla.gnome.org/show_bug.cgi?id=758987 --- ext/hls/m3u8.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/ext/hls/m3u8.c b/ext/hls/m3u8.c index c5e0d372e3..b9d2546205 100644 --- a/ext/hls/m3u8.c +++ b/ext/hls/m3u8.c @@ -1051,6 +1051,21 @@ gst_m3u8_client_advance_fragment (GstM3U8Client * client, gboolean forward) GST_DEBUG ("Could not find current fragment, trying next fragment directly"); alternate_advance (client, forward); + + /* Resync sequence number if the above has failed for live streams */ + if (client->current_file == NULL && GST_M3U8_CLIENT_IS_LIVE (client)) { + /* for live streams, start GST_M3U8_LIVE_MIN_FRAGMENT_DISTANCE from + the end of the playlist. See section 6.3.3 of HLS draft */ + gint pos = + g_list_length (client->current->files) - + GST_M3U8_LIVE_MIN_FRAGMENT_DISTANCE; + client->current_file = + g_list_nth (client->current->files, pos >= 0 ? pos : 0); + client->current_file_duration = + GST_M3U8_MEDIA_FILE (client->current_file->data)->duration; + + GST_WARNING ("Resyncing live playlist"); + } GST_M3U8_CLIENT_UNLOCK (client); return; }