not compatible on WeChat Video chatting about windows-camera

[comor86]

If no change added, below is the log. Up is normal close, down is WeChat unnormal close.

[LPBourret]

Hi @comor86, sorry for the delay in response, I was out for vacation and am back today. Indeed I would not advise that you shutdown the virtual camera upon stream stop :\ as this will lead to headaches when virtual camera user (i.e. an app on behalf of their consumer) stops then want to start again.

Looks like WeChat is keeping a hold onto the camera and not properly disposing of their camera handle when not using the camera which effectively locks the virtual camera from being used somewhere else (and the physical camera it wraps as well). If you use the API released in newer SDK, i.e.:

1. asking for the MF_VIRTUALCAMERA_PROVIDE_ASSOCIATED_CAMERA_SOURCES

   Windows-Camera/Samples/VirtualCamera/VirtualCameraMediaSource/VirtualCameraMediaSourceActivate.cpp

   Line 322 in 1d1cee6

   RETURN_IF_FAILED(m_spActivateAttributes->SetUINT32(MF_VIRTUALCAMERA_PROVIDE_ASSOCIATED_CAMERA_SOURCES, 1));

2. then using the MF_VIRTUALCAMERA_ASSOCIATED_CAMERA_SOURCES to retrieve the IMFMediaSource of the target physical camera you wish to wrap

   Windows-Camera/Samples/VirtualCamera/VirtualCameraMediaSource/VirtualCameraMediaSourceActivate.cpp

   Line 27 in 1d1cee6

   if (SUCCEEDED(m_spActivateAttributes->GetUnknown(MF_VIRTUALCAMERA_ASSOCIATED_CAMERA_SOURCES, IID_PPV_ARGS(&spCollection))))

then the problem should be avoided. if not using this API then you would need to terminate the IMFMediaSource of the wrapped camera upon stopping the stream, and recreating it upon starting.. but this strategy would not guarantee success of recreating the device source of the wrapped camera if another app is holding onto it concurrently.

[comor86]

I wonder what this mean " If you use the API released in newer SDK"? I'm using SDK 10.0.22000.0.

According to the sample code, there is a comment about MF_VIRTUALCAMERA_PROVIDE_ASSOCIATED_CAMERA_SOURCES.

// The below 2 GUIDs are defined in Windows build 22621 and above only, 
// if targetting SDK for Windows 22621 or higher this would need to be commented out.
// GUIDs for retrieving the device source instead of recreating it from within the vcam
DEFINE_GUID(MF_VIRTUALCAMERA_PROVIDE_ASSOCIATED_CAMERA_SOURCES,
    0xF0273718, 0x4A4D, 0x4AC5, 0xA1, 0x5D, 0x30, 0x5E, 0xB5, 0xE9, 0x06, 0x67);

DEFINE_GUID(MF_VIRTUALCAMERA_ASSOCIATED_CAMERA_SOURCES,
    0x1BB79E7C, 0x5D83, 0x438C, 0x94, 0xD8, 0xE5, 0xF0, 0xDF, 0x6D, 0x32, 0x79);

Does it mean that I can't use this two features on Windows 11 21H2, and could use them on 22H2? I have tried your suggestion and found that if (SUCCEEDED(m_spActivateAttributes->GetUnknown(MF_VIRTUALCAMERA_ASSOCIATED_CAMERA_SOURCES, IID_PPV_ARGS(&spCollection)))) didn't return S_OK, but RETURN_IF_FAILED(m_spActivateAttributes->SetUINT32(MF_VIRTUALCAMERA_PROVIDE_ASSOCIATED_CAMERA_SOURCES, 1)); actually called and return S_OK, so the problem still there.

[LPBourret]

There are 2 different topics to disambiguate:

1. the SDK version your project targets (i.e. in the vcxproj that defines the minimum Windows version required to run this compiled binary)
2. the OS version at runtime of the virtual camera consumer (an app/vcam built using 22000 SDK may run on Windows version 22000+).

This header defines GUID that are also defined in the 22621 SDK to opportunistically leverage functionalities available in Windows 22621 without changing the project target SDK version. That's why this comments says that if you change your project target to 22621, then you have to comment those GUID definition since they will conflict with the SDK defining them as well in a required header.
If this code runs on a machine updated to Windows 22621, then the line

if (SUCCEEDED(m_spActivateAttributes->GetUnknown(MF_VIRTUALCAMERA_ASSOCIATED_CAMERA_SOURCES, IID_PPV_ARGS(&spCollection)))) 

should return true and avoid the problem you exposed with WeChat. If running on Windows version 22000, then you can gracefully do something else meanwhile to accommodate the app not disposing properly of the camera when stopped and not in use.

If you can run exclusively on Windows 22621 and above then the problem would be avoided. If not, then you could put in place the aforementioned mitigation of disposing the of the IMFMediaSource on Stop, and recreating it upon start using again MFCreateDeviceSource() (albeit with its set of caveats)

[LPBourret]

closing, please reopen if you encounter an issue still in your implementation