Comments inline... On Wed, Aug 10, 2011 at 2:05 PM, Charles Pritchard <ch...@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
