HEVC (h265) recording fails at sink init with MF_E_INVALIDMEDIATYPE; h264 works

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 1mo ago ·closed by John Lauer

Split from #189. The native recorder's codec arg accepts h265/hevc and desktop_record_encoders correctly reports the HEVC encoder present (e.g. "NVIDIA HEVC Encoder MFT", hardware:true on arav-rog and crr) - but actually starting a take with codec:"h265" fails at sink-writer init with MF_E_INVALIDMEDIATYPE ("The data specified for the media type is invalid, inconsistent, or not supported"), on BOTH the GPU (ARGB32) and CPU (RGB32) paths.

Tried in 2.1.106: setting MF_MT_MPEG2_PROFILE = eAVEncH265VProfile_Main_420_8 on the HEVC output media type (H.264 defaults a profile, HEVC needs one). Necessary but NOT sufficient - same error persists.

Likely remaining cause: the H.265 encoder MFT does not advertise RGB/ARGB input, and the sink writer's auto-inserted color converter that bridges BGRA->NV12 for the H.264 MFT is not being negotiated for HEVC. Next attempts to try (needs a box with the HEVC MFT - arav-rog / crr, both idle-testable):

Feed NV12 input explicitly (add a converter / set the input type to NV12) instead of relying on auto-negotiation.
Set MF_MT_MPEG2_LEVEL alongside the profile.
Enumerate the HEVC MFT's supported input subtypes directly to see what it wants.

Until then, 2.1.107 returns a clean errorCode: hevc_unsupported for codec:h265 pointing at h264 (the default, fully working at any bitrate/fps), instead of a raw MF string. H.264 recording and the ~105 s freeze fix (the #189 bug) are unaffected and shipped.

1 Reply

John Lauer · 1mo ago

Fixed in 2.1.110 (insiders). codec:"h265" records a real HEVC MP4.

Two-part cause, both proven by the 2.1.108 diagnostic (which logs the failing sink-writer step + HRESULT):

The hardware H.265 encoder MFT will not ingest RGB/ARGB; it needs NV12. The H.264 MFT takes ARGB32 directly, which is why h264 always worked. The SinkWriter does NOT auto-insert an RGB->NV12 converter into a HEVC topology.
The fragmented MP4 sink (MFTranscodeContainerType_FMPEG4, added in 2.1.104 for the #189 freeze fix) ACCEPTS H.264 but REJECTS HEVC at BeginWriting with MF_E_INVALIDMEDIATYPE. The diagnostic showed BeginWriting failing identically with ARGB32 AND NV12 input — that ruled out pixel format and pointed straight at the container.

Fix (2.1.109 + 2.1.110):

A D3D11 VideoProcessor converts the BGRA capture texture -> NV12 each frame (input full-range RGB 709, output studio YCbCr 709); the pooled MF samples are NV12 and the sink input type is NV12. The H.264 path is byte-identical (ARGB32, no VideoProcessor).
HEVC uses the non-fragmented MP4 container. HEVC requires the GPU path, so gpu:false is ignored for h265.

Proof on arav-rog (RTX 4090, 2560x1440), 2.1.110:

20 s take: encoder "NVIDIA HEVC Encoder MFT", 1332 frames, 0 dropped, finalised in 27 ms, 65 MB.
150 s take: 5936 frames, steady 29.9 fps, 0 dropped, no freeze, finalised in 3 s (finaliseMs:5), 294 MB.
ffprobe on the pulled file: codec_name=hevc (2560x1440 video) + codec_name=aac (audio), MP4, duration 47.68 s. Box scan: ftyp + moov + hvc1 + hvcC + mp4a, no avc1.

desktop_record_encoders lists the h264/h265 encoders a box has (hardware-first). If BeginWriting ever fails again, codec:h265 returns a clean hevc_unsupported (kept as a safety net). Fleet on 2.1.110: arav-rog, ConfRoomROG, AdomLapper.

John Lauer closed this · 1mo ago