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 13:39:13 UTC