W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2011

MediaStreamRecorder ideas

From: ᛏᚮᛘᛘᚤ <tommyw@google.com>
Date: Thu, 8 Dec 2011 13:35:59 +0100
Message-ID: <CALLKCfMv3Hw92PGvGFXuZ-iPnuPjtq5EP1s9KKXF9=dogvB9ng@mail.gmail.com>
To: public-webrtc@w3.org, public-media-capture@w3.org
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.
Received on Thursday, 8 December 2011 12:36:29 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:14:58 GMT