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?



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
>>
>>
>