[whatwg] File API Streaming Blobs

Comments inline...

On Wed, Aug 10, 2011 at 2:05 PM, Charles Pritchard <chuck at jumis.com> wrote:

>  On 8/9/2011 9:38 AM, Aaron Colwell wrote:
>
> FYI I'm working on an experimental extension to Chromium to allow media
> data to be streamed into a media element via JavaScript. Here is the draft
> spec<http://html5-mediasource-api.googlecode.com/svn/tags/0.2/draft-spec/mediasource-draft-spec.html> and
> pending WebKit patch <https://bugs.webkit.org/show_bug.cgi?id=64731> related
> to this work. I have simple WebM VOD playback w/ seeking working where all
> media data is fetched via XHR.
>
>
> It's nice to see this patch.
>
>
Thanks. Hopefully I can get it landed soon so people can start playing with
it in Chrome Dev Channel builds.


> I'm hoping to see streamed array buffers in XHR, though fetching in chunks
> can work,
> given the relatively small overhead of HTTP headers vs Video content.
>
>
Eventually I'd like to see streamed array buffers in XHR. For now I'm just
using range requests and allowing the JavaScript code determine how large
the ranges should be to control overhead.


> The WHAWG specs have a Media Stream example which uses URL createObjectURL:
> navigator.getUserMedia('video user', gotStream, noStream);
> function gotStream(stream) {
>     video.src = URL.createObjectURL(stream);
>
> http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html#dom-mediastream
>
> The WHATWG spec seems closer to (mediaElement.createStream()).append()
> semantics.
>

There was a previous discussion about this on WHATWG. There was concern
about providing compressed data to a MediaStream object since they are
basically format agnostic right now.


> Both WHATWG and the draft spec agree on src=uri;
>
>
The benefit of src=uri is that it allows you to leverage all the existing
state transition and behavior defined in the spec.


> File API has to toURL semantics on objects, simlar to the draft spec, for
> getting filesystem:// uris.
>
> My understanding: The draft spec is simpler, intended only to be used by
> HTMLMediaElement
> and only by one element at a time, without introducing a new object. In the
> long
> run, it may make sense to create a media stream object, consistent with the
> WHATWG direction.
>

The draft spec was intended to be as simple as possible. Attaching this
functionality to HTMLMediaElement instead of
creating a MediaStream came out of discussions on whatwg
here<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032283.html>
 and here<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032384.html>.
I'm definitely open to revisiting this, but I got
the feeling that people wanted to see a more concrete implementation first.
I also like having this functionality part of
HTMLMediaElement because then I only have to deal with the HTMLMediaElement
during seeking instead of having to coordinate behavior
between the MediaStream & the HTMLMediaElement.


>
> On another note, Mozilla Labs has some experiments on recording video from
> <canvas> (as well as general webcam, etc):
> https://mozillalabs.com/rainbow/
> https://github.com/mozilla/rainbow
> https://github.com/mozilla/rainbow/blob/master/content/example_canvas.html
>
>
I'll take a look at this.

Aaron

Received on Thursday, 11 August 2011 10:45:56 UTC