RE: approaches to recording

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]],
                                  "audio/wav");

/Adam

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