Re: Constraints and MediaRecorder

On 2/3/14 12:31 AM, Harald Alvestrand wrote:
> On 02/03/2014 06:01 AM, Robert O'Callahan wrote:
>> On Mon, Feb 3, 2014 at 4:59 PM, Harald Alvestrand 
>> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>>
>>     Would you rather have grainy video or no video? Only the
>>     application knows, and for the UA to do what the application
>>     wants, there has to be API expressiveness that allows the UA to
>>     express what it wants.
>>

Clearly the application wants neither grainy video nor no video, so 
bundling that in with "what the application wants" is at least unnatural 
and novel. There's no gUM permission prompt to avoid here, so why build 
a complicated intent missile for what's naturally captured in a couple 
of lines of code?

1. App: I want X
2. Browser: Sorry I only have Y (returning Y or ErrorSorryOnlyHave("Y") 
doesn't matter)
3. Optional: App decides Y is OK or bails.

To me, that's the most obvious way to express the negotiation that 
naturally has to happen, between what apps demand and what browsers 
produce (which will change over time).

It also meets the simple-things-must-be-simple test:
- Simple apps have one line of code to write (and browsers act as 
desired for simple apps).
- Advanced apps have a few more lines of code to write.
- Avoids Constrainable, which is not simple.

It also has none of the webidl and future-proofing headaches of 
Constrainable (it handles the complicated unknown browser-property case 
naturally).

>> Can you point to a real-life example of an application that would 
>> rather just fail than get low-resolution video --- one where that's 
>> likely to be a possibility in practice?
>
> Pre-qualifying equipment for use in a high quality recording scenario 
> is one instance. If it can't do it, replace it.

Using gUM? Isn't that going to give you a permission prompt for each 
one? That seems pretty terrible.

> I can certainly think of other cases - applications that would rather 
> just fail than to get video above 1 Mbit/second, because it knows how 
> much disk it's going to use up to store it and for how long, for instance.

I think the question was about low-resolution video, not too-high 
resolution.

>> For MIME type, I can see that some applications would just want to 
>> reject "bad" types in some cases. Such applications can just start 
>> recording, then check the value of "type" and react accordingly if 
>> it's not a type it can use (e.g. by stopping the recorder and giving 
>> feedback to the user).
>
> This argues against your suggestion that the MIME type should be given 
> (as a single value) in init parameters. Either multiple types are 
> acceptable (in which a single parameter isn't saying anything, since 
> the UA can just disregard it), or they are not (in which case a single 
> parameter should cause failure if it can't be satisfied).

The mime argument can easily be a list of DOMStrings. I don't see how 
that matters here. My main takeaway from Roc's point is that 
applications are free to fail whenever they're unhappy, with few or no 
side-effects.

>> If there is a convincing answer to my question above, then we can 
>> handle it the same way --- equip MediaRecorder with attributes 
>> returning the size of encoded video frames.
>
> This presupposes that the MediaRecorder, if it can't satisfy the 
> parameters given, will make a choice among the other alternatives that 
> is the one that the user might be able to live with.
>
> Frankly I see this as a more complex and more "trust to luck" API than 
> letting the application state what it desires from the UA, and which 
> parameters it is willing to have disregarded.

I respectfully disagree with this point, however, whether it fails or 
falls back seems a smaller point than the fact that Constrainable is not 
needed in either case here.

.: Jan-Ivar :.