Can the virtual camera be accessed from multiple applications simultaneously?

[DavitMob]

In readme Getting Started's 5th step says Install VirtualCamera_UWP, this one I am not sure what I should do. I have seen in other issues people were able to install uwp camera manager app, but I am not sure how do I do this. Any comment about this would be appreciated. What I was able to do was the following:

1. Built all the projects successfully
2. Installed VirtualCamera_MSI
3. Ran VirtualCamera_Installer and was able to install VCam-SimpleMediaSource and VCam-HWMediaSource. When choosing VCam-AugmentedMediaSource, the installer crashes.

VCam-SimpleMediaSource and VCam-HWMediaSource I registered were visible in ms teams (for example). However, it was not possible for me to use the same virtual camera from another app (e.g. slack) simultaneously while ms teams was using the virtual cam. Maybe I am missing smth or doing smth wrong. If not, is there a way to modify/extend this project so the virtual camera is consumed from multiple applications simultaneously? Or any way to use MediaSource to build a virtual camera that will be consumed by multiple applications simultaneously.

[LPBourret]

Hi,
I guess you are asking 2 questions:

1. how can you install the virtual camera UWP control app?
   follow the steps 1 to 4 in the readme section related to the app (https://github.com/microsoft/Windows-Camera/tree/master/Samples/VirtualCamera#virtualcameramanager_app). This will allow you to launch the UWP app from which you can create and destroy virtual camera instances using a GUI. In this case though you don't need to run VirtualCamera_Installer which does mostly the same thing as the app but from cmd line.

2. how to use the same camera from more than 1 app concurrently? VirtualCamera is not meant to be a way to allow concurrent usage of a camera from more than 1 app. VCam is a mechanism to virtually 'plug' a new camera on the system, and have that camera produce frames/expose capabilities in a vast number of ways such as wrapping an existing camera or synthetizing frames on its own. MediaCapture is a client-side API to instantiate a camera handle and use it from an app. That said, this quesitons refers to the 'sharing mode' with which you initialize your camera client (i.e. in WinRT this would be your MediaCapture instance, the way you initialize it using a MediaCaptureInitializationSettings and specifying a MediaCaptureSharingMode)
   if an app initializes a camera client with SharingMode == ExclusiveControl (most if not all apps do), then only it can control the camera (i.e. change MediaType, set controls, etc.). However, a second app can open the same camera using a camera client initialized with SharingMode == SharedReadOnly, which will allow it to receive frames but not to change the MediaType nor set controls. I think this is what you are asking for correct? Your other app needs to open the camera in SharedReadOnly to receive frames despite the other app concurrently running and using the same camera with a client initialized in ExclusiveControl.

[DavitMob]

Thank you very much for the detailed comment @LPBourret . For some reason I was told that in order for the camera to be accessed concurrently, I need to create a virtual camera. So I don't. I will just use WinRT in my app to initialize my camera in SharedReadOnly mode. I assume this will work in any scenario, right? That is, regardless what api the other app is using to initialize the camera (for example, regardless if the other app is a UWP app or not), I can always use the camera in SharedReadOnly mode, right?

[LPBourret]

Hi, yes mostly as there is a caveat sadly:
some USB cameras that started to ship a while ago may block you from reading from them even in shared mode if the other app is using them via DShow (an older API instead of MF or WinRT).
We have been requiring cameras to not do this but we can't prevent 1) older hardware that already shipped and 2) older apps that still use DShow to get you in that situation in your UWP app even when using readonly sharedmode when 1) + 2) are put together. There is however nothing that can be done in that situation to read frames concurrently so your approach is the one to use to cover that experience.

[DavitMob]

Thanks @LPBourret . Closing the issue.