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

Re: Constraints and MediaRecorder

From: Cullen Jennings <fluffy@iii.ca>
Date: Sat, 1 Feb 2014 20:00:21 -0700
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-Id: <4E3F9B40-9175-446D-944B-A6F4C6FEF9C5@iii.ca>
To: robert@ocallahan.org

The constraint API has moved to support more or less exactly what you propose below but calls it a setting. 

On Feb 1, 2014, at 4:38 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> I'm skeptical of the Constraints API in general, but I think MediaRecorder at least doesn't seem to need it.
> Suppose we had a MediaRecorderOptions dictionary like so:
> dictionary MediaRecorderOptions {
>   DOMString mimeType;
>   unsigned long width;
>   unsigned long height;
> };
> and pass it as an additional argument to the constructor. Further suppose we specify that any video frames are aspect-preserving-scaled to fit within width x height if both are specified, or if only one is specified then the video frames are aspect-preserving-scaled to that dimension. The mimeType is used if supported, otherwise the UA ignores it and makes its own choice.
> What are the use-cases that approach fails to solve? Maybe there are some, but the usability penalty going from
> var mr = new MediaRecorder(stream, {mimeType:"audio/opus"});
> to
> var mr = new MediaRecorder(stream);
> mr.applyConstraints({optional:[{mimeType:"audio/opus"}]}, function onsuccess() { ... });
> (in particular going from sync to async) is annoying. Not to mention the spec and WebIDL issues of indirecting through Constraints and pulling in that machinery.
> 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, 2 February 2014 03:00:50 UTC

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