UVC 1.5 H.264-only camera — Windows never issues `SET_INTERFACE alt=1` after successful Probe/Commit

Daniel SERCY 0 Reputation points
2026-05-29T13:19:29.36+00:00

Problem

We have a USB High-Speed UVC 1.5 H.264 camera device (STM32N6570-DK, VID=0x0483/PID=0x7753, USBX middleware). The device exposes a single VS_FORMAT_H264 / VS_FRAME_H264 format (1280×720, Constrained Baseline, Level 3.2, 30+15 fps) with a Encoding Unit (bUnitID=0x03) and one isochronous IN endpoint (Alt=0 zero-bandwidth, Alt=1 wMaxPacketSize=1024).

All descriptor fields have been aligned with the Microsoft constrained-baseline 720p reference example from the USB Video Class H.264 extension document (bLevelIDC=0x20, bmCapabilities=0x0029, bmSupportedUsages=0x00010003, bmSupportedRateControlModes=0x05, bMaxCodecConfigDelay=0x01, bNumFrameIntervals=2, EU bmControls=0xE9). USBView reports no descriptor errors.

When Windows Camera App opens the device, the following USB control sequence is observed on the device side (UART log):

SET_INTERFACE if=1 alt=0          ← enumeration
GET_CUR / SET_CUR / GET_CUR VS_PROBE_CONTROL   ← negotiation, clean
SET_CUR VS_COMMIT_CONTROL         ← accepted, STATUS=0
GET_MAX VS_PROBE_CONTROL          ← device returns 666666 µs (15 fps)
GET_MIN VS_PROBE_CONTROL          ← device returns 333333 µs (30 fps)
--- STOPS HERE ---
```sql

No Encoding Unit requests are issued. No `SET_INTERFACE alt=1` is issued. The isochronous streaming alternate setting is never opened. The device appears in the Windows Camera App camera list but preview never starts.

The device firmware correctly handles the stale-commit case (Windows sends a cached format index from an older firmware; device returns STATUS=0 with probe state and Windows retries cleanly). The second commit round is clean (fmt=1, frame=1) and also accepted. The failure occurs after both commit rounds.

Full static descriptor dump: `Traces/USBView23.txt`. Full negotiation trace: `Traces/Uart23.txt`.

### Questions

1. After a successful UVC 1.5 H.264 `SET_CUR COMMIT` (STATUS=0), what condition causes `usbvideo.sys` or the KS/MF capture stack to silently abort without issuing any Encoding Unit requests or `SET_INTERFACE alt=1`?

2. Which `KS_H264VIDEOINFO` field or internal media-type validation step is most likely failing, and is there a WPP / ETW trace (`usbvideo.sys`, `ks.sys`, or MFCaptureEngine) that would expose the rejection error code?

3. Does Windows Camera App (UWP `MediaCapture`) support H.264-only UVC cameras for live preview, or does it require at least one raw format (NV12/YUY2) alongside H.264?
Windows for home | Windows 11 | Devices and drivers
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-05-29T13:19:52.0333333+00:00
    1. After a successful UVC 1.5 H.264 COMMIT, usbvideo.sys will not issue Encoding Unit requests or SET_INTERFACE alt=1 if the negotiated stream cannot be validated as a usable Media Foundation capture stream. Typical reasons include:
      • The negotiated frame interval or capabilities do not match what the driver and Media Foundation expect for the advertised H.264 profile/level and usage.
      • The device’s H.264 capabilities (as exposed via the H.264 UVC extensions) do not conform to the Microsoft H.264 UVC extensions that usbvideo.sys is designed to work with.
      • The device does not present itself correctly as a color or sensor camera, or required registry/BOS configuration for camera type and DMFT chain is missing or inconsistent.
      The inbox UVC driver is designed to work with H.264 cameras that follow the “Microsoft Specification of Video Class Driver for H.264/MPEG‑4” and the “Microsoft Proposed Extensions to the USB Video Class for H.264” and will silently fail to start streaming if the stream cannot be configured into a valid MF pipeline.
    2. The validation is done at the UVC/Media Foundation boundary, where the driver translates the negotiated UVC H.264 format into an internal media type (which includes the equivalent of KS_H264VIDEOINFO). If that translation fails, the stack will not proceed to open the isochronous alternate setting. The documentation indicates:
      • The UVC class driver discovers H.264 features, negotiates the session, and streams H.264 payloads only if the device firmware follows the Microsoft H.264 UVC guidelines.
      • For H.264 cameras, the firmware must implement video streaming according to the Microsoft H.264/MPEG‑4 video class driver specification and the proposed H.264 UVC extensions.
      To diagnose failures, the recommended approach is to:
      • Verify the H.264 descriptors and controls strictly match the Microsoft H.264 UVC specification (including profile/level, capabilities, and frame intervals) and the example constrained‑baseline 720p configuration.
      • Run the HLK “Camera Driver Test – UVC Test 1” and the H.264 camera tests (such as “MultiCamera Preview, Record H.264 Video and AAC Audio”). These tests validate that the camera and driver are compatible with Windows Media Foundation and will surface failures such as no samples produced, failure to enter run state, or timeouts.
      • Use the HLK troubleshooting guidance to interpret errors like MF_E_HW_MFT_FAILED_START_STREAMING or MF_E_SINK_NO_SAMPLES_PROCESSED, which indicate that the device did not successfully enter the run state or did not deliver valid samples.
      These HLK tests are the supported way to expose the underlying failure conditions in the Windows camera pipeline for UVC/H.264 devices.
    3. Windows supports H.264 UVC cameras through the inbox UVC driver starting with Windows 8, and the driver can stream H.264 payloads from a camera without requiring a proprietary driver, provided the firmware follows the Microsoft H.264 UVC specification. The documentation does not state that a raw (NV12/YUY2) format is required alongside H.264 for preview; instead, it emphasizes that:
      • The inbox UVC driver supports H.264 streaming and uses Media Foundation for encoding/decoding.
      • H.264 cameras must implement the Microsoft H.264 UVC extensions correctly so that usbvideo.sys can discover capabilities, negotiate the session, and stream.
      Therefore, the key requirement is conformance to the Microsoft H.264 UVC specification and correct descriptor/firmware implementation, not the presence of an additional raw format. If the H.264‑only configuration fails validation, the stack will not proceed to SET_INTERFACE alt=1 and preview will not start.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.