[Bug]: Error: Failed to encode WGC frame

[Afton-programmer]

Search existing issues

• I have searched the existing issues

Describe the bug

Error: Failed to encode WGC frame
This error appeared on Windows 10 after version 1.9.4; please look into this—the issue arose following the new update.

Expected behavior

Thanks for the repair.

To Reproduce

No response

Screenshots

No response

OS

Windows

OS Version

Windows 10

Other OS

No response

Browser

None

Browser Version

No response

Other Browser

No response

Device Type

None

Other Device

No response

Additional context

No response

[EtienneLescot]

Thanks for coming back with this, and sorry — this one is ours. You were on #327 with a stop that timed out; 1.9.4-rc.2 changed the Windows encode path to run on the GPU, and on your machine that path is failing where the old one did not. Different symptom, caused by the fix for the first.

The design intent was that the GPU path degrades to the previous CPU one rather than failing. It does that for every check made while starting up, but not for a failure that only appears once frames are flowing, which is what you are hitting.

Getting you recording again now

There is a switch for exactly this, already in the build you have. Set it once and relaunch OpenScreen:

PowerShell

[Environment]::SetEnvironmentVariable("OPENSCREEN_WGC_DISABLE_DXGI_INPUT", "1", "User")

Or: Windows key → "environment variables" → Edit environment variables for your account → New → name OPENSCREEN_WGC_DISABLE_DXGI_INPUT, value 1.

That forces the CPU path the previous versions used. If recording works again with it set, that confirms the GPU path is the cause, and it also tells us the rest of the release is fine on your machine.

The one line that would let us fix it

Failed to encode WGC frame is the generic message the helper prints when it gives up; the actual failure is logged immediately above it, with the call that failed and its error code. Something like:

ERROR: Acquire capture bridge failed (hr=0x887a0005)
ERROR: Failed to encode WGC frame

That HRESULT is the whole diagnosis. The easiest way to capture it, no install needed:

1. Download openscreen-diagnostic-windows-x64 from the latest run of the Diagnostic artifact workflow, or grab scripts/diagnostic-tool/ from the repo
2. node diagnostic.mjs --duration 10 --output report.json
3. Attach report.json here

The report also contains a capture-adapter line naming which GPU the capture landed on versus which one drives your display. If those differ on your machine, that is very likely the root of both problems.

If running Node is not convenient, the error line alone — copied from wherever you saw Failed to encode WGC frame — is most of what we need.

What happens next

We are not promoting 1.9.4 to a stable release until this is understood, so nobody gets it as an automatic update. The fix is almost certainly that a failure at this stage should fall back to the CPU path mid-recording instead of ending it, the way the startup checks already do — but the HRESULT decides that, so it is worth waiting for rather than guessing.

[EtienneLescot]

Fixed differently than expected, and more bluntly: the GPU encode path is off by default as of v1.9.4-rc.3. https://github.com/getopenscreen/openscreen/releases/tag/v1.9.4-rc.3

@Afton-programmer you should not need the environment variable I gave you earlier. Install rc.3 and recording goes back to the path 1.9.3 used. If you set the variable, you can remove it — the name changed anyway.

Why off rather than patched

The path had one confirmed success and one confirmed regression: yours. Its fallbacks cover every check made while starting up, and none of a failure that only appears once frames are flowing, which is what you hit. A recording that dies mid-encode has nowhere left to go, because the encoder is already configured for the GPU format by then.

That gap is a real design hole, not a tuning problem, and it was shipped on by default on the strength of one machine where it helped. Turning it off costs the people it helped nothing they cannot get back with a flag, and costs you nothing at all. It stays off until a mid-encode failure degrades to the CPU path instead of ending the recording.

Still worth having, if it is easy

The exact error line above Failed to encode WGC frame — the one with an hr=0x... code. It names the call that failed on your hardware, and it is what the eventual fix has to handle. You are unblocked either way, so only if it is convenient.

Reopening or a new report is welcome if rc.3 still fails, since that would mean the cause is somewhere I have not looked.

[EtienneLescot]

One question, and it is a small one — the answer would narrow this down more than anything else we can do right now.

Which graphics card does the affected machine have? If it is a laptop with both an integrated and a discrete GPU, both names, and which one Windows says is driving the display.

The fastest way to get it:

PowerShell

Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion

Or: right-click the desktop → Display settings → Advanced display → the adapter name is at the top. Task Manager → Performance also lists every GPU in the machine.

Why it matters

Every reporter who has stated their OS is on Windows 10, and both reporters who have stated their hardware have a discrete GPU. Neither machine we can test on matches on either count — ours are Windows 11 with integrated graphics only — so the two possible causes are perfectly tangled in the data we have, and we cannot tell them apart.

Your answer breaks the tie. If your machine has no discrete GPU, one of the two hypotheses dies immediately and we stop chasing it. If it does, the remaining question is a specific one we can rent hardware to test.

No logs, no reinstall, no reproduction attempt needed — just the adapter name.