W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2012

Re: Feedback on the recording proposal

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 9 Oct 2012 13:11:41 +0200
Message-ID: <5074066D.6080408@ericsson.com>
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2012-10-09 07:13, Robert O'Callahan wrote:
> I liked the old StreamRecorder proposal that had a MediaStream.record()
> method returning a StreamRecorder object with the rest of the API on the
> StreamRecorder object. That supported multiple recordings that don't
> interfere with each other, which seems like a good idea and is no more
> complex to implement or use. If you do that, you don't need a
> "recording" boolean.

I think it would be nice to have the recording API in a separate 
interface. The old API had some issues but I agree that the record() 
method that returned the MediaStreamRecorder worked pretty well.

> I think the API should be attached to MediaStreams, not tracks, for the
> reasons Harald mentioned. A key use-case is to record synchronized video
> and audio and that's trivial to support if you record MediaStreams. If
> you want to record just one track, you can construct a MediaStream
> around that one track and record it.

I agree.

> Does the last dataavailable event happen before or after the
> stoprecording event? I guess it should be "before".

What if the data (on some platforms) needs to undergo some processing 
before it can be handed to the application as a Blob. Shouldn't 
"stoprecording" fire when the recording is actually stopped and then 
"dataavailable" when the Blob is available.

Received on Tuesday, 9 October 2012 11:12:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:12 UTC