[FFmpeg-devel] Seeking in Apple HTTP Live Streaming

[Takis Issaris]

----- 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).

With friendly regards,
Takis