Re: Constraints and MediaRecorder

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:
>
>     My use case for constraints is always the case where the JS
>     application (not the UA) has to make the call between:
>
>     - I'd like things to be like that, but I'd rather have something
>     working than nothing
>     - I have to have it like that, and I can't live with having it any
>     other way
>
>     The somewhat OBE case that comes to mind first is if we set a
>     constraint of
>
>
> OBE?

Overtaken By Events - it would have been a more realistic case if the
recent poll in RTCWEB had shown a large group of people arguing for "two
of {H.264, VP8, H.261}".

>
>     [mandatory or optional]:
>        width: 640
>        height: 480
>
>     and the only available codec is H.261, which can't do more than
>     352x288.
>
>
>     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.
>
>
> 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.

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.


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

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