[foms] Proposal: adaptive streaming using open codecs

Christopher Blizzard blizzard at mozilla.com
Mon Nov 8 13:54:24 PST 2010


On 11/8/2010 1:29 PM, Mark Watson wrote:
> How you specify what you want in the appendVideo call, and how the browser loads it are somewhat independent. The browser could use small byte range requests or a single open-ended request: the instructions from the JS layer are about what to play, not exactly how to fetch it.

OK, to put this in a set of requirements in order to contain scope:

* The ability to pass already de-muxed but encoded audio & video into 
the video element for playback.
* That data can be from an HTTP download and exposed as an XHR result 
and then passed into the video element.  Data could also come from a 
WebSocket connection, or somewhere else.
* The ability to mark some audio data as "might contain gaps" so the 
audio layer can do the right thing when skipping from one stream to another.

This means that the JS code is required to actually figure out how to 
get the data, what the rate of the next chunk will be and which type of 
audio stream to use.  It also means that the JS code needs to know how 
to handle the index, how to seek, etc.  I think that it offers some 
great opportunities for fast start and to start experimenting with 
WebSockets for streaming as well.

What Chris is proposing is different, and higher level, and makes 
assumptions about formats and how things will be chunked on the server.  
(Or at least how a custom server will translate byte requests into 
mappings into files.)

The idea here is that once we have some best practices we can talk about 
a higher level format that specifies how a client could do the right 
thing about switching rates in the simple-for-the-developer case.  But I 
feel like we need to learn how things will work based on a lower-level 
API.  The use case of a standalone player matters to me, and I want to 
make sure we don't lose that over the long term.

But this is also worth doing because we want the lower-level API anyway.

Chris, this is pushing back on what you are suggesting, so I want to 
hear what you think.

--Chris


More information about the foms mailing list