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.

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