[GH-ISSUE #156] bug: Browser streaming fails on any host without a hardware video encoder #81

New issue

Closed

opened 2026-10-18 14:02:44 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-18 14:02:44 +00:00

Owner

Originally created by @knguyen298 on GitHub (Jul 20, 2026).
Original GitHub issue: https://github.com/open-webui/computer/issues/156

Summary

cptr/frontend/static/browser-encoder.js configures the WebCodecs VideoEncoder with hardwareAcceleration: 'prefer-hardware'. On hosts with no hardware video encoder (headless servers, GPU-less VMs), VideoEncoder.isConfigSupported() returns supported: false for every codec, so the guard throws and the browser tab errors out.

Environment

cptr with managed Chrome (Google Chrome, H.264-capable)
Linux VM, no GPU/hardware video encoder
Reproduces regardless of codec or resolution

Root cause

Per the WebCodecs spec, hardwareAcceleration defaults to no-preference, and prefer-hardware/prefer-software are hints that user agents should respect when possible but may ignore. Chromium does not implement them as hints: it treats prefer-hardware as a hard requirement, while no-preference means "use hardware if available, otherwise fall back to software."

Because there is no hardware encoder on these hosts, prefer-hardware causes isConfigSupported() to return false for all codecs, and this guard throws:

const support = await VideoEncoder.isConfigSupported(config);
if (!support.supported) throw new Error(`H.264 WebCodecs encoding is unavailable ...`);

Confirmed empirically on current Chrome: with prefer-hardware the config returns supported: false; with no-preference it returns true and encodes in software.

Suggested fix

Change the encoder config in browser-encoder.js:

hardwareAcceleration: 'prefer-hardware'  ->  'no-preference'

This loses nothing on hosts that have a hardware encoder (Chromium still uses hardware under no-preference); it only adds the software fallback where no hardware encoder exists. If explicit intent is preferred, try prefer-hardware first and retry once with no-preference on !supported before throwing.

Originally created by @knguyen298 on GitHub (Jul 20, 2026). Original GitHub issue: https://github.com/open-webui/computer/issues/156 ### Summary `cptr/frontend/static/browser-encoder.js` configures the WebCodecs `VideoEncoder` with `hardwareAcceleration: 'prefer-hardware'`. On hosts with no hardware video encoder (headless servers, GPU-less VMs), `VideoEncoder.isConfigSupported()` returns `supported: false` for every codec, so the guard throws and the browser tab errors out. ### Environment - cptr with managed Chrome (Google Chrome, H.264-capable) - Linux VM, no GPU/hardware video encoder - Reproduces regardless of codec or resolution ### Root cause Per the WebCodecs spec, `hardwareAcceleration` defaults to `no-preference`, and `prefer-hardware`/`prefer-software` are hints that user agents should respect when possible but may ignore. Chromium does not implement them as hints: it treats `prefer-hardware` as a hard requirement, while `no-preference` means "use hardware if available, otherwise fall back to software." - [Spec](https://www.w3.org/TR/webcodecs/#hardware-acceleration) - [Chromium behavior](https://github.com/w3c/webrtc-extensions/issues/98#issuecomment-1043205515) Because there is no hardware encoder on these hosts, `prefer-hardware` causes `isConfigSupported()` to return false for all codecs, and this guard throws: ```js const support = await VideoEncoder.isConfigSupported(config); if (!support.supported) throw new Error(`H.264 WebCodecs encoding is unavailable ...`); ``` Confirmed empirically on current Chrome: with `prefer-hardware` the config returns `supported: false`; with `no-preference` it returns `true` and encodes in software. ### Suggested fix Change the encoder config in `browser-encoder.js`: ```js hardwareAcceleration: 'prefer-hardware' -> 'no-preference' ``` This loses nothing on hosts that have a hardware encoder (Chromium still uses hardware under `no-preference`); it only adds the software fallback where no hardware encoder exists. If explicit intent is preferred, try `prefer-hardware` first and retry once with `no-preference` on `!supported` before throwing.

bsakaguchi closed this issue

2026-10-18 14:02:44 +00:00

bsakaguchi commented

2026-10-18 14:02:45 +00:00

Author

Owner

@tjbck commented on GitHub (Jul 21, 2026):

Should be addressed, testing wanted here!

@tjbck commented on GitHub (Jul 21, 2026): Should be addressed, testing wanted here!

bsakaguchi commented

2026-10-18 14:02:45 +00:00

Author