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

Re: Constraints and MediaRecorder

From: Robert O'Callahan <robert@ocallahan.org>
Date: Sun, 9 Feb 2014 22:45:03 +1300
Message-ID: <CAOp6jLbOr0rBcEW6KxhX9hq+zrErb7q6UW74vgRCL-w80AhiOw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Jan-Ivar Bruaroey <jib@mozilla.com>, Harald Alvestrand <harald@alvestrand.no>, Martin Thomson <martin.thomson@gmail.com>, Cullen Jennings <fluffy@iii.ca>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On Sun, Feb 9, 2014 at 9:28 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Mon, Feb 3, 2014 at 4:04 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>> On Tue, Feb 4, 2014 at 12:25 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>> I agree that this is true to some extent, but TBH I found it more
>>> convincing before your post above suggesting that capability testing
>>> might consist of empirically verifying that the browser did what it
>>> promised it did. From the perspective of the consumer of the API,
>>> what I want is deterministic behavior and that includes errors when
>>> I ask for something the UA won't.
>> OK, but the Web likes graceful degradation when feasible. That's why we
>> don't throw errors when you use an unsupported CSS property in a
>> stylesheet, and why 2D canvas silently skips rendering operations when
>> given NaN parameters. This is partly because the Web has a cohort of
>> mediocre developers and poorly maintained apps, partly because the Web has
>> heterogenous implementations with different levels of API support, and
>> partly because Web implementations compete on how many apps they can run so
>> economics favour permissiveness. (There are yet other reasons applying to
>> specific examples.) Having said that, I appreciate that degree of
>> permissiveness involves tradeoffs that have to be analyzed on a case by
>> case basis.
>> In this case we have some consumers who want to provide optional
>> constraints, and others who want to provide mandatory constraints, and
>> providing a single API that provides both without confusing anyone over its
>> semantics is a bit hard. If we go with only optional constraints, and let
>> people implement mandatory checking via inspection APIs that we'll probably
>> have to provide anyway, it feels like a win to me.
> I'm still finding myself confused about what you mean by "inspection APIs"
> Say, for instance, that I want the MediaRecorder to record at 192 kHz.
So we have some mechanism for me to ask for that and then the browser
> gives me back a MediaRecorder with some properties it thinks are
> appropriate. Are you arguing that there should be some API that will
> allow me to interrogate the object and see what I got (which would
> have to exist for every constraint, presumably) or that I have to
> directly test the object for its properties, e.g., by passing in audio
> and then seeing if it retains the high frequencies?

The former --- assuming there's a use-case where you really need to know,
at the time of recording, whether those frequencies are being recorded.

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w
Received on Sunday, 9 February 2014 09:45:30 UTC

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