[FFmpeg-devel] Seeking in Apple HTTP Live Streaming
Michael Niedermayer
michaelni at gmx.at
Tue Nov 22 01:20:25 CET 2011
On Mon, Nov 21, 2011 at 04:14:03PM -0800, Takis Issaris wrote:
>
>
> ----- Original Message -----
> > From: Michael Niedermayer <michaelni at gmx.at>
> > To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> > Cc:
> > Sent: Tuesday, November 22, 2011 12:40 AM
> > Subject: Re: [FFmpeg-devel] Seeking in Apple HTTP Live Streaming
> >
> > 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
>
> Agreed. Should the seeking be completed after returning from applehttp.c's
> seeking call or would it be acceptable that the actual search happens elsewhere?
> (f.e. somewhere near the read frame call or near the open url call).
do whatever makes most sense technically
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111122/696a1780/attachment.asc>
More information about the ffmpeg-devel
mailing list