Reland: Reorganize media::VideoCapture* types

Reland: Reorganize media::VideoCapture* types

Relanding after revert in r236927.  Original commit message below:

The purpose of this CL is to clean up the distinction between
VideoCaptureFormat (which identifies the captured type of a frame),
VideoCaptureParams (which identifies the requested format of a capture),
and VideoCaptureCapability (which identifies the capture capabilities of a
device).

Notably:
* VideoCaptureFormat::frame_size_type ->
  VideoCaptureParams::allow_resolution_change, as variable resolution
  capability is a per-session, not a per-frame property.
* VideoCaptureCapability::color -> VideoCaptureFormat::pixel_format, as frame
  color format is a per-frame property.
  * As VideoCaptureParams holds a VideoCaptureFormat member, capture requests
    are able now to request a particular capture color format.

BUG=269312
TEST=local build, run unittests, chrome on CrOS snow, desktop Linux
TBR=ncarter@chromium.org,jiayl@chromium.org,yzshen@chromium.org,wjia@chromium.org,jschuh@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=236979

[commit-bot: I haz the power, 2013-11-23 09:50:08]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sheu@chromium.org/83633008/1

[commit-bot: I haz the power, 2013-11-23 11:48:47]

Retried try job too often on linux_rel for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

[commit-bot: I haz the power, 2013-11-23 16:22:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sheu@chromium.org/83633008/1

[commit-bot: I haz the power, 2013-11-23 21:11:47]

Change committed as 236979

[mcasas, 2013-11-26 15:05:21]

On 2013/11/23 21:11:47, I haz the power (commit-bot) wrote:
> Change committed as 236979

Haven't we been here before? :)

What's the rationale for using gfx::Size, a UI namespace data
structure, in media/video/capture?

[Ami GONE FROM WEBRTC_CHROMIUM, 2013-11-26 18:56:01]

On Tue, Nov 26, 2013 at 7:05 AM, <mcasas@chromium.org> wrote:

> On 2013/11/23 21:11:47, I haz the power (commit-bot) wrote:
>
>> Change committed as 236979
>
> Haven't we been here before? :)
>

I don't know what this is referring to, but...

What's the rationale for using gfx::Size, a UI namespace data structure, in
> media/video/capture?
>

Passing width,height pairs of args around is more error-prone and less
wieldy than passing gfx::Size's around.
Since the latter also includes a convenient ToString() and is no more
expensive than two ints it seems like a win.
What problem do you see here?

https://codereview.chromium.org/83633008/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[mcasas, 2013-11-26 20:47:57]

On 2013/11/26 18:56:01, fischman1 wrote:
> On Tue, Nov 26, 2013 at 7:05 AM, <mailto:mcasas@chromium.org> wrote:
> 
> > On 2013/11/23 21:11:47, I haz the power (commit-bot) wrote:
> >
> >> Change committed as 236979
> >
> > Haven't we been here before? :)
> >
> 
> I don't know what this is referring to, but...
> 
> What's the rationale for using gfx::Size, a UI namespace data structure, in
> > media/video/capture?
> >
> 
> Passing width,height pairs of args around is more error-prone and less
> wieldy than passing gfx::Size's around.
> Since the latter also includes a convenient ToString() and is no more
> expensive than two ints it seems like a win.
> What problem do you see here?
> 
The origin of gfx::Size, more specifically the UI. And a bit its semantics: 
I use a "size" to specify a capture format, when I mean a "rectangle", or 
a "resolution" or a "WxH"... Shouldn't it be coming from sth like 
base::Rectangle? Or media::Rectangle? With a ROI inside etc?

> https://codereview.chromium.org/83633008/
> >
> 
> To unsubscribe from this group and stop receiving emails from it, send an
email
> to mailto:chromium-reviews+unsubscribe@chromium.org.

[Ami GONE FROM WEBRTC_CHROMIUM, 2013-11-26 21:23:28]

gfx::Rect lets you specify x/y in addition to width/height (i.e a region of
interest).
If there was a base::Rect then using that would be fine by me, but as it is
depending on ui/gfx from media doesn't seem problematic to me. See
media/DEPS's mention of ui and media.gyp for other ways in which the
dependency manifests.

-a


On Tue, Nov 26, 2013 at 12:47 PM, <mcasas@chromium.org> wrote:

> On 2013/11/26 18:56:01, fischman1 wrote:
>
>  On Tue, Nov 26, 2013 at 7:05 AM, <mailto:mcasas@chromium.org> wrote:
>>
>
>  > On 2013/11/23 21:11:47, I haz the power (commit-bot) wrote:
>> >
>> >> Change committed as 236979
>> >
>> > Haven't we been here before? :)
>> >
>>
>
>  I don't know what this is referring to, but...
>>
>
>  What's the rationale for using gfx::Size, a UI namespace data structure,
>> in
>> > media/video/capture?
>> >
>>
>
>  Passing width,height pairs of args around is more error-prone and less
>> wieldy than passing gfx::Size's around.
>> Since the latter also includes a convenient ToString() and is no more
>> expensive than two ints it seems like a win.
>> What problem do you see here?
>>
>
> The origin of gfx::Size, more specifically the UI. And a bit its semantics:
> I use a "size" to specify a capture format, when I mean a "rectangle", or
> a "resolution" or a "WxH"... Shouldn't it be coming from sth like
> base::Rectangle? Or media::Rectangle? With a ROI inside etc?
>
>  https://codereview.chromium.org/83633008/
>> >
>>
>
>  To unsubscribe from this group and stop receiving emails from it, send an
>>
> email
>
>> to mailto:chromium-reviews+unsubscribe@chromium.org.
>>
>
>
>
> https://codereview.chromium.org/83633008/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.