W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [whatwg] File API Streaming Blobs

From: Aaron Colwell <acolwell@chromium.org>
Date: Thu, 11 Aug 2011 10:45:56 -0700
Message-ID: <CAA0c1bAc2XFBr0SQJgOM1CPTh6_WSXEAP1ytvWTk=-9RsVxrXQ@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Glenn Maynard <glenn@zewt.org>, Simon Heckmann <simon@simonheckmann.de>, WHATWG <whatwg@lists.whatwg.org>, "WEBAPPLICATIONS (WEBAPPS) WORKING GROUP" <public-webapps@w3.org>, Eric U <ericu@google.com>, "arun@mozilla.com" <arun@mozilla.com>, Adam Malcontenti-Wilson <adman.com@gmail.com>
Comments inline...

On Wed, Aug 10, 2011 at 2:05 PM, Charles Pritchard <chuck@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 22:30:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT