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