[FFmpeg-devel] Seeking in Apple HTTP Live Streaming

[Takis Issaris]

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?



Thanks for your fast reply!

With friendly regards,
Takis