Re: Feedback on the recording proposal

On Oct 8, 2012, at 22:13 , Robert O'Callahan <robert@ocallahan.org> 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 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.

+1

> 
> I think allowing dynamic changes to the recording format isn't a great idea, so I would suggest that the format should be a parameter to record(). Since we'll probably grow a number of optional parameters to record(), I suggest having record() take an optional WebIDL dictionary containing its parameters.

can you say a bit more about what the recording formats would be?

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

Seems like it has to happen after so you get all the data 

> 
> The proposal doesn't say what the format strings mean. It might be a good idea to simply have a single format string which is the MIME type of the resulting blob, with the MIME codec parameters optionally provided. You could have a MediaStream.canRecordType() method, analogous to HTMLMediaElement.canPlayType(), to check for format support. Then the format parameter to record() could be a single MIME type string; we could require that the implementation produce a Blob with that MIME type or fail with an error. This may mean having to discard some tracks. If no MIME type is provided, the UA gets to choose the type. Note that if we do it this way, the API can record streams that contain tracks other than audio and video, e.g. subtitles.
> 
> I agree with the proposal that when the track is paused, recording should be paused. If we want to allow "filler", then I think we should define a way to construct a wrapper MediaStream that never pauses and automatically fills while its input MediaStream is paused.
> 
> Jim Barnett wrote:
> When the media capture group discussed the issue before (in the context
> of the use cases document) we decided that recording and media
> processing were the same use case, since they were both based on
> "capturing the media in known format".
> 
> 
> I don't think this is true in general. General audio processing requires real-time processing and demands features like the ability to access and process raw samples off the Javascript main thread with low latency. Video processing has even more complex requirements. I don't think those requirements should be imposed on a recording API.

I agree that media processing has timing latency constraints that recording does not. But that seems like recording is a subset of media processing. It might be that if we had a media processing API, we would decide that API was fine for recording. 

I guess the key thing to me is the media processing API is far more important than the recording API for the applications I  want to do


> 
> Rob
> -- 
> “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others?" [Matthew 5:43-47]

Received on Tuesday, 9 October 2012 17:02:46 UTC