[foms] Proposal: adaptive streaming using open codecs

[Chris Pearce]

On 6/11/2010 5:53 a.m., Mark Watson wrote:
> On Nov 4, 2010, at 9:13 PM, Chris Pearce wrote:
>
>>
>>
>> I think some kind of model where the decoding pipeline gets passed
>> keyframe-aligned byte-ranges from possibly different resources seems
>> reasonable. We'd probably not want the media data from the chunks to be
>> exposed to JS, we'd be better off passing "handles" to chunks around in
>> JS instead.
>>
> What do you think of the scheme that Jeroen proposed where the "handles" are ( URL, byte range ) pairs ?


I think the Jeroen's appendVideo() proposal is a good starting point for 
discussion. I'm happy with a bufferLevel attribute, but I think browsers 
should only honour it if we're in readyState HAVE_ENOUGH_DATA. Living in 
New Zealand, I very frequently have to pause YouTube videos to allow 
them to mostly download in order to play them through without stopping, 
and I don't want to stop people from pre-buffering when necessary.

I'd prefer to make manual stream switching opt-in, and not have an 
explicit appendVideo() call. I'd rather have JS periodically poll the 
state of the download (we can make available whatever data/statistics 
you need), and have JS call setLevel() to force stream changes. The 
browser can then switch the stream as soon as it's able to. That seems 
like less work by fewer people in the long run.

I don't like the idea of an appendVideo() function which specifies a 
byte range because:

   1. I think that browsers wouldn't want to initiate a new byte range
      request for every appendVideo() call anyway, they'd want to
      request the entire media (probably with a startOffset to EOF BRR),
      in order to reduce delays and overhead caused by setting up many
      smallish BRR.
   2. If appendVideo() could specify a byte range, it could specify an
      invalid range, or a range which doesn't chronologically follow the
      previously appended range. Everyone who wants to do manual stream
      switching has to get this right, but if it's implemented
      in-browser, it only needs to be gotten right once.
   3. It's easier for a browser to get the transition between two
      streams consistently seamless than it is for user JS to, since we
      have more information and more control over the network and decode.


I'd much rather that the browser fetched the indexes of all streams on 
startup (probably asynchronously) and played a default stream as per 
normal. If manual switching was enabled, then upon a call to setLevel(), 
the video would switch to the requested stream at an appropriate time. 
We'd probably want to start rendering the new stream as soon as 
possible, as we could be switching down due to dropping too many frames 
due to the decode not keeping up with rendering.


Chris P.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20101108/c4c555cc/attachment.htm