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

[Aaron Colwell]

On Mon, Jul 11, 2011 at 5:54 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> It seems to me that the spec is written assuming only one media element is
> consuming the MediaSource. But nothing stops multiple elements consuming the
> same URL simultaneously. Maybe instead of going through a URL you should add
> API directly to media elements.
>

You are right that I don't have anything preventing the MediaSource URL from
being passed to multiple media elements. Only one media element will accept
the URL though because whichever one opens the URL first will transition the
source to the OPEN state. Media elements can only open sources in the CLOSED
state. I'm using a URL for initialization to be consistent with how the
media element is initialized in all other cases. I didn't want to create a
new initialization path.

I thought about adding an attribute to HTMLMediaElement that provided a URL
for signalling MediaSource usage. That mechanism would allow you to create a
URL that only works with that element. When this URL is specified, a
MediaSource attribute would be updated on the media element during loading
and JavaScript could use that to pass data to the tag. I couldn't find a
similar pattern in other APIs so I didn't take that path. If people think
that is a better route then I'm all for it.



> bytesAvailable is for flow control? Instead of doing it this way, I would
> follow WebSockets and use a bufferedAmount attribute to indicate how much
> data is currently buffered up. That makes it easy for authors who don't want
> to care about flow control to just append stuff without encountering errors,
> while still allowing authors who care about flow control to do it.
>
>
Yes. The intent was to provide a way for the browser to control how much
data was being pushed into it. It looks like WebSocket will just close the
connection if it doesn't have enough buffer space and the API doesn't appear
to provide a mechanism to predict how much buffered data will trigger a
close. Do we want similar semantics for media? It seems like the browser
should provide some hints to indicate that it is not ok to push hours/days
of data into this interface.

Thanks for your comments.

Aaron