GNOME Bugzilla – Bug 731164
hlsdemux: Attempt to reload variant playlist if refreshing playlist or downloading fragments failed
Last modified: 2014-06-06 10:04:43 UTC
A HLS stream may invalidate playlists referenced by the master (variant) playlist, e.g. for load balancing or session validation purposes. In that case, refreshing the playlist or downloading a fragment may fail. If this happens, attempt to refresh the variant playlist, and if the referenced playlists can still be matched, update the URLs to these playlists. All that may have changed is that these URLs now redirect to another host or path.
Created attachment 277807 [details] [review] Patch
Created attachment 277810 [details] [review] Actual patch
Review of attachment 277810 [details] [review]: Thanks for the patch! Looks good except for some minor issues ::: ext/hls/m3u8.c @@ +138,3 @@ + dup->targetduration = self->targetduration; + dup->allowcache = self->allowcache; + dup->key = g_strdup (self->key); You should probably copy the IV too (also check if you have all the members of the struct then) @@ +843,3 @@ + GST_ERROR + ("Cannot update variant playlist, unable to match all playlists"); + goto out; Why is that an error always? Maybe we played the low-bitrate variant and the high-bitrate variant was dropped?
That's true, I guess we really only need the variant playlist that we are currently playing. But even if that one went away, we could switch to an alternative variant. I just don't really know how to safely switch over to another playlist, if we can't match. Maybe this log message should be changed to a FIXME for future improvement?
ok :)
Created attachment 277886 [details] [review] Updated patch This patch changes that error message to a FIXME. The iv is maintained per fragment and does not need to be copied (actually there is no field for it in the _GstM3U8 structure).
I wonder why the key is per playlist though. It has exactly the same scope as the IV (all fragments following it until the next IV/key).
Maybe they need to be cached somewhere in between EXT-X-KEY tags? I guess the EXT-X-KEY doesn't have to be specified for each fragment, but it's just a guess from looking at the code. I haven't looked at the spec in this regard.
Yes exactly. I don't know why we store them inside the playlist at all :)
commit 008edeadaef13f585eefba7ff449a25a68661275 Author: Sebastian Dröge <sebastian@centricular.com> Date: Fri Jun 6 13:04:04 2014 +0300 hlsdemux: Fix compiler warnings commit babd8969f29966e471c74f6411e6a15fec80f810 Author: Thomas Bluemel <tbluemel@control4.com> Date: Fri May 30 16:34:18 2014 -0600 hlsdemux: Reload the variant playlist if refreshing a playlist or downloading a fragment fails This can happen if the playlists have moved due to the variant playlist now being redirected to another target. This currently only works as long as the referenced playlists don't change in relation to the variant playlist, and the new location is purely due to a new path triggered by a new redirection target of the variant playlist, or a new redirection target of the playlist itself. https://bugzilla.gnome.org/show_bug.cgi?id=731164