RE: recording

Thanks for the proposal.

Record can not take mediastreamtrack as argument?

Suggest to combine startCapture/startRecording, no distinguished difference, we may use different argument in this method to control whether incremental or all-at-once. The same with stopCapture/stopRecord.

For the codecs, I think let the UA to test and fire a error event if it does not support the decodecs of the stream.

Yang
Huawei

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
Sent: Tuesday, November 13, 2012 3:43 AM
To: public-media-capture@w3.org
Subject: recording

Here's a summary of what I think we agreed to in Lyon.  If we still agree to it, I will start writing it up.  (Please send comments on any or all of the points below.)

Recording should be implemented by a separate class.  Its constructor will take a MediaStream as an argument  (we can define it to take other types as well, if we choose, but no one is suggesting any at the moment.)

There are two kinds of recording:

1)      incremental, in which (smaller) Blobs of data are returned to the application as they are available.

2)      All-at-once, in which one big Blob of data is made available when recording is finished.

There will be different methods for these types.  To make a distinction, I will call type 1 'capture' and type 2 'recording'  (I tend to think of 'recording' as producing one big file, while 'capture' sounds more incremental).

To do incremental recording, the app calls startCapture(bufferSize), where bufferSize specifies the number of milliseconds of data it wants to receive in each Blob.  The Blobs are made available in  dataavailable events (with an ondataavailable handler to extract/process the data.)  Capture continues until the MediaStream is ended or the app calls stopCapture.  When this happens it receives  a final dataavailable event, and then a captureDone event (which indicates that no further data will be available.)  While capture is going on, the app can also call getData, which causes the UA to generate a dataavailable event containing all the data that it has gathered since the last dataavailable event.  (The app can use getData to do polling on its own schedule if it doesn't want to rely on a fixed buffer size.  It would have to set 'bufferSize' to a very large value in this case.)

To do all-at-once recording, the app calls startRecording, which returns immediately.   The UA accumulates data until the MediaStream is ended or the app calls stopRecording.  At that point a single recordingDone event is generated which contains a Blob with all the accumulated data.

It is an open question whether an app can make overlapping calls to startCapture and startRecord.  We can define it either way.

There will be methods to read and set the UA's recording options.  Details are TBD but at the least the app would be able to choose among the available recording/container formats (if the UA supports more than one.)

There were a couple of issues left open in the discussion.  The first was whether there would be an MTI format.  It seems to me that at the very least we would want to require that the UA be able to play back any format that it can record/capture to.  I think that it would also make sense to require that the UA support a format/container allowing it to record/capture at least 2 simultaneous video and 2 audio streams (i.e. both legs of an simple peer-to-peer audio+ video call).   If we can agree on an MTI format that allows this, so much the better (but I don't have one to propose.)

The second open issue was the definition of errors.  There wasn't any consensus on a set of errors that we should define, and many people seemed to think that different platforms might raise errors under different conditions, depending on their underlying capabilities.  Whatever we decide to do, it seems to me that there are two cases that we should distinguish.  Some errors are fatal, in that recording cannot continue (running out of memory would be an example.)  In this case, the UA should raise an Error, followed by dataavailable and captureDone (in the capture case) or recordingDone (in the recording case.)  In other cases, recording may be able to continue, though the results may not be what the app is expecting.  The best example of this that came up during discussion was adding a Track while capture was underway.  Platforms may not be able to do this, but could continue capturing the original set of Tracks.  In this case, perhaps the UA should raise a Warning event, indicating "I'm still recording, but it's probably not what you want." It would be up to the App to decide whether to stop capture or let it continue.


-        Jim