[vlc-devel] [PATCH] HttpLive stream_filter: alternative version of ChooseSegment function

[Robert Forsman]

On Mon, 12 Mar 2012 15:05:37 -0400
Rémi Denis-Courmont <remi at remlab.net> wrote:

> Upon non-zero start-time, the input core will ask the demuxer to (time-)seek. 
> Either the TS demuxer is unable to seek HLS streams, or HLS streams are not 
> (byte-)seekable. But they probably should be to some extent. Whenever this 
> limitation is addressed, your patch will introduce a silent regression.

It is possible to imagine HLS media as byte-seekable, but you have to
learn the byte size of each segment.

VOD HLS media can be imagined as a single transport stream divided
between a large number of URLs.

Live HLS media can be conceptualized as a sliding window in a file with
no beginning or end.  When you first start to pull it you are given
access to a bit in the middle.  As time goes on more bits become
available on the end, and bits fall off of the beginning.  Deciding
what is the mapping from byte offset to URLs is mildly arbitrary, but
once you pick an anchor it becomes entirely mathematical.

Probably the biggest factor is that HLS is usually variable bit rate,
so when you start with a time reference, it's cleaner to map the time to
a segment (using the temporal lengths listed in the .M3U8) and then
find the right access unit within that file using PTSs.

I've had horrid luck seeking in VBR transport streams (single-file)
with mplayer (jump forward 1 minute is sometimes 20 seconds instead).
I haven't tortured VLC in this respect so I don't know how well it
handles things.