Add VideoCaptureDevice::GetDeviceSupportedFormats to interface + implementation for Linux and Fake

media/video/capture/video_capture_types.h

Index: media/video/capture/video_capture_types.h
diff --git a/media/video/capture/video_capture_types.h b/media/video/capture/video_capture_types.h
index 1a170aaf5e7d623b102f96020d5805d04aab1680..e91047712efcab5a021cd10e4a4dc2c538625480 100644
--- a/media/video/capture/video_capture_types.h
+++ b/media/video/capture/video_capture_types.h
@@ -77,6 +77,8 @@ class MEDIA_EXPORT VideoCaptureCapability : public VideoCaptureFormat {
   VideoCaptureSessionId session_id;
 };
 
+typedef std::vector<media::VideoCaptureCapability> VideoCaptureFormats;

[scherkus (not reviewing), 2013/09/12 17:56:00]

remove media::

[scherkus (not reviewing), 2013/09/12 17:56:00]

it seems unfortunate that we have to use VideoCaptureCapability considering we
only set color, width, height, and frame_rate

what about expected_capture_delay, interlaced?

session_id also seems very out of place

[mcasas, 2013/09/24 15:02:27]

TODO() check if those parameters are still in use anywhere.

+
 }  // namespace media

[perkj_chrome, 2013/09/13 10:33:05]

yes- session_id seems wrong to have at all. 

Can you help checkout and write a comment what VideoCaptureResolutionType
frame_size_type is?
Is  interlaced used by anyone?  Is there even a reason to separate
VideoCaptureFormat and VideoCaptureCapability? Wouldn't it make more sence to
combine them? 

[ncarter (slow), 2013/09/13 19:02:19]

Here's the information needs I see:

VCDevice <-> VCDevice::EventHandler (needs the info: width, height, colorspace,
stride etc. Does NOT have a session_id because a device can serve multiple
sessions.)

VCDevice::EventHandler <-> VCController (needs width and height, but colorspace
is implicitly I420. Does not have a session_id, because that's per-client
state.)

VCController/VCManager <-> VCHost <-> VideoCapture <-> VideoCaptureImpl <->
delegates (needs width and height. The session_id can be included but is
redundant unless it is in the context of the first (Start) request, in which
case it's a required parameter. Pixel format is always implicitly I420, and
should never be included.)

As far as I can tell, |interlaced| serves no purpose anywhere. It's not clear to
me (because I haven't looked) how important it is that we send frame_rate in
responses everywhere, but I don't see it as hurting anything and can be bundled
with width and height.

I don't think that VideoCaptureResolutionType as currently formulated is
altogether coherent. It's not clear to me whether it's a property of the device,
a mode of the device, or a constraint of the receiver. It seems like it's
actually a mix. If I've read the code correctly, the PPAPI clients can't deal
with variable resolutions, but the webrtc clients can? So in that sense it's a
constraint of the client. But also, only one of the devices is geared up to
support the variable resolution mode, so it's also a capability of the device.

[mcasas, 2013/09/24 15:02:27]

Associated enum names are self explanatory IMHO, either a constant resolution
device or one that changes according to its own volition.
Perhaps. I should fill a TODO/crbug on this, but is beyond the scope of this CL.
See above. TODO to further consolidate this file's classes.
Is both a command to the device to be configured so and so and also a reply of
the device.

 
 #endif  // MEDIA_VIDEO_CAPTURE_VIDEO_CAPTURE_TYPES_H_