[foms] Proposal: adaptive streaming using open codecs
chris at pearce.org.nz
Sun Nov 7 19:37:01 PST 2010
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foms