File Video Capture: allow IO operations from Device thread

media/capture/video/file_video_capture_device_factory.cc

Index: media/capture/video/file_video_capture_device_factory.cc
diff --git a/media/capture/video/file_video_capture_device_factory.cc b/media/capture/video/file_video_capture_device_factory.cc
index 0ead703662115d63c6419c94c8af87b99629807e..0a1570f3de4581af3cc1234f5ead86acee46d235 100644
--- a/media/capture/video/file_video_capture_device_factory.cc
+++ b/media/capture/video/file_video_capture_device_factory.cc
@@ -28,6 +28,7 @@ base::FilePath GetFilePathFromCommandLine() {
 std::unique_ptr<VideoCaptureDevice> FileVideoCaptureDeviceFactory::CreateDevice(
     const VideoCaptureDeviceDescriptor& device_descriptor) {
   DCHECK(thread_checker_.CalledOnValidThread());
+  base::ThreadRestrictions::AssertIOAllowed();
 #if defined(OS_WIN)
   return std::unique_ptr<VideoCaptureDevice>(new FileVideoCaptureDevice(
       base::FilePath(base::SysUTF8ToWide(device_descriptor.display_name))));
@@ -41,6 +42,8 @@ void FileVideoCaptureDeviceFactory::GetDeviceDescriptors(
     VideoCaptureDeviceDescriptors* device_descriptors) {
   DCHECK(thread_checker_.CalledOnValidThread());
   DCHECK(device_descriptors->empty());
+  base::ThreadRestrictions::SetIOAllowed(true);

[chfremer, 2016/09/22 16:39:53]

I believe this will work, but it feels a little hacky to simply allow IO
operations on the calling thread without telling the clients about it.

What would a clean solution look like?
I am guessing, we would we have to post the IO operations to the IO thread, wait
for the response and then return back to the client? Are there any arguments
against doing that?

[mcasas, 2016/09/22 16:47:03]

It is hacky, but the Video Capture thread is not ours to
deal with, it comes from the AudioManager [1], and we 
can't modify it there (would affect others).
Yeah, the best-est way would be to post these tasks
to the FILE or the IO thread, I'd say, or allow the 
FileVCD to operate on IO thread.  The only argument
against this is complexity: for a Debug device, I 
think it's overkill to post to FILE/IO Thread, and 
arguably FileVCD should try to mimic any other VCD,
where there is at most 1 thread beyond the IO.

I could see FileVCD having an internal thread,
with IO allowed, to perform the Fie operations.
This would replicate the other VCD implementations
that have an internal thread, but IMHO this would
over complicate a debug-only feature.

[1]
https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/medi...

+
   const base::FilePath command_line_file_path = GetFilePathFromCommandLine();
   device_descriptors->emplace_back(
 #if defined(OS_WIN)
@@ -63,6 +66,7 @@ void FileVideoCaptureDeviceFactory::GetSupportedFormats(
     const VideoCaptureDeviceDescriptor& device_descriptor,
     VideoCaptureFormats* supported_formats) {
   DCHECK(thread_checker_.CalledOnValidThread());
+  base::ThreadRestrictions::AssertIOAllowed();
 
   VideoCaptureFormat capture_format;
   if (!FileVideoCaptureDevice::GetVideoCaptureFormat(