hlsdemux: using iframe playlists when seeking

Duncan Palmer dpalmer at digisoft.tv
Tue Dec 9 15:49:06 PST 2014

Sebastian, we should be able to detect the scenario that you've
mentioned by comparing the URL of the fragment found when using the
i-frame playlist with that found when using the non-iframe playlist.
If they differ, we fall back to the existing implementation.

Alternately, we could do some sanity checking on the offset retrieved
from the i-frame playlist. In the case where we've a different set of
TS files, the offset we retrieve from the i-frame playlist will most
likely not be valid for the segment in the non-i-frame playlist, so we
can disregard it, and fall back to the existing implementation. E.g.

    Existing implementation:
        seek (x) => segment y (where segment y is in the range of
offsets [a .. b])

    Using the iframe playlist, where a different set of TS files are used:
        seek(x) => offset c

    Offset c is not in [a .. b], therefore, we disregard it, and fall
back to the existing implementation.

If the 2 sets of TS files are similar enough that offset c is in [a ..
b], then one of the following will happen:
- Offset c represents a time earlier than the seek time x. This is
fine, and works in the same way as the existing implementation.
- Offset c represents a time later than the seek time x. This is not
so good - we'll perhaps seek to a time a few seconds past where we
should be.

So, this method of comparing offsets isn't reliable...

On 8 December 2014 at 10:40, Duncan Palmer <dpalmer at digisoft.tv> wrote:
> On 5 December 2014 at 18:30, Sebastian Dröge <sebastian at centricular.com> wrote:
>> While the idea is good, the problem is that this requires the I-frame
>> playlist to point to the I-frame offsets in the normal playlist. This is
>> not required by the spec, it can be a completely different MPEG TS
>> stream.
> Your right. That sux.
> Having said that, I would imagine that pointing to a different TS from
> an iframe playlist would be an unusual thing to do. Is there any
> precedent in using properties to enable specific behaviours? We could
> enable/disable use of iframe indices for seeking this way.

More information about the gstreamer-devel mailing list