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

Re: Constraints and MediaRecorder

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 4 Feb 2014 12:05:43 +1300
Message-ID: <CAOp6jLbMtxU-mZ+wkg53SpwBF=Rnygweivc6yDB9NRAwZ3FSuQ@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Mon, Feb 3, 2014 at 6:31 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

>
>   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 use-cases demand complex type choosing strategies, then I would suggest
offering MediaRecoder.canRecordType as a parallel to
HTMLMediaElement.canPlayType.

I would still advocate allowing the UA to choose a different type if the
specified type is unsupported, because that makes the more robust behavior
the default.

 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 Monday, 3 February 2014 23:06:12 UTC

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