Re: Feedback on the recording proposal

On Wed, Oct 10, 2012 at 6:02 AM, Cullen Jennings <fluffy@iii.ca> wrote:

> On Oct 8, 2012, at 22:13 , Robert O'Callahan <robert@ocallahan.org> wrote:
> > 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.
>
> can you say a bit more about what the recording formats would be?
>

That's an orthogonal issue to the dictionary, but I addressed it later in
my message --- I think we should use MIME types.

I agree that media processing has timing latency constraints that recording
> does not. But that seems like recording is a subset of media processing. It
> might be that if we had a media processing API, we would decide that API
> was fine for recording.
>

I think the key feature of stream recording is that it exposes the encoding
side of codecs to the Web, including codecs implemented with hardware
support. We could try to lever that into media processing APIs but I can't
see a good reason to.

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]