RE: Generic media recording proposal

Travis Leithead
<travis.leithead@microsoft.com><travis.leithead@microsoft.com>wrote:

> >-----Original Message-----
> >From: Harald Alvestrand [mailto:harald@alvestrand.no <harald@alvestrand.no>]
> >On 12/08/2011 06:50 PM, Travis Leithead wrote:
> >> What is the group's thoughts on creating a recorder interface that could
> >>be used for more than just MediaStreams? For example, it seems like it
> >>might be neat to be able to record a<video>  or<audio>  tag, or record
> >>video from an animating<canvas>?
> >>
> >> If this sounds like an interesting scenario for future extension, I would
> >>suggest that the "recording" capability be logically separated from the
> >>MediaStream.
> >
> >I am in favour of the separation, but that's because I think the
> >functionality is not needed for the main purposes of MediaStream, which
> >makes it strange to require implementations to have it.
> >
> >I would prefer to think of those different recording sources as
> >producing a MediaStream that can be consumed by a Recorder, though. It
> >decreases the amount of required linkage.
>
> In other words, should those different sources wish to support recordings, they would need to add an API to "extract" a MediaStream object that could then be presented to a Recorder, correct? This does appear to decrease the potential for linkage or extension required to a Recorder interface such as the one previously described.
>
>
In my StreamProcessing proposal I've already proposed APIs to enable
capturing of media elements and canvases to MediaStreams.
https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html

It seemed useful to me to create a single Recorder instance based on a
MIME type/quality inputs, and then to be able to use that instance to
record a variety of things. That would imply that the Recorder
instance could be re-used (support setSource() multiple times);
otherwise, the Recorder is one-time use, and you may as well specify
the source in the Constructor as a required parameter.
>
>
With ProcessedMediaStream you could support just a single stream input, and
authors could multiplex different inputs into that single recorded stream,
with sample-accurate scheduling of the changes in inputs. With a
main-thread setSource() API, you can't get accurate transitions from one
input to another.

The scenario that is not possible with a one-time-use Recorder is
recording segments of a MediaStream into one contiguous file (not
recording the gaps between the time that stop() is called and start()
is called). For example, if your capture device reports periods of
silence on an audio track, you could stop and start the audio
recording to trim out the silence gaps in a conversation (or
commercials in a video stream as another example).
>
>
Right. ProcessedMediaStream combined with a StreamRecorder would solve that.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]