Re: Mediastream Recording implementation

Thanks, Jim. Here's what I found with that hint:
http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/0093.html

To summarize, the argument is that Blob needn't be in-memory, and so the
implementation can store it on disk in the case of very large encoded
outputs from a recording process.

That's a good argument. The other way of thinking about this is that for
sliced data (currently driven by the time slicing parameter on record, but
could also in principle be governed with that guidance by the encoder
itself) the recorder should present in-memory data and put the burden of
saving it persistently onto the ondataavailable consumer.

Looking at the requirements, I don't see low-latency transmission of
encoded output to remote locations while the recording is running. That
does seem like a valuable goal, however, so long as it doesn't impair other
requirements. Another option: XHR2 has both ArrayBuffer and Blob type
productions. Perhaps that's suitable for this API as well...


cowwoc:

> Was this portion of discussion moved to public-webrtc@w3.org? If not, did
you mean to ask whether we plan to use DOM Promises in the Media Capture
API?

I saw responses here on public-media-capture. I saw the minutes from the
call on the issue.




On Tue, Jul 16, 2013 at 9:57 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>  ** **
>
> ** **
>
> *From:* Greg Billock [mailto:gbillock@google.com]
> *Sent:* Tuesday, July 16, 2013 12:49 PM
> *To:* public-media-capture@w3.org
>
> *Subject:* Re: Mediastream Recording implementation****
>
>  ** **
>
> A question that's come up in the discussions on blink-dev: what kinds of
> Blob-inherent capabilities are intended to accrue to the output data in the
> mediastream recorder API?****
>
> ** **
>
> In Chrome, we manage Blobs in the browser process, which is good for doing
> Blob-powered things like taking and exchanging URLs, sharing the data to
> workers, and such, but will impose a cost for handling the data if no such
> Blob-inherent things are being used. I wondered whether ArrayBuffer might
> be closer to the intended semantics for the encoded stream. Has this
> already been discussed here?****
>
> ** **
>
> >> It has been, and someone had what seemed like a good argument against
> ArrayBuffer (and in favor of Blob), but unfortunately I can’t remember what
> it was.  Sorry that I can’t be of more help.  ****
>
> **-          **Jim****
>
> On Fri, Jul 12, 2013 at 8:55 AM, Greg Billock <gbillock@google.com> wrote:
> ****
>
> Yes, we're going to be starting work on this soon. (I've joined
> public-media-capture to keep up with developments)****
>
> ** **
>
> What was the outcome of the call discussing webrtc API and Promises? Any
> conclusions in that direction?****
>
> ** **
>
> -Greg Billock****
>
> ** **
>
> ** **
>
> On Fri, Jul 12, 2013 at 5:49 AM, Michael[tm] Smith <mike@w3.org> wrote:***
> *
>
> Dominique Hazael-Massieux <dom@w3.org>, 2013-07-10 16:23 +0200:****
>
>
> > A quick note that our Mediastream recording API has gotten a first (?)
> > implementation, in Firefox (available in Nightly):
> >
> http://firefoxnightly.tumblr.com/post/54915551771/audio-recording-window-mediarecorder-has-landed
> > https://bugzilla.mozilla.org/show_bug.cgi?id=803414****
>
> Seems there's also work started to implement it in Blink -
>
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2l_G_apqk30
>
> --
> Michael[tm] Smith http://people.w3.org/mike****
>
> ** **
>
> ** **
>