RE: approaches to recording

Are the browser vendors comfortable recording varying sets of tracks?  From what Travis said it sounded like Microsoft wasn't.  Would people from Google, Mozilla or Opera like to offer an opinion?  

- Jim

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

I'm not that keen on adding a recording API on both stream and track level. I'm more into the approach with a separate MediaRecorder that accepts both a list of MediaStreamTrack objects as well as a MediaStream (as Robert suggests below). The track list is really be the easy case since no other tracks can appear after the recording has started. It would be a difference compared to collecting a set of tracks in a new MediaStream and pass that to the recorder.

The previous proposal mentioned additional functionality to merge separately recorded tracks into one unit. Adding a list of tracks to a recorder would do that automatically.

/Adam

On 2012-10-15 15:24, Jim Barnett wrote:
> 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 17:35:10 UTC