Windows UVC: First frame dropped silently after stream start

Thank you for your reply.

I followed your suggestion and manually created the EnableFrameServerMode registry value under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation\Platform

I set its value to 0 and restarted the computer. Unfortunately, the issue still persists.

Here are some additional details that may help with the investigation:

• Camera model: Orbbec Gemini 335L
• Connection: USB 3.0
• Transfer mode: USB Bulk Transfer

The frame drop is 100% reproducible, but it only affects the very first frame after the video stream is started.

The issue occurs regardless of the application being used. It can be reproduced with both:

• the official Orbbec camera software, and
• the built-in Windows Camera app.

However, the same camera works correctly on Ubuntu Linux, where the first frame is received successfully without being dropped.

This camera also supports a software trigger mode, where each trigger generates exactly one frame. In addition, every frame contains a hardware frame sequence number. Because of these characteristics, it is very easy to verify that the first frame is consistently lost on Windows.

Please let me know if there are any additional logs, ETW traces, or diagnostic information that would be helpful for further investigation.

Hello master,

Thanks for replying.

I'll see what I can do. I'll keep you updated.

I suspect this issue may be related to the UVC FID (Frame ID) synchronization mechanism.

During my investigation, I tried sending an empty frame from the device immediately after starting the stream to initialize the FID state. After adding this workaround, the first-frame issue was no longer reproducible.

Although this workaround appears to resolve the problem, I would like to further confirm the actual root cause if possible. Specifically, I would like to know whether this behavior is expected as part of the Windows UVC streaming initialization mechanism, or if it could indicate a potential issue in the Windows UVC driver or Media Foundation pipeline.

If there are any recommended logs, traces, or diagnostic methods that could help verify whether the FID synchronization is the underlying cause, I would appreciate your guidance.

Thank you for your support.

Hello master,

Thanks for replying.

This is actually possible. Regarding for the root cause, I'd say you can try to use WireShark (already on your computer) and verify these:

• FID value of every payload header
• First FID seen after stream start
• Whether the first delivered frame and first dropped frame share the same FID state
• Presence of EOF on the first frame

Thanks for your suggestion.

By default, the first frame that is dropped has a UVC payload header bmHeaderInfo value of 0x8C. After that, the payload header alternates between 0x8C and 0x8D for each frame, which indicates that the FID bit toggles normally.

Could this mean that the Windows UVC driver initializes the expected FID value to 0 when streaming starts? If the first frame also has an FID of 0, could the driver interpret it as a duplicate or stale frame and discard it? In other words, is the first frame being dropped because its FID matches the driver's initial FID state?

Or is there any official documentation or recommendation suggesting that a UVC device should transmit an initial dummy (empty) frame to initialize the FID state before sending valid video frames?

Is this behavior expected according to the Windows UVC driver implementation, or is there any documentation describing how the initial FID state is handled?