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

[Robert O'Callahan]

On Thu, Jul 14, 2011 at 4:35 AM, Aaron Colwell <acolwell at google.com> wrote:

> 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.


OK, I sorta get the idea. I think you're defining a new interface to the
media processing pipeline that integrates with the demuxer and codecs at a
different level to regular media resource loading. (For example, all the
browser's built-in logic for seeking and buffering would have to be disabled
and/or bypassed.) As such, it would have to be carefully specified,
potentially in a container- or codec-dependent way, unlike APIs like Blobs
which work "just like" regular media resource loading and can thus work with
any container/codec.

I'm not sure what the best way to do this is, to be honest. It comes down to
the use-cases. If you want to experiment with different seeking strategies,
can't you just do that in Chrome itself? If you want scriptable adaptive
streaming (or even if you don't) then I think we want APIs for seamless
transitioning along a sequence of media resources, or between resources
loaded in parallel.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not in
us. If we confess our sins, he is faithful and just and will forgive us our
sins and purify us from all unrighteousness. If we claim we have not sinned,
we make him out to be a liar and his word is not in us." [1 John 1:8-10]