Repository navigation
GPU-direct encoder ignores the configured bitrate (~59.5 Mbps at both 10000 and 2000 kbps) #601
Description
Activity
- added a commit that references this issue
on Sep 24, 2026 2026-09-25 retest on the current production Release core: local SRT GPU-direct H.264 sender passed
--check-bitrateat 2, 4.5, 6, and 10 Mbps. Received video rates were 0.931, 4.257, 4.044, and 4.130 Mbps respectively; each run decoded 1920x1080 at ~60 fps with one encoder construction and no reported shedding. The low measured rates at higher targets are expected for this simple-content sender fixture; the changing-content hardware conformance fixture in the investigation checks both lower and upper bounds.The authorized Zoom test meeting also passed the live ingest validator after the join-link and Engine On harness fixes: nine participants, three video feeds, first frame 74 ms after the subscription request. This did not exercise real-meeting Program output or an external streaming endpoint, so #601 live-show acceptance remains open.
2026-09-25 live Program follow-up on the authorized test meeting: one-minute headless production-core recording with three real participant sources passed after explicit Engine On. The MP4 decoded at 1920x1080, 3,594 frames over 59.9 s (60.0 fps), audio duration 59.904 s, no reported encoder dropped video or render deadline misses. Spatial frame differences showed motion in 27.1% of adjacent frames. The original whole-frame-mean-luma oracle falsely failed this moving video; PR #641 corrects it and preserves the artifact check. This proves live meeting Program recording cadence, but not a live SRT/RTMP receiver bitrate at 4.5/6/10 Mbps, so #601 remains open.
Found while measuring Task 1 of the #597 stream-backpressure work. Not fixed there — that sub-project is about backpressure, and this is a separate defect in the encoder's rate control.
What was measured
The GPU-direct H.264 path was driven at 1920x1080@60 through the real Media Foundation hardware MFT, counting bytes out of the encoder over a fixed window:
A 5x change in the configured bitrate moved the output by 0.3%. The encoder emits the same bytes either way, at roughly 6x the requested rate.
Why
MediaFoundationGpuVideoEncodersetsMF_MT_AVG_BITRATEon the output media type and never touchesCODECAPI_AVEncCommonRateControlModeorCODECAPI_AVEncCommonMeanBitRate. On this hardware the MFT appears to treat the media-type attribute as advisory and runs at its own default quality target.Why it matters
An operator who configures a 10 Mbps stream gets roughly 59 Mbps on the wire. Any destination provisioned for the configured rate falls behind immediately, which is the shape of the #597 incident even though #597's own root cause was the restart storm. The backpressure work now in flight will mask the symptom by shedding input frames; it does not make the stream honor its configured bitrate.
Rig
RTX 4090, driver 616.92, Windows SDK 10.0.26100. The probe harness lives on branch
feat/stream-backpressurebehindCOREVIDEO_RATE_PROBE_KBPS.Done when
A configured bitrate is honored within a stated tolerance across at least 2000, 6000 and 10000 kbps, measured as bytes out of the encoder over a fixed window — not by reading back the attribute we set.