Re: approaches to recording

On Thu, Oct 11, 2012 at 4:28 AM, Jim Barnett <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.

It would be easy to add other features to the Recorder.  For example, most
> recordings are stored as files.  The Recorder object could be configured
> with a  URL and automatically right the recording to that URL once it was
> finished.  (I suppose that it could also be configured to stream the
> recording to the URL as it was created.)
>

It seems to me that most developers of sophisticated applications, which
any stream-recording application would be, prefer to manage data delivery
themselves. Streaming data chunks across a WebSocket or via XHR is easy, so
I think we could omit direct URL streaming.


> There could  also be a configuration item specifying whether multiple
> audio tracks were to be merged or recorded separately.    Most of these
> options should  probably be provided as a Dictionary at construction time
> since we would not want them changed while recording was going on.
>

We might want to do this in a more general way, such as a MediaStream
constructor that mixes together the audio tracks of an incoming
MediaStream, because this functionality would be useful for other
MediaStream consumers.

There would need to be a distinct interface, probably similar to the
> existing proposal, to handle media capture and media processing at the
> Track level.
>

I've already argued that we shouldn't mix client-side media processing in
here.

Rob
-- 
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]