- From: Aaron Colwell <acolwell@google.com>
- Date: Tue, 12 Jul 2011 13:45:48 -0700
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
Received on Tuesday, 12 July 2011 13:45:48 UTC