W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2014

Re: Constraints and MediaRecorder

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 03 Feb 2014 06:31:41 +0100
Message-ID: <52EF29BD.4020102@alvestrand.no>
To: robert@ocallahan.org
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
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.
Received on Monday, 3 February 2014 05:32:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:24 UTC