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

RE: approaches to recording

From: Jim Barnett <Jim.Barnett@genesyslab.com>
Date: Mon, 15 Oct 2012 06:24:40 -0700
Message-ID: <E17CAD772E76C742B645BD4DC602CD8106CE0523@NAHALD.us.int.genesyslab.com>
To: "Adam Bergkvist" <adam.bergkvist@ericsson.com>, <robert@ocallahan.org>
Cc: <public-media-capture@w3.org>
I'm sensing a groundswell of opinion that the Recording API has to be located close to the track level.  A list of Tracks is rather different than a MediaStream...

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Monday, October 15, 2012 9:20 AM
To: robert@ocallahan.org
Cc: Jim Barnett; public-media-capture@w3.org
Subject: Re: approaches to recording

On 2012-10-10 23:50, Robert O'Callahan wrote:
> On Thu, Oct 11, 2012 at 4:28 AM, Jim Barnett 
> <Jim.Barnett@genesyslab.com <mailto:Jim.Barnett@genesyslab.com>> wrote:
>     The upshot of yesterday’s discussion is that there is interest in
>     two different approaches to recording, so I’d like  to start a
>     discussion of them.  If we can reach consensus on one of them, we
>     can start to write things up in more detail.
> Was this discussion minuted somewhere?
>     /_Proposal 2. _/Create a separate Recorder object that would serve
>     as a destination/sink for  MediaStream.  (I gather that there’s
>     already been a proposal along these lines – I’d appreciate it if
>     someone would send me a copy.) The configuration of this object
>     would determine what the MediaStream was allowed to do.  For
>     example, the application would create a Recorder object designed to
>     handle a certain number of audio and video tracks.  If the platform
>     could not support that number, the error would be raised when the
>     Recorder was created/configured, not once recording was underway.
>     If creation of the Recorder succeeds but the MediaStream attempts to
>     exceed the configured number of audio or video tracks, either an
>     error would be raised or the extra Tracks would be ignored
> If the UA can handle an unlimited number and kind of tracks in the 
> recorder (which isn't all that hard, assuming a reasonable container 
> format), then this would just create a burden for Web authors with no 
> benefit. So I don't think we should always require authors to specify 
> track limits up front.
> One option would be to have two APIs to initialize the recorder: one 
> which takes a MediaStream, and one which takes a list of 
> MediaStreamTracks. The former has the possibility of new tracks being 
> added dynamically, and the latter does not. The UA could reject 
> requests if the format doesn't support the specified tracks, or if the 
> format doesn't support addition of tracks and the author passed in a MediaStream.
> However, I don't think that's a great option. It means that an author 
> who gets a MediaStream via getUserMedia("audio") or via a media 
> element that they know very well is only playing audio can't easily 
> record that stream to a WAV file for example. It makes more sense to 
> me to take an optimistic approach; if tracks can't be handled by the 
> recorder, it should just ignore those tracks and fire events to 
> indicate that they were dropped.

If the recorder could be created with a list of tracks it would be pretty easy to specify exactly what you want to record.

var recorder = new MediaRecorder([audioOnlyStream.audioTracks[0]],

Received on Monday, 15 October 2012 13:25:59 UTC

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