RE: Mediastream Recording implementation

In the Blob vs. ArrayBuffer discussion... there is a lot of room for implementation details on how the data can be paged in and out of memory on demand. Certainly not all the data need be in memory initially with either return type. The Blob does require a bit more work to begin addressing it if in-memory manipulation of the data is your goal (this usually involves Blob->ArrayBufferView); if your goal is to simply send the data along to a server via XHR, then Blob is convenient, because the mimeType can travel along with the data easily. I don't know that we ever pinned down the question about what the mimeType will be though.

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Tuesday, July 16, 2013 12:19 PM
To: Greg Billock
Cc: public-media-capture@w3.org
Subject: RE: Mediastream Recording implementation

Greg,
You did a better job searching than I did  (I poked around but never found that email).  I'm certainly willing to re-open the discussion on this issue, but I'd like to hear  from others.  Travis and Robert?  You were part of the discussion last time.


-          Jim

From: Greg Billock [mailto:gbillock@google.com]
Sent: Tuesday, July 16, 2013 2:53 PM
To: Jim Barnett
Cc: public-media-capture@w3.org<mailto:public-media-capture@w3.org>
Subject: 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<mailto: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<mailto:Jim.Barnett@genesyslab.com>> wrote:


From: Greg Billock [mailto:gbillock@google.com<mailto:gbillock@google.com>]
Sent: Tuesday, July 16, 2013 12:49 PM
To: public-media-capture@w3.org<mailto: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<mailto: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<mailto:mike@w3.org>> wrote:
Dominique Hazael-Massieux <dom@w3.org<mailto: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