RE: MediaStream Recording options

Greg,
  In general, get/setOptions is the least mature part of the spec.  I've been hoping that I would be able to inherit the options/settings interface from another spec, but so far that hasn't worked out.   Further comments in-line.

From: Greg Billock [mailto:gbillock@google.com]
Sent: Friday, July 19, 2013 2:44 PM
To: public-media-capture@w3.org
Subject: MediaStream Recording options

A couple more questions about the getOptions/setOptions methods.

First, these APIs look dual, but in fact getOptions returns the set of available options, not the options that have been set with setOptions. Should this be renamed getAvailableOptions instead? That the RecordingSettings and AvailableSettings are different types is a bit confusing as well. Would renaming the methods be ergonomic enough to go with a single RecordingSettings type?
>> Something like this would make sense, but again I'm hoping to inherit the API from another spec, so that all the Recording spec would have to do is to define the specific options that it uses.

Having getOptions return the set of current options might still be a good idea.

Second. Are the options meant to be user-consumed? That is, is the idea that retrieved options can be presented to the user? Or is this meant to just be manipulated directly by app code?
>> They're mostly intended for app use.  We haven't really thought about presentation to the user.  I wonder if we'd want an additional pretty-print name or something like that.

Third. Have you considered options relating to audio sampling? For example a "audioBitDepth" and "audioSampleRate" might be really nice. I'm guessing this set of options is intended as the spot where further encoding options can be added in. How many of these are intended to go here directly as settings keys as opposed to, say, params on the mime type?

>> We really haven't thought about this part.

Fourth. "imageWidth" and "imageHeight" sound like photo capture sizes. The comments on AvailableSettings makes it sound like this is capture size for video as well, though. Is that right? Will this crop, downsample, or what? I think this could use some additional documentation. Should these parameters, for video, echo the names in MediaTrackConstraints? "width", "height", "frameRate", etc.
>>  They may have started off as photo settings, and then not been properly renamed when photo was moved to a different spec.   Might it confuse people if they echo the names for the MediaTrackConstraints?  I'm not sure.   There's been a fair amount of discussion about how the UA may/should/must implement MediaStream constraints.  The rough conclusion has been that it can either use the settings on the underlying device, or do postprocessing, but it's not allowed to fake data (in other words, it can downsample, but not upsample.)  I imagine that similar considerations apply here, but we haven't written it  up yet.  This, again, is something I would like to inherit from another spec (i.e. the general syntax and semantics of settings.)

Fifth. Is "takePhoto" and associated image parameters redundant to MediaStream Image Capture? Any reason to have them in both spots? Presumably the pre-encoding image capture will be lower latency and higher fidelity.
>> No, they're redundant and I have removed them from the editor's  draft.  They were originally in the recording spec, then moved to a separate spec.

Thanks!

-Greg Billock