File Video Capture: allow IO operations from Device thread

media/capture/video/file_video_capture_device_factory.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "media/capture/video/file_video_capture_device_factory.h"
 
 #include "base/command_line.h"
 #include "base/files/file_path.h"
 #include "base/strings/sys_string_conversions.h"
 #include "build/build_config.h"
@@ skipping 10 matching lines @@
   base::FilePath command_line_file_path =
       base::CommandLine::ForCurrentProcess()->GetSwitchValuePath(
           switches::kUseFileForFakeVideoCapture);
   CHECK(!command_line_file_path.empty());
   return command_line_file_path;
 }
 
 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))));
 #else
   return std::unique_ptr<VideoCaptureDevice>(new FileVideoCaptureDevice(
       base::FilePath(device_descriptor.display_name)));
 #endif
 }
 
 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)
       base::SysWideToUTF8(command_line_file_path.value()),
       kFileVideoCaptureDeviceName, VideoCaptureApi::WIN_DIRECT_SHOW
 #elif defined(OS_MACOSX)
       command_line_file_path.value(), kFileVideoCaptureDeviceName,
       VideoCaptureApi::MACOSX_AVFOUNDATION
 #elif defined(OS_LINUX)
       command_line_file_path.value(), kFileVideoCaptureDeviceName,
       VideoCaptureApi::LINUX_V4L2_SINGLE_PLANE
 #else
       command_line_file_path.value(), kFileVideoCaptureDeviceName,
       VideoCaptureApi::UNKNOWN
 #endif
       );
 }
 
 void FileVideoCaptureDeviceFactory::GetSupportedFormats(
     const VideoCaptureDeviceDescriptor& device_descriptor,
     VideoCaptureFormats* supported_formats) {
   DCHECK(thread_checker_.CalledOnValidThread());
+  base::ThreadRestrictions::AssertIOAllowed();
 
   VideoCaptureFormat capture_format;
   if (!FileVideoCaptureDevice::GetVideoCaptureFormat(
         GetFilePathFromCommandLine(), &capture_format)) {
     return;
   }
 
   supported_formats->push_back(capture_format);
 }
 
 }  // namespace media