W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2012

Re: Proposal for Hints Information

From: Cullen Jennings <fluffy@cisco.com>
Date: Mon, 30 Jan 2012 13:12:10 -0800
Cc: Dan Burnett <dburnett@voxeo.com>, public-webrtc@w3.org
Message-Id: <9F6B04DB-CD94-44A6-81DA-E19239ADB62C@cisco.com>
To: Aleksandr Avseyev <alexn74@gmail.com>

On Jan 24, 2012, at 15:22 , Aleksandr Avseyev wrote:

>    I like it except that I'm not sure if aspect ratio should be the highest priority.In real life use cases it seems to be working fine. Say, webcam supports 960x540 and 1600x1200. User sets aspect priority to 16:9 and min height to 1200. It should pick 960x540, right?

Yes. Also, most webcam that did theses two modes would also support 1600x900 so if it supported that, then it would return that. 

I will note this is a case where the camera provided can not meet the constraints asked for so anything is more or less considered a failure. If the applications cared more about the min high than the aspect ratio, but still wants to work if the aspect ration can't be meant, it should not have specified the aspect as a constraint. 


> 
> On Tue, Jan 24, 2012 at 6:57 AM, Cullen Jennings <fluffy@cisco.com> wrote:
> 
> I'm thinking about the uses cases here and let me try a straw man 
> 
> If there is an aspect ratio, specified, meeting that constraint is the highest priority.
> 
> If there is a max height or width set, meeting that constrain is the next highest priority.
> 
> If there is a min height or width set, meeting that constraint is the lowest priority.
> 
> All constraints being meant, select the solution with the largest number of pixels.
> 
> 
> For the cases I could think of of being "realistic" use cases - these rules seemed to work. Thoughts on if something as simple of this would not work? different set of rules ?
> 
> 
> 
> On Jan 24, 2012, at 6:12 , Dan Burnett wrote:
> 
> > This almost makes my point for why selectable configs are best.  Authors will always want to control priority.  In fact, I suspect authors will want not just single priority flags but rather an ability to give a priority list, e.g., height_bound is more important than best_aspect, which is more important than fit_height, but width_bound, best_fit, and fit_width are unacceptable.
> >
> > -- dan
> >
> > On Jan 23, 2012, at 9:41 PM, Aleksandr Avseyev wrote:
> >
> >>   I would add priority flags: HEIGHT_BOUND, WIDTH_BOUND or BEST_FIT, BEST_ASPECT, FIT_WIDTH, FIT_HEIGHT. Default priority is pixel count and we don't care if either height or width go out of bound.
> >>
> >> On Mon, Jan 23, 2012 at 5:26 PM, Cullen Jennings <fluffy@cisco.com> wrote:
> >>
> >> On Jan 23, 2012, at 15:11 , Aleksandr Avseyev wrote:
> >>
> >> >
> >> > On Mon, Jan 23, 2012 at 8:32 AM, Cullen Jennings <fluffy@cisco.com> wrote:
> >> >
> >> >
> >> > For Video: ----------------------------
> >> >
> >> > min / max height
> >> >
> >> > min / max width
> >> >
> >> >  Is there any reason not to put height and weight into pairs? From my opinion it makes more sense to specify minRes(w, h) and maxRes(w, h). Aspect ratio is a good idea, but it should be specified on how it works with resolution.
> >> >
> >> > ------------------------------
> >> > Regards, Aleksandr Avseyev (Futurewei Research Lab)
> >> >
> >>
> >> that seems like a reasonable idea but we'd need to figure one more thing out and what is what min and max mine in the case of 2 d vector. For example, is 176 by 144 bigger or smaller than 160 by 160. What I would propose is that we order them based on the number of pixels. So 176 * 144 = 25344 which is smaller than 160 * 160 = 25600. If the number of pixels is the same then we pick the one that is wider is considered bigger.
> >>
> >> Does that sound like it would work ?
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> ------------------------------
> >> Regards, Aleksandr Avseyev (Futurewei Research Lab)
> >> www.pictures2.com
> >
> 
> 
> 
> 
> -- 
> 
> ------------------------------
> Regards, Aleksandr Avseyev (Futurewei Research Lab)
> www.pictures2.com
Received on Monday, 30 January 2012 23:41:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC