How to avoid MS Teams to select MJPG as camera data format?

Question

How to avoid MS Teams to select MJPG as camera data format?

Tom JD1 Xue 21

I'm developing a "python + C++ DLL" application, which calls Windows MediaCapture interface to open and read camera data (in format of NV12 or YUY2) in SharedReadOnly mode. And it must work together with MS teams while teams open camera (in exclusive mode) to achieve some function of image recognition. My application works fine with teams.

But today I met a problem. A laptop's camera supports camera data format of both NV12, MJPG. And teams select MJPG, then my application can't get data any more, no matter who starts to open camera first. From the code, I can see the frame it gets is null now.

auto frame = m_FrameReader.TryAcquireLatestFrame();

I did some research work, and the root cause might be this:

Teams selects MJPG format according to its own stratigy. Teams uses camera in exclusive mode, and my application uses camera in SharedReadOnly mode. In such a scenario, Microsoft Teams' choice of camera data format determines the final data format selected by my application.
Then camera hardware outputs MJPG data via MJPG pin. MJPG Pin supports only 1 active instance.
The MJPG Decoder (MFT) is bound to above MJPG pin and converts data to NV12 format, then finally will feed data to Teams.
Above MJPG pin and MJPG Decoder usually can be accessed by single instance, e.g. Teams. This depends on the driver's design. And this causes my application can't get camera data any more.

I hope someone who understands this aspect can help confirm whether my above understanding is correct and provide appropriate suggestions. Thank you!

3 answers

Your answer

Answer 1

Hi @Tom JD1 Xue

Thank you for posting your question in the Microsoft Q&A forum.

Your understanding is mostly correct. The issue occurs because Microsoft Teams selects an MJPG path that only supports a single active instance. When this happens, the Windows Camera Frame Server can’t deliver frames to your SharedReadOnly session, so your TryAcquireLatestFrame() call keeps returning null.

When you initialize MediaCapture with SharingMode set to SharedReadOnly, Windows allows multiple apps to access the same camera at the same time. This mode is designed for scenarios where your app needs to run alongside another app such as Microsoft Teams. You can’t change camera settings in this mode, but you should still be able to receive frames unless something in the camera pipeline is blocking them.

If TryAcquireLatestFrame() continually returns null, it usually means that no frames are available or the reader isn’t actually receiving any data. This can happen when another application is using the camera in a way that prevents the Frame Server from sharing the stream. Microsoft recommends handling the FrameArrived event and reading frames inside that handler, always checking for null. If the event fires but no frame is delivered, the pipeline may be blocked.

Whether Teams choosing MJPG prevents your app from receiving frames depends on whether the Windows Camera Frame Server is active. The Frame Server is responsible for sharing camera access across apps. If Teams or the camera driver bypasses the Frame Server by locking a hardware MJPG decoder or using a single-instance MJPG pin, your app may be blocked from receiving frames.

To improve compatibility and avoid MJPG-related issues, consider the following steps:

-Use an uncompressed format like NV12 or YUY2. Even if Teams uses MJPG, you can often open a parallel NV12 or YUY2 stream through the Frame Server. Select NV12 or YUY2 explicitly from the SupportedFormats list of your MediaFrameSource to avoid binding to MJPG hardware decoding.
Reference: Process media frames with MediaFrameReader - Windows apps | Microsoft Learn.

-Lower your requested resolution or frame rate. Some camera drivers only support concurrent streams at reduced resolutions or when one stream uses NV12 or YUY2. Use camera profiles to find combinations that support concurrent access and initialize your app with one of those profiles.
References:

-Avoid using hardware MJPG decoding. If your pipeline uses Media Foundation transforms, disable hardware decoding so the system uses software decoding instead. This allows multiple apps to decode frames simultaneously.
For Source Reader or Sink Writer pipelines, set MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS to false.
For MediaCapture, follow the guidance on disabling hardware transforms.
Note: Microsoft is providing this information as a convenience to you. These sites are not controlled by Microsoft, and Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please ensure that you fully understand the risks before using any suggestions from the above link.
Reference: MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS attribute (Mfreadwrite.h) - Win32 apps | Microsoft Learn.

-Start your SharedReadOnly reader before Teams opens the camera. This can sometimes encourage Windows to keep the Frame Server path active. It’s not guaranteed, but it’s a quick test that might help.
Reference: MediaCaptureInitializationSettings.SharingMode Property (Windows.Media.Capture) - Windows apps | Mi…

-Update your camera driver or switch to the Windows inbox UVC driver. Many concurrency issues are caused by vendor-specific drivers or MJPG paths that rely on single-instance hardware transforms.

-If your scenario allows, plug in or emulate a virtual camera driver that mirrors the physical camera. you can use a virtual camera driver that mirrors the physical camera. One instance can feed Teams (MJPG), while another feeds your processing pipeline (NV12).

I hope this information is helpful.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Tom JD1 Xue 21

Hi @Teddie-D ,

Thank you very much for your great help!

I have done some experiments on what you suggest.

"-Lower your requested resolution or frame rate. Some camera drivers only support concurrent streams at reduced resolutions or when one stream uses NV12 or YUY2. Use camera profiles to find combinations that support concurrent access and initialize your app with one of those profiles. "

For this one, I select the NV12 or YUY2 with lowest resolution, then I could get camera data but after the data is saved as an image, it looks like colorful snowflakes. I don't know why.

"-Start your SharedReadOnly reader before Teams opens the camera. This can sometimes encourage Windows to keep the Frame Server path active. It’s not guaranteed, but it’s a quick test that might help. "

This doesn't work, when Teams select MJPG, then my application can't get data any more, no matter who starts to open camera first. Even if I set the format to NV12 again after Teams starts, then I still get null frame.

"-Update your camera driver or switch to the Windows inbox UVC driver. Many concurrency issues are caused by vendor-specific drivers or MJPG paths that rely on single-instance hardware transforms. "

I did this before I made this post, but still not work.

"-If your scenario allows, plug in or emulate a virtual camera driver that mirrors the physical camera. you can use a virtual camera driver that mirrors the physical camera. One instance can feed Teams (MJPG), while another feeds your processing pipeline (NV12). "

This is a great method, but it is too complex. We need to solve this issue within short time.

"-Avoid using hardware MJPG decoding. If your pipeline uses Media Foundation transforms, disable hardware decoding so the system uses software decoding instead. This allows multiple apps to decode frames simultaneously. For Source Reader or Sink Writer pipelines, set MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS to false. For MediaCapture, follow the guidance on disabling hardware transforms. "

I haven't tried this one. Not very clear how to implement it.

One more question, as you said "-Use an uncompressed format like NV12 or YUY2. Even if Teams uses MJPG, you can often open a parallel NV12 or YUY2 stream through the Frame Server."

So for example, app1 use NV12 and app2 use YUY2, which means camera will provide two pins, one pin outputs NV12 data and another pin outputs YUY2 data, is this workable?

I have discussed this question with different people and always have disagreements about it.

Finally, we make a decision to not support MJPG format in current stage. So this issue is not urgent to resolve, but I still greatly appreciate your selfless assistance. Thanks!

Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-06T10:43:14.9433333+00:00
Hi @Tom JD1 Xue
Thank you for your update.
-If you're seeing colorful snowflakes when saving NV12 or YUY2 frames, it's because these are YUV formats, not RGB. Saving them directly as image files without converting to RGB first will result in corrupted visuals. To fix this, you need to convert the frame to RGB before saving:

SoftwareBitmap::Convert(frame.SoftwareBitmap, BitmapPixelFormat::Bgra8)

In Python with OpenCV:

rgb = cv2.cvtColor(nv12_frame, cv2.COLOR_YUV2BGR_NV12) cv2.imwrite("image.png", rgb)

-Most UVC cameras expose only one active pin per stream. This means the hardware itself cannot output multiple formats simultaneously. However, the Windows Frame Server creates a shared pipeline that can convert the camera’s output into different formats for each client application.

So, if one app requests NV12 and another requests YUY2, the Frame Server can handle that, but only if it's active and the driver supports concurrent streams.
If the Frame Server is bypassed as in your case, the camera’s MJPG pin becomes locked to a single format. No additional formats like NV12 or YUY2 will be available.

Therefore, two apps using different formats won’t work unless the Frame Server is enabled and the driver supports multiple simultaneous streams.
Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-07T05:41:28.47+00:00

Hi @Tom JD1 Xue
I wanted to follow up and ensure the information provided was useful to you. If you have any new updates or further inquiries, please let me know. Thank you!
Tom JD1 Xue 21 Reputation points

2025-11-07T13:58:36.9733333+00:00

Hi @Teddie-D

Your explaination and suggestion are very helpful!

I will reattempt the technical approach of reading NV12 (low resolution) data and converting it to RGB format. Whether I make progress or encounter problems, I will keep you informed.

Thanks a lot!

Tom JD1 Xue 21

Hi @Teddie-D

I did more experiments, and now the conclusion is:

Both BGRA8 and YUY2 formats can acquire frames, but the decoded data is completely corrupted (appears as random colorful noise patterns).

The frames are saved to files, and they can be found here:

https://github.com/tomxue/MJPG-issue

camera_frame_x.bmp file is for format BGRA8, while frame_YUY2_320x180_1762574657005.raw file is for format YUY2.

The key code is below:

// MediaCapture Initialization Settings

MediaCaptureInitializationSettings settings;

settings.VideoDeviceId = sourceGroup.Id();

settings.SharingMode = MediaCaptureSharingMode::SharedReadOnly;

settings.MemoryPreference = MediaCaptureMemoryPreference::Cpu;

settings.StreamingCaptureMode = StreamingCaptureMode::Video;

// MediaFrameReader Configuration

MediaFrameReader frameReader = CreateFrameReaderAsync(frameSource, outputSubtype);

frameReader.AcquisitionMode(MediaFrameReaderAcquisitionMode::Buffered);

Test Results Summary

123

Code Execution Flow：

      ├─> TryAcquireLatestFrame()                 

      │   // BGRA8: Returns valid frame ✓

      │   // YUY2:  Returns valid frame ✓

      │   // NV12:  Returns null ✗

      └─> ProcessVideoFrame(frame)

          └─> ProcessSoftwareBitmap()

              └─> Save to file (observed corrupted data)


**Further questions：**

1. Why does TryAcquireLatestFrame() return null for NV12 output when source is MJPG in shared mode?

sql
- YUY2 and BGRA8 work (return frames)

- NV12 fails (returns null)
2. Why is the decoded frame data corrupted for both YUY2 and BGRA8 formats?

sql
- Is this a known limitation of MJPG decoding in shared mode?

- Is there a workaround or alternative approach?
3. What is the recommended approach for accessing camera frames in shared mode when Teams is using MJPG?



**Note：logs to show the camera supported formats**

[DLL 15:23:24.762] Enumerating supported formats, count: 36

[DLL 15:23:24.763]   Available format: NV12 (1280x720)

[DLL 15:23:24.764]   Available format: MJPG (1280x720)

[DLL 15:23:24.765]   Available format: NV12 (960x540)

[DLL 15:23:24.765]   Available format: MJPG (960x540)

[DLL 15:23:24.766]   Available format: NV12 (848x480)

[DLL 15:23:24.766]   Available format: MJPG (848x480)

[DLL 15:23:24.767]   Available format: NV12 (640x480)

[DLL 15:23:24.767]   Available format: MJPG (640x480)

[DLL 15:23:24.768]   Available format: NV12 (640x360)

[DLL 15:23:24.768]   Available format: MJPG (640x360)

[DLL 15:23:24.769]   Available format: NV12 (424x240)

[DLL 15:23:24.769]   Available format: MJPG (424x240)

[DLL 15:23:24.770]   Available format: NV12 (352x288)

[DLL 15:23:24.770]   Available format: MJPG (352x288)

[DLL 15:23:24.771]   Available format: NV12 (320x240)

[DLL 15:23:24.772]   Available format: MJPG (320x240)

[DLL 15:23:24.772]   Available format: NV12 (320x180)

[DLL 15:23:24.772]   Available format: MJPG (320x180)

[DLL 15:23:24.773]   Available format: YUY2 (1280x720)

[DLL 15:23:24.775]   Available format: YUY2 (960x540)

[DLL 15:23:24.776]   Available format: YUY2 (848x480)

[DLL 15:23:24.776]   Available format: YUY2 (640x480)

[DLL 15:23:24.777]   Available format: YUY2 (640x360)

[DLL 15:23:24.777]   Available format: YUY2 (424x240)

[DLL 15:23:24.778]   Available format: YUY2 (352x288)

[DLL 15:23:24.778]   Available format: YUY2 (320x240)

[DLL 15:23:24.779]   Available format: YUY2 (320x180)

[DLL 15:23:24.779]   Available format: RGB24 (1280x720)

[DLL 15:23:24.780]   Available format: RGB24 (960x540)

[DLL 15:23:24.780]   Available format: RGB24 (848x480)

[DLL 15:23:24.780]   Available format: RGB24 (640x480)

[DLL 15:23:24.781]   Available format: RGB24 (640x360)

[DLL 15:23:24.781]   Available format: RGB24 (424x240)

[DLL 15:23:24.782]   Available format: RGB24 (352x288)

[DLL 15:23:24.782]   Available format: RGB24 (320x240)

[DLL 15:23:24.783]   Available format: RGB24 (320x180)

Thanks!

Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-10T13:32:42.01+00:00
Hi @Tom JD1 Xue
Your observations closely reflect how the Windows Camera Frame Server and shared-mode MediaCapture typically behave.

Let’s address each point:

1.TryAcquireLatestFrame() returns null for NV12 when Teams uses MJPG.
This behavior is device and driver dependent. It often occurs when a controlling application like Microsoft Teams locks the camera to the MJPG format.
In this scenario, NV12 frames may not be exposed to secondary readers when operating in shared mode. However, BGRA8 and YUY2 formats usually still work, since the OS can internally convert MJPG to these formats.
According to Microsoft documentation, TryAcquireLatestFrame() can validly return null, so your code should always handle this case defensively.

2.BGRA8 and YUY2 images appear corrupted.
This typically results from misinterpreting the pixel format:
-BGRA8: If the image is written with the wrong stride or top-down orientation, it can display as random or distorted colors.
-YUY2: As a packed YUV format, it requires proper YUV to RGB conversion. Writing it directly to a BMP or PNG without conversion leads to visual artifacts that resemble colorful snowflakes.

MJPG use by Teams restricts NV12 availability.

When Teams uses MJPG in a controlling or exclusive mode:
-Some drivers bypass the Frame Server, which prevents NV12 from being shared with other apps.
-Others restrict decoder instancing, allowing only converted formats like BGRA8 or YUY2 to be exposed to secondary clients.
This behavior varies across hardware and driver implementations.

3.Recommended approach when Teams uses MJPG.
To ensure compatibility and stability:
-Use BGRA8 as your preferred output format in shared mode. It’s broadly supported and compatible with SoftwareBitmap::Convert.
-Always check for null frames from TryAcquireLatestFrame() and handle them gracefully.
-If you require NV12, consider opening the camera in exclusive mode, but note this will prevent Teams or other apps from accessing the camera simultaneously.
-After setting up your reader, use MediaFrameSource.CurrentFormat to confirm the actual output subtype being delivered.
Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-11T06:51:39.14+00:00

Hi @Tom JD1 Xue
May I know if you have got any chance to check my answer? If you need further assistance, please feel free to let me know. Thank you!
Tom JD1 Xue 21 Reputation points

2025-11-11T08:14:49.69+00:00

Hi @Teddie-D,

Thank you for your reply!

So your idea is if we can get the data, it should work. The noise data might be caused by incorrectly parsing of data. Right?

I checked the data via ffplay or IrfanView to see noise snowflakes.

I will double confirm whether my code has correctly saved the data, and feedback you today or tomorrow.

BR,

<PII removed>
Tom JD1 Xue 21 Reputation points

2025-11-11T08:47:47.4166667+00:00

Hi @Teddie-D

We meet another issue.

We assume MJPG issue can't be solved in a short time, so we need to detect whether user's camera supports MJPG format and inform GUI to handle accordingly.

We use MediaCapture interface to achieve the camera's support format list. This works fine.

But some user's laptop turns off the "Camera access" switch in Windows system settings. In such case, we can't get the format list via MediaCapture API.

Do you have any idea on this scenario? Any method to get the supported format list even if camera access is forbidden?

Thanks!

BR,

<PII removed>
Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-12T12:52:26.8133333+00:00
Hi @Tom JD1 Xue
Yes, that’s exactly the idea. If TryAcquireLatestFrame() returns a valid frame and you can access the buffer, the data itself is likely correct. The “colorful snowflakes” you observed almost always come from how the raw bytes are interpreted or saved, not from actual corruption in the capture pipeline.

When camera access is disabled at the system level, Windows blocks the Media Foundation and MediaCapture stack entirely. For privacy reasons, there’s no API that can list supported camera formats without first obtaining user consent and OS‑level camera access, since format details can reveal sensor characteristics.

However, you can still detect the permission state and list basic camera metadata safely, without accessing the camera stream.

1.Check camera access permission

Use DeviceAccessInformation to see whether your app or the system currently allows access to the camera class:

using namespace Windows::Devices::Enumeration; auto dai = DeviceAccessInformation::CreateFromDeviceClass(DeviceClass::VideoCapture); auto status = dai->CurrentStatus();

You can also subscribe to AccessChanged to update your UI dynamically if the user changes privacy settings at runtime:

dai.AccessChanged( winrt::auto_revoke, DeviceAccessInformation const&, DeviceAccessChangedEventArgs const& args { auto newStatus = args.Status(); });

2.Enumerate device metadata even when access is denied

You can still list all connected cameras and inspect their properties using DeviceInformation. This works even if camera access is blocked, because it queries the system’s device catalog rather than the capture pipeline:

auto devices = co_await DeviceInformation::FindAllAsync(DeviceClass::VideoCapture); for (auto const& d : devices) { auto id = d.Id(); auto name = d.Name(); auto props = d.Properties(); }

Answer 3

Tom JD1 Xue 21

Hi @Teddie-D

Really thanks for your kindly help!

I see your points, thanks so much for your expertise!

Roughly to say, for example, for YUY2 data, I didn't convert it. I just save it and use some tool to check it and see snowflakes.

I summarize the code flow and questions of how I fetched YUY2/BGRA8 frames in below text file, please check.

BGRA8.txt

YUY2.txt

Sorry, I missed your last post. I will further study it (camera access forbidden issue) tomorrow.

BR,

Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-13T06:56:13.85+00:00

Hi @Tom JD1 Xue
We understand how frustrating it can be when technical issues arise, and we truly appreciate the effort you’ve taken to share the details of your scenario.

As moderators, our test environment has certain limitations, so we’re unable to fully reproduce your setup. However, we can provide troubleshooting guidance and direct you to relevant Microsoft documentation and community resources, even though we may not always be able to validate them hands‑on.

To help you get the most accurate and timely guidance, I recommend starting a new thread in the Microsoft Community Hub where you will find experienced users and experts who can offer tailored advice and deeper insights specific to your situation.

Thank you for your patience and understanding, and I’m sorry we can’t resolve this directly here. Redirecting you ensures you’ll connect with the right support team who can provide the help you need.
Tom JD1 Xue 21 Reputation points

2025-11-14T15:39:14.9533333+00:00

Hi @Teddie-D

Thank you so much for your transparent and helpful response! I completely understand the limitations you mentioned. I really appreciate you laying out a clear path forward. I'm contacting the camera vendor, they should know whether our approach is feasible or not. If I have any progress, I will keep you updated.

Thanks again for all your help!
Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-15T09:03:57.3733333+00:00

Hi @Tom JD1 Xue
Thank you for your kind understanding. If you have any further updates, please don’t hesitate to share them. Your insights are invaluable not only for me but also for other members of the community who may be facing the same challenge.
Tom JD1 Xue 21 Reputation points

2025-11-20T13:59:08.8966667+00:00

Hi @Teddie-D

I got email from the camera vendor as below:

"According to Microsoft’s Windows OS and product design guidelines, the GPU hardware decoder and camera HW/FW design of older notebook platforms are not suitable for reading MJPG streams in shared mode."

Thanks for your great help!

BR,

<PII removed>
Teddie-D 8,120 Reputation points Microsoft External Staff Moderator

2025-11-20T23:14:12.0966667+00:00

Hi @Tom JD1 Xue
Thank you so much for sharing this update. It’s really helpful to have clarity on the current behavior and its limitations. The details you’ve provided will make it easier for others who encounter the same challenge. I truly appreciate the time and effort you’ve spent troubleshooting this with me.

Share via

How to avoid MS Teams to select MJPG as camera data format?

3 answers

Your answer