With recent proposed changes [1] to the Media Foundation based implementation of media::VideoCaptureDevice, I would like to start a discussion here about whether or not we want to (re-)roll out the Media Foundation based implementation to users.

Based on the git log from this CL [2], my guess is that the Media Foundation based implementation was needed and introduced in the context of Windows Metro Apps. Later, the support for Metro Apps was probably discontinued, and it was decided to switch all users to the DirectShow based implementation. The Media Foundation based implementation was kept behind a flag, in case it was still needed.

With the rollout of the video capture service in M61, the flag actually became ineffective due to a bug [3], so it is fairly safe to assume that there is no significant usage of it as of today.

Despite calling Media Foundation "the successor of DirectShow", Microsoft does not currently seem to tag DirectShow as deprecated, see [4]. Therefore, there is no reason to believe that support for DirectShow is going away on Windows platforms anytime soon. However, it is possible that certain new features will only be available through Media Foundation. For example, in [1] #18, the reporter mentions that capturing still images at 4k does not seem to be supported in DirectShow. 

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=730068
[2] https://chromium.googlesource.com/chromium/src/+/d127b7ee6c93e9aff1ee6124a5998fb8aa8a1cad%5E%21/media/capture/video/win/video_capture_device_factory_win.cc
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=777880
[4] https://msdn.microsoft.com/en-us/library/windows/desktop/ee663260(v=vs.85).aspx

We would like to avoid having to support both implementations long-term. If MediaFoundation can do everything that the DirectShow implementation does and more, then I think we should move to MediaFoundation.

IMO the way to do this would be gradually through an experiment-controlled rollout.

I don't have any direct insight into this either. 
On the encoding / decoding side, we're already moving or have moved to MF, so I think switching to it for capture is the right way forward. I'd expect it's only a matter of time before the DirectShow path is deprecated -- but that's just a hunch.

Some notes / Qs:
- Does the DirectShow path allow zero-copy encoding using our MediaFoundation encoder?
- The MediaFoundation implementation seems to be a 1/3rd of the line count as the DirectShow impl. Less complexity to maintain is always better...
- Does the MediaFoundation path work on Windows 7? N edition?

+tommi for commentary.

I am the reporter of cr [1].

Here is my little insight on this.

My company and I were in touch with a Microsoft MediaFoundation Tech Expert. 

The expert confirmed that DirectShow was deprecated in favor of MediaFoundation. 

He also confirmed that the Surface Pro 4 cameras still image PIN was only usable from the MediaFoundation API. I don't know if there are any other devices that specifically that are only fully usable from the MediaFoundation API. But the Microsoft Surface Pro alone seems to be a huge success in term of sells.

Beside that, what I saw from the Microsoft Documentation (msdn) is that the company is heavily pushing its Universal Windows Platform (UWP) as application centric model for its OS. UWP is kind of the Apple Store or Android Store of Windows. Almost every tech tutorial is dedicated to UWP high level apis. The UWP camera API use for sure MediaFoundation in the background. IMO this explains the delay took by Microsoft on the DirectShow full deprecation and removal, they care less about the low level APIs exposed to the public.

Currently, MediaFoundation with IMFCaptureEngine API (proposed in [1])
covers:
- Video streaming
- High quality still photo capture
- Video recording
doesn't cover the various camera settings control:
- zoom
- exposure
- flash
- etc ...

So, at the moment, the MediaFoundation API is not a full replacement of the DirectShow. But according to [2], you can use MediaFoundation for the video and photo capture while keeping DirectShow for the camera settings control.

Please note that IMFCaptureEngine is available since Windows 8, refer to [3].

Given all these facts, I think that:
- force-media-foundation flag should be removed
- DirectShow should be used on Windows 7 and below
- MediaFoundation with IMFCaptureEngine should be used on Windows 8 and above

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=730068
[2] http://blogs.microsoft.co.il/pavely/2012/05/19/windows-media-foundation-controlling-camera-properties/
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/hh447846(v=vs.85).aspx

Hello,

I understand that this kind of decision may require a certain delay.
Meanwhile, I have also to maintain the code review up to date with master.

Do you know the approximative delay needed to make the decision?

Based on the input collected here, it sounds like the consensus is that we do want to eventually migrate to MediaFoundation. Based on the information in #4, I agree it makes sense to target Windows 8 and higher for MediaFoundation and keep everything below that on DirectShow.

Unfortunately this means that we are going to have to support both implementations for quite a while, since it will probably be many years before the Windows 7 user base has become insignificant enough to remove the DirectShow code path.

I am not aware of any formal process for calling a decision, but I think the most important owners are present in this thread. If there are no objections, I will create a design doc and launch bug for an experiment-controlled roll-out of the Media Foundation code path for Windows 8 and above. We can then also go ahead and review/land the CL created by alaoui.rda@ for updating the Media Foundation code path to use IMFCaptureEngine.

Sound good to everyone? 

chfremer@, my company and I are still very motivated to land MediaFoundation usage without the flag.
Can I help in any way?

Sure, your help is much appreciated!

I guess the next step is to change the command-line flag to a base::Feature. You could do the CL for this. Then, we could use that for what is called an experiment-controlled rollout, which means enabling it gradually for certain percentages of dev/canary/beta/stable channels using the experimentation framework used for Chrome (which is called Finch). I can set up the configuration for this, since it is not part of the open-source Chromium project.

We also need a launch bug and a design doc, which I can take care of setting up.

What we also need to do is think about metrics (histograms and/or user actions) we can track in order to be able to measure how well things are going and see and diagnose any problems that may occur. For that I recommend looking at [1][2], and as an example usage [3].

I would also highly recommend covering class VideoCaptureDeviceMFWin with unit tests in isolation [4], which is something you could work on as well.

[1] https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/histograms/README.md
[2] https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/actions/README.md
[3] https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/video_capture_manager.cc?dr=CSs&l=72
[4] https://bugs.chromium.org/p/chromium/issues/detail?id=786854

chfremer@, mcasas@,

Is everything ok with the flag activation?
Do we have an ETA for full Chrome 66/67 media foundation activation?

On Chrome 66 (Beta), 67 (Dev), and Canary, I am unable to enable media foundation manually via --force-mediafoundation. I think it is the consequence of the transformation of the flag in a feature flag? Do we have a way to force the feature flag on an installation?

FYI, I am still able to force the flag on Chrome 65 (Stable).

The current status is that the feature is enabled for 50% of users on the Dev/Canary channel. During testing it was identified that certain virtual camera plugins on Windows do not support MediaFoundation and only work with DirectShow. I believe that switching all Windows 8.1+ users over to MediaFoundation without a solution for this would be bad because of feature loss.

I currently cannot find time to work on a solution, and therefore the rollout is stuck at where it is. The best solution I can currently think of would be to make it so that both MediaFoundation and DirectShow get enabled together. However, this would cause the same devices to potentially appear more than once in the list of available devices, which may be confusing.

Re #14:

Using "--force-fieldtrials=MediaFoundationVideoCapture/Enabled", I am able to force MediaFoundation on Chrome 67.

I just started working on the virtual camera issue.

> However, this would cause the same devices to potentially appear more than once in the list of available devices, which may be confusing.

Based on the camera names (or any other form of id), I naively think we should be able to provide to the consumer an enumeration composed of:
- cameras managed by MediaFoundation
- cameras managed by DirectShow but not MediaFoundation (i.e. virtual cameras)

Or this id I hope for doesn't exist or is not reliable?

chfremer@,

I created https://chromium-review.googlesource.com/c/chromium/src/+/1000853

Thanks for the CL. I reviewed it and think it looks great.

Sorry, I forgot to answer the part about forcing the feature on with a flag.
In addition to what you already found, it should also work with --enable-features=MediaFoundationVideoCapture, and if you want to force it off you can use --disable-features=MediaFoundationVideoCapture.