Re: Feedback on the recording proposal

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.

/Adam

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