- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Tue, 19 Aug 2014 12:57:02 -0400
- To: cowwoc <cowwoc@bbs.darktech.org>, public-media-capture@w3.org
On 8/19/14 10:57 AM, cowwoc wrote:
>> You also seem to assume that people will specify constant values as
>> opposed to calculating the desired value programmatically. That's not
>> necessarily true. I may very well decide to create a dynamic viewport
>> depending on what is going on in my application at a given time and
>> its aspect ratio might change across runs (this is even more true in
>> the context of desktop web browsers where the window size changes on
>> a regular basis).
I'm not assuming constants, but if you're limiting yourself to hardware
cameras that can exactly match the aspect ratio of your dynamic viewport
then good luck with that.
>> In that case, it's even more important that the user (programmer) be
>> trained to give the system the chance to make approximations - if
>> aspect ratios are dynamic, they will very often be impossible to hit
>> exactly, due to things like granularity of codec macroblocks
>> (typically 16 pixels).
>>
>> And it's even less likely that the epsilon will matter in practice.
>
> Discussing this in more detail, how does the API enable developers to
> implement this use-case? Certainly a developer will want the biggest
> video box smaller than [X, Y] and then he might have preferences in
> terms of the aspect ratio. For example, one developer might prefer
> widescreen aspect ratios while another might prefer 4:3 (depending on
> say ... whether they are broadcasting multimedia or screen sharing a
> remote desktop). How does the API allow the developer to express such
> constraints?
Does this work?
getUserMedia({ video:{ width:{max:X}, height: {max:Y},
aspectRatio:{ideal:(mm? 16/9 : 4/3) }}});
Btw, not saying people should cut'n'paste this. This is your use-case,
and you seem certain developers prefer black bars over "fill and crop"
or skew.
.: Jan-Ivar :.
Received on Tuesday, 19 August 2014 16:57:30 UTC