GNOME Bugzilla – Bug 750028
hlsdemux: Search more when advancing fragment
Last modified: 2015-05-29 07:34:19 UTC
Description in the commit message
Created attachment 304151 [details] [review] hlsdemux: Search more when advancing fragment In live situations, it is not uncommon for the current fragment to end up out of the (updated) play range (lowest/highest sequence). But the next fragment to play *is* present in the play range. When advancing, if we can't find the current GstM3U8MediaFile, don't abort straight away. Instead, look if a GstM3U8MediaFile with the next sequence value is present, and if so switch to it.
Created attachment 304153 [details] Graph of low/high/current mediafile sequence This is a plot from the radio4 stream mentioned in #745171 The first/last seqnum lines are the lowest/highest fragment sequence (when a m3u8 gets updated). The current seqnum line corresponds to the fragment being downloaded As can be noticed in 3 places (at 171s, 305s and 376s), the low seqnum line overtakes the "current" line. Without this patch, this would result in hlsdemux not advancing, baseadaptivedemux triggering a discont, and the sending the next fragment. This would cause various issues. With the patch, due to looking harder for the "next" fragment, we no longer fail. Notice also that we are not getting "late" here. If that was the case, the current line would not be parallel (i.e. having the same rate) as the high/low plots.
This potentially fixes bug #745171 and #745281
*** Bug 745171 has been marked as a duplicate of this bug. ***
*** Bug 745281 has been marked as a duplicate of this bug. ***