RE: MediaStreamRecorder ideas

Let me translate this into a set of requirements:
A. The ability to stop a recording independently of retrieving the recorded data
B. Stop recordings automatically when MediaStreams end
C. Circular buffer for size time/limitation
D. Indicate the recording format with a MIME type
E. Use a File (rather than Blob) for recording output.
F. peek() to be able to extract recorded data so far without stopping the recorder.

May I suggest one more based on your points below:
G. Ability to discover what recording MIME types are available in the UA

I'm totally behind A, B, & D, as these just seem obvious to me.

Followup questions:
* Can you think of any scenarios that would necessitate C, other than UA size limitations? It seems like circular buffers are great for DVR scenarios, but you'd need a lot more ability to control the output (like seek support). Many of these scenarios are already supported by <video>--can we find a way to make them work together?
* Why File? Over Blob, a File adds "name" and "lastModifiedDate". What will the "name" be? It seems unnecessary since you'd need a way of naming the recording when you extract it, or before you start recording. For "lastModifiedDate" the recording is conceptually "in memory" and not necessarily committed to disk (though implementations will likely record to disk in a temp location, since recordings can be very large).
* As I've mentioned before, making the recording output a Stream [1] solves requirement F, since you can get the immediate recorded stream, and "collect" it into a Blob, and/or slice it up as desired.

[1] http://dvcs.w3.org/hg/webapps/raw-file/tip/StreamAPI/Overview.htm


-Travis

From: Tommy Widenflycht (ᛏᚮᛘᛘᚤ) [mailto:tommyw@google.com]
Sent: Thursday, December 08, 2011 4:36 AM
To: public-webrtc@w3.org; public-media-capture@w3.org
Subject: MediaStreamRecorder ideas

In my not-so-humble opinion the MediaStreamRecorder isn’t usable right now, and the API needs to be changed. I suggest the following changes as a minimum delta:

  1.  MediaStreamRecorder should have a stop() method. Calling this will stop the recorder but not throw away the data, the data will live until the recorder is garbage collected. If the associated MediaStream stops/ends the recorder should do so as well. Also the UA should be allowed to have a maximum file size/time length and be allowed to throw away the oldest data circular buffer style.
  2.  MediaStream::record should take a optional MIME type (which may have parameters). If no MIME type is given the UA can pick whatever is most suitable, but if a MIME type is given it must be used. If the UA doesn’t support the type or recording in general it should return a null pointer.
  3.  MediaStreamRecorder::getRecordedData should return a File (instead of a Blob) and stop recording. MediaStreamRecorder will optionally support a peek() method that will return a Blob of the data recorded this far. This will make life easier for weaker UAs.
Thoughs?

/Tommy

--
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU law.