[whatwg] Proposal for a MediaSource API that allows sending media data to a HTMLMediaElement
Aaron Colwell
acolwell at google.com
Tue Jul 12 17:00:58 PDT 2011
On Tue, Jul 12, 2011 at 4:44 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
> On Wed, Jul 13, 2011 at 11:30 AM, Aaron Colwell <acolwell at google.com>wrote:
>
>> I'm doing WebM demuxing and media fetching in JavaScript. When a seek
>> occurs, I look at currentTime to see where we are seeking to. I then look at
>> the CUES index data I've fetched to find the file offset for the closest
>> seek point to the desired time. The appropriate data is fetched and pushed
>> into the element via append(). The seeked event firing and readyState
>> transitioning to HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA tells me when I've
>> sent the element enough data. During playback I just monitor the buffered
>> attribute to keep a specific duration ahead of the current playback time.
>
>
> Now I'm rather confused about what you're doing and how you're using this
> feature. What format is the data that you're feeding into the element?
>
Sorry I wasn't clear about my intent. Currently I'm feeding it WebM. I could
see this expanding to Ogg and perhaps MP4. Theoretically any format that
looks like a packet stream could work.
>
> 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.
Aaron
More information about the whatwg
mailing list