W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2012

Re: approaches to recording

From: Timothy B. Terriberry <tterriberry@mozilla.com>
Date: Wed, 17 Oct 2012 08:08:27 -0700
Message-ID: <507EC9EB.7020706@mozilla.com>
To: public-media-capture@w3.org
Jim Barnett wrote:
> Implicitly, at least, there are two APIs: one for streaming and one for file-level recording.  If we're doing streaming recording on a MediaStream, and new Tracks get added, do we ignore them or signal an error?  What do we do if Tracks get removed?  Signal an error or fill in with black frames/silence?

I think the easiest thing to do is ignore new tracks. I.e., just say the 
track list is fixed at the time you start recording. If you want to add 
video to a call, for example, you can always stop recording at the 
application level and re-start it after you've added the track. I think 
that works most cleanly with the idea of a StreamRecorder object that is 
separate from the MediaStream object, since otherwise you need the 
MediaStream.addStream method to throw an error just because a 
StreamRecorder object happens to exist, which seems clunky, to say the 

After a track gets removed, I think we should just repeat the last video 
frame and/or pad with silence. We will have to do this anyway for DTX 
(discontinuous transmission), because non-RTP-based media players don't 
know how to deal with that.
Received on Wednesday, 17 October 2012 15:08:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:12 UTC