Feedback on the recording proposal

I liked the old StreamRecorder proposal that had a MediaStream.record()
method returning a StreamRecorder object with the rest of the API on the
StreamRecorder object. That supported multiple recordings that don't
interfere with each other, which seems like a good idea and is no more
complex to implement or use. If you do that, you don't need a "recording"
boolean.

I think the API should be attached to MediaStreams, not tracks, for the
reasons Harald mentioned. A key use-case is to record synchronized video
and audio and that's trivial to support if you record MediaStreams. If you
want to record just one track, you can construct a MediaStream around that
one track and record it.

I think allowing dynamic changes to the recording format isn't a great
idea, so I would suggest that the format should be a parameter to record().
Since we'll probably grow a number of optional parameters to record(), I
suggest having record() take an optional WebIDL dictionary containing its
parameters.

Does the last dataavailable event happen before or after the stoprecording
event? I guess it should be "before".

The proposal doesn't say what the format strings mean. It might be a good
idea to simply have a single format string which is the MIME type of the
resulting blob, with the MIME codec parameters optionally provided. You
could have a MediaStream.canRecordType() method, analogous to
HTMLMediaElement.canPlayType(), to check for format support. Then the
format parameter to record() could be a single MIME type string; we could
require that the implementation produce a Blob with that MIME type or fail
with an error. This may mean having to discard some tracks. If no MIME type
is provided, the UA gets to choose the type. Note that if we do it this
way, the API can record streams that contain tracks other than audio and
video, e.g. subtitles.

I agree with the proposal that when the track is paused, recording should
be paused. If we want to allow "filler", then I think we should define a
way to construct a wrapper MediaStream that never pauses and automatically
fills while its input MediaStream is paused.

Jim Barnett wrote:

> When the media capture group discussed the issue before (in the context
> of the use cases document) we decided that recording and media
> processing were the same use case, since they were both based on
> "capturing the media in known format".
>
>
I don't think this is true in general. General audio processing requires
real-time processing and demands features like the ability to access and
process raw samples off the Javascript main thread with low latency. Video
processing has even more complex requirements. I don't think those
requirements should be imposed on a recording API.

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]