[FFmpeg-devel] Seeking in Apple HTTP Live Streaming
michaelni at gmx.at
Tue Nov 22 00:40:07 CET 2011
On Mon, Nov 21, 2011 at 03:01:43PM -0800, Takis Issaris wrote:
> Hi Michael,
> ----- Original Message -----
> > From: Michael Niedermayer <michaelni at gmx.at>
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Cc:
> > Sent: Monday, November 21, 2011 8:34 PM
> > Subject: Re: [FFmpeg-devel] Seeking in Apple HTTP Live Streaming
> > On Mon, Nov 21, 2011 at 08:21:28AM -0800, Takis Issaris wrote:
> >> Hi all,
> >> As a follow-up to my previous patch, I'd like to implement more exact
> > seeking on HTTP Live Streams. Currently, when seeking to a specific timestamp in
> > such a stream, the seeking results in arriving at the start of the correct
> > segment, but not at the requested timestamp within that segment. Worse, when
> > seeking to a specific timestamp which happens to be a part of the segment which
> > is currently being played, the playback resets to the start of the current
> > timestamp (that could most likely be fixed rather easily). So, when pressing
> > forward arrow key when using ffplay, you'll actually move backwards to the
> > start of the segment (if current timestamp+10s lies within the current segment).
> >> I'd like to change that so that the applehttp.c seeking implementation
> > uses mpegts.c to actually seek to the specified timestamp, but I'm not sure
> > on how to implement this.
> >> Currently, when seeking using applehttp_read_seek, I think there's no
> > valid MPEG-TS demuxer context in that function. Should I make sure I get a valid
> > demuxer there, or should I defer the actual seeking using the MPEG-TS demuxer
> > until a valid demuxer is constructed elsewhere in the applehttp.c file?
> > I assume theres no way to tell the server to start a segment from a
> > specific time? (i havnt found one)
> No, I don't think so (haven't found one either).
> > Do the servers support seeking to a specific byte position within a
> > segment ?
> Yes, it's just an Apache HTTP server, so it supports GET with a byte range (If that
> was what you were hinting at).
> > If yes, seeking per CBR assumption is an option which also doesnt need
> > the demuxer
> Yes, initially I'd never even considered CBR. But as I start to think about it,
> the seeking speedup could counterweight the quality/bitrate disadvantage.
> > The reason why i suggect to assume CBR is that the alternative is
> > the default seek per timestamp which does a binary search and this
> > could be quite slow with http needing to send a few packets back and
> > forth for each iteration of the search
> Yes, but the draft recommends using 10 second segments, so I'd hoped that
> the actual number of HTTP GETs needed would be rather limited.
> > depending on network speed, bitrate and segment size a linear search
> > could also be considered, that is demux and throw away packets until
> > the right time, this may or may not be faster than a binary search
> Yes, I'd thought about doing something like that as the applehttp.c seek
> already skips to the correct 10s segment, so a linear search within that should
> not take that long.
> Would something like that be useful in applehttp.c or should it be kept in application
> specific code?
requireing applehttp specific code in every app does not seem a good
idea to me thus IMHO its better in applehttp.c
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel