W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

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

From: Aaron Colwell <acolwell@google.com>
Date: Tue, 12 Jul 2011 16:14:27 -0700
Message-ID: <CAA0c1bBYM0gyLiJNx=fV8n2QqHfAbRUj5ccL1JpzuZKGfqRFNw@mail.gmail.com>
On Tue, Jul 12, 2011 at 3:28 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Jul 13, 2011 at 8:45 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> 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.
>>
>
> I was thinking more of putting the MediaSource functionality
> (open/append/close) on the media element itself.
>

I'm open to that. In fact that is how my current prototype is implemented
because it was the least painful way to test these ideas in WebKit. My
prototype only implements append() and uses existing media element events as
proxies for the events I've proposed. I only separated this out into a
separate object because I thought people might prefer an object to represent
the source of the media and leave the media element object an endpoint for
controlling media playback.


>
> Do you need to support seeking in with this API? That's hard. It would be
> simpler if we didn't have to support seeking. Instead of seeking you could
> just open a new stream and pour data in for the new offset.
>

 I'd like to be able to support seeking so you can use this mechanism for
on-demand playback. In my prototype seeking wasn't too difficult to
implement. I just triggered it off the seeking event. Any append() that
happens after the seeking event fires is associated with the new seek
location. currentTime is updated with the timestamp in the first cluster
passed to append() after the seeking event fires. Once the media engine has
this timestamp and enough preroll data, then it will fire the seeked event
like normal. I haven't tested this with rapid fire seeking yet, but I think
this mechanism should work.

Aaron
Received on Tuesday, 12 July 2011 16:14:27 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:34 UTC