[whatwg] Proposal for a MediaSource API that allows sending media data to a HTMLMediaElement

[Aaron Colwell]

On Tue, Jul 12, 2011 at 5:05 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 12:00 PM, Aaron Colwell <acolwell at google.com>wrote:
>
>> On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> I had imagined that this API would let the author feed in the same data
>>> as you would load from some URI. But that can't be what's happening, since
>>> in some element implementations (e.g., Gecko's) loaded data is buffered
>>> internally and seeking might not require any new data to be loaded.
>>>
>>>
>>  No. The idea is to allow JavaScript to manage fetching the media data so
>> various fetching strategies could be implemented without needing to change
>> the browser. My initial motivation is for supporting adaptive streaming with
>> this mechanism, but I think various media mashup and delivery scenarios
>> could be explored with this.
>>
>
> I don't think you can do that with this API without making huge assumptions
> about what the browser's demuxer, internal caching, etc are doing.
>
>
I am open to suggestions. My intent was that the browser would not attempt
to cache any data passed into append(). It would just demux the buffers that
are sent in. When a seek is requested, it flushes whatever it has and waits
for more data from append().  If the web application wants to do caching it
can use the WebStorage or File APIs. If the browser's media engine needs a
certain amount of "preroll" data before it starts playback it can signal
this explicitly through new attributes or just use HAVE_FUTURE_DATA
& HAVE_ENOUGH_DATA readyStates to signal when it has enough.

Aaron