RE: new draft of recording

Robert,
  Responses in-line, set of by ‘>>’

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.


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.)


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.


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.
The members of RecordingSettings should not be nullable. As dictionary members, they're all always optional.

>> I hope that this will all be defined in the Constrainable interface.  If it turns out that it’s not practical for this spec to inherit that, we will revisit all of these issues in detail.


AvailableSettings members should probably always be present, therefore AvailableSettings should not be a dictionary. In fact it's unclear why bundling these members together into an object is helpful. Why not provide a separate attribute on MediaRecorder for each "available setting" that needs to be exposed?

>> See previous comment.


For MIME types, instead of a list why not follow HTMLMediaElement and offer a canRecordType method? Seems easier to use than asking apps to scan a list. Also, it's more flexible since MIME types can contain information like codecs and other recording parameters, and you wouldn't want to make a list enumerating every supported recording configuration.

>> This might make sense, or it might make sense to have both.  Anyone else have an opinion?


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.)


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"