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

media/video/capture/video_capture_device.h

Index: media/video/capture/video_capture_device.h
diff --git a/media/video/capture/video_capture_device.h b/media/video/capture/video_capture_device.h
index 8ef43e75f0ebf8267b5f416ffebf0f4be1efd877..0d03924bfd8960255733550393e371f0aa61f8a9 100644
--- a/media/video/capture/video_capture_device.h
+++ b/media/video/capture/video_capture_device.h
@@ -221,6 +221,14 @@ class MEDIA_EXPORT VideoCaptureDevice {
 
   // Get the name of the capture device.
   virtual const Name& device_name() = 0;
+
+  // Gets the supported video capture formats, if operation is supported by the
+  // driver, for a particular video capture device. This operation must be run
+  // after the device being opened with Allocate(), and it may take into account

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

It seems a bit weird that we require Allocate to be called before this function.
Before calling this function- there is no way of knowing what |capture_format|
to Allocate. 
Please also make sure that you use the same "capability" structure for both
Allocate and this new method.

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

I have a CL out that merges Start+Allocate, and the proposed semantic here is at
odds with that. If you have a look at https://codereview.chromium.org/24133002/
I think you'll quickly see how they're in conflict. Are there notes or an email
thread somewhere that describes your plan for how GetDeviceSupportedFormats will
operate end-to-end?

What's not clear to me is how this new function is intended to be called in
practice from VideoCaptureManager. Today a device is always constructed,
Allocate()'d and Start()'ed in response to a HostMsg_Start IPC event, and that's
why I'm moving to merge those phases. (see the recently-revamped code at
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/re...
) At what point exactly in the lifetime of the stream do we expect to enumerate
the supported formats? Does the result need to make it all the way back to the
renderer process, or is it handled in the controller?

My gut feeling right now is that this functionality is more about enumeration of
devices, rather than operation of a device. If so then it probably doesn't
belong tied to an instance of VideoCaptureDevice* at all. It should probably be
more like how device enumeration works, using static functions. In my thinking,
once a VideoCaptureDevice exists you ought to know what you want to do with it.

+  // the current state of the device, f.i. an already opened device might see
+  // supported formats limited etc.

[ncarter (slow), 2013/09/16 16:20:02]

The current contract of this function seems to expect synchronous operation. Are
you sure this will work well on all device implementations? The threading story
of various device impls is all over the place. MFWin and the desktop capture
devices are two cases where it's not clear if we can get what we need.

Should the response be sent via some method of the VCD::EH interface instead?
That would make it much easier to communicate this info back down the
VideoCaptureController -> VideoCaptureHost -> VIdeoCaptureImpl chain. Or does
this information need to flow back via MediaStreamManager?

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

Asynchronous reply would be the answer, let me write some notes in the next
iteration.

+  virtual void GetDeviceSupportedFormats(

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

how do I know if this method succeeded or not? what happens to capture_formats
when it does fail?

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

On the asynchronous reply, it would be empty.

+      VideoCaptureFormats* capture_formats) = 0;

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

this CL could be dramatically simplified if you provided a default
implementation in the .cc

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

Done.

 };
 
 }  // namespace media