Re: new draft of recording

On Sat, Mar 30, 2013 at 1:45 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:

>
>
> *From:* rocallahan@gmail.com [mailto:rocallahan@gmail.com] *On Behalf Of *Robert
> O'Callahan
> *Sent:* Friday, March 29, 2013 1:41 AM
> *To:* Jim Barnett
> *Cc:* public-media-capture@w3.org
> *Subject:* Re: new draft of recording****
>
> ** **
>
> I assume your attachment matches what's checked into
> https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html
> .
>
> > void              start (optional long? timeslice);
>
> I don't think you want the ? there.****
>
> ** **
>
> >> Most of your comments involve Settings and capabilities.  The current
> plan is that the gUM spec will define a Constrainable interface that
> MediaRecorder will inherit.  So I haven’t spent much time working on the
> details of the syntax here, since I’m expecting it to change.
>

OK but start() is nothing to do with settings and capabilities, right?

The text for imageHeight/imageWidth/mimeType says "the initial value will
> be a platform-supplied default". It seems better for the initial value to
> be defined, e.g. 0 and the empty string. When and how often do they change
> to a different value? The spec needs to say.
>
> ** **
>
> >> Don’t we want the initial value to be something useable?  The idea is
> that a developer can just call record and something useful will happen.
> That means that height/width and MimeType have to see sent to something
> practical, and that’s best left up to the UA (particularly since we don’t
> have a MTI mimetype.)
>

OK. What does 'imageHeight' mean? I thought it was the image height the UA
had selected after capturing has begun. Are you saying it's the height the
author requested via setOptions? How is it supposed to be used by apps?
Maybe we should just remove it?

Ditto for the MIME type. An app can get that from the first Blob delivered,
can't it?

****
>
> The utility of stop/start/pause/resume events seems questionable. These
> happen in response to method calls on the MediaRecorder, so authors already
> know when these things are happening. Are there use-cases where these
> events are useful?
>
> ** **
>
> >> The idea is that these are asynchronous commands, and the app needs to
> know when they actually go into effect.  This is particularly the case for
> start(), which can be called before any media is available.  I’m less sure
> of the case for pause/resume, but the events were added for consistency.
> In general , stop/pause/resume should take effect quite quickly, but there
> can be a long delay before a call to start() produces any actual recording.
>

It's not clear to me why an app would care when recording started
(especially since the event fires async and can therefore be delayed a
while after the actual start). Can you give an example where these events
are needed?

Separate error and warning events seems unnecessary. Other Web APIs don't
> use warning events. Web developers generally receive warnings via some
> UA-specific developer tool interface. If an actual Web app can't use the
> information, the API shouldn't be there. And generally, if you're not sure
> an API is needed, it shouldn't be there.
>
> ** **
>
> >> Yes, it’s not clear whether we need warning events.  One possible use
> would be in out-of-memory cases.  Rather than waiting till it runs out of
> memory, the UA might signal the to the app that it was about to run out of
> memory.  That way it could be sure not to lose any current data.  But we
> haven’t worked this out in detail yet.
>

I don't think we should try to solve OOM here. I don't think this should be
in the spec unless someone has a detailed explanation of how it works and
why it's needed.

Is it really necessary to export the minimum and maximum width and height?
> I think it would be simpler and just as workable to let the author request
> a width and height and let the user-agent automatically clamp them to fit
> implementation limits (preserving aspect ratio I suppose).
>
> ** **
>
> >> This is the way that the current gUM constraints proposal works.  For
> each attribute we define a set of legal values plus the current value.  I
> want to be consistent with gUM (and, as indicated above, would like to
> inherit this whole mechanism from it.)
>

Ah. I haven't looked into the gUM constraints stuff yet and I'm a bit
afraid to do so :-)

Rob
-- 
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"