build(gstcefsrc): CEF 154 and gstcefsrc master under the HTML Input block

[srperens]

What this is

CEF 154 and gstcefsrc master under the HTML Input block, with Strom's three gstcefsrc patches rebased onto them.

Stacked on #879 (feat/cef-devtools-proxy): it builds on that branch's patches and page guard, and targets it. Not to be merged before #879.

Why

• CEF: 144.0.21 is Chromium 144.0.7559.248. 154.0.33 is Chromium 154.0.8037.94, the current stable, about eight months and ten major versions on. In strom-full the renderers run unsandboxed as root, so a known Chromium bug in a page is code running in Strom's container. That makes staying current matter more than usual.
• gstcefsrc: the pin b633408 is from 2025-12-02. Master (204b01b, 2026-08-24) is 22 commits on: event and caps leaks fixed, unlock/unlock_stop, CEF timestamps with an internal queue, max-video-framerate, and macOS build fixes.

What changed

The patches

docker/gstcefsrc/*.patch are regenerated against master:

• popup-close: applied as it was.
• isolated-context: conflicted only where upstream added max-video-framerate next to it, in the property enum, setters, getters, init and class init. Both are kept.
• strict-network: CEF 145 split Local Network Access into two permissions, local network and loopback, and later renamed the old one ..._DEPRECATED. The patch now answers all of them, chosen by CEF_API_ADDED, so it still builds against older CEF.

build-gstcefsrc.yml defaults to the new CEF and ref.

The HTML Input block

gstcefsrc master changed three things the block depends on:

	before	master
frames	one per tick at a fixed rate	only when the page changes, framerate=0/1 in the caps
rate	in the caps	the max-video-framerate property
caps into cefdemux	video/x-raw	application/x-cef

The block tells the two plugins apart by the property. On the new plugin it sets the rate on the element, names the caps for cefdemux, and puts a compositor after the video. A live compositor emits at its own rate and repeats the last frame it has, so the block's output stays at a constant rate however still the page is. videorate cannot do this, because it repeats a frame only when the next one arrives.

Measured on a static page with CEF 154 via gst-launch, cefsrc ! … ! fpsdisplaysink:

after cefsrc	output
videorate ! video/x-raw,framerate=25/1	2 frames, 0.50 fps
compositor ! video/x-raw,framerate=25/1	24.85–25.11 fps, steady

On the old plugin the block builds exactly what it did before.

Raw cefsrc pipelines change behaviour. A caps filter asking cefsrc for a fixed rate (video/x-raw,framerate=30/1) no longer negotiates, a static page sends no frames, and cefdemux needs application/x-cef. docs/HTML_RENDER.md says what to use instead. Any flow that drives raw cefsrc with a fixed-rate caps filter has to change, Open Live's included.

Release

gstcefsrc-154.0.33-strom1 (run 37010759222) is published to gstcefsrc-deps, and docker/strom-full/Dockerfile points at it with both sha256 digests. Nothing published before is touched.

What was measured

All in strom-full on arm64 (Docker Desktop), with CEF 154 and the patched gstcefsrc in place of 144, a locally built Linux binary of this branch, and the new entrypoint. The suite ran first against a local build of the plugin and was repeated against the published arm64 archive. Before the repeat I checked that the archive's sha256 matches the release digest and that version.txt names CEF 154.0.33 and the three patches.

Check	Result
Static page, video-only block at 25 fps, frames written to disk	100 frames in 4 s
WebAudio tone, audio_video block, audio_out to wav	audio flows (1.4 MB of F32 in 4 s), peak at full scale
Two HTML Input blocks on the default URL	each gets its own link and page
Page calling print(), alert(), confirm() and starting a download on load	all return, nothing on disk
File input clicked through remote control	Strom up, page rendering
Popup opened and closed, then an on-air URL change	lands
Flow stopped and restarted, same link	opens the new page; history clean on both starts
Two sources, a cookie and localStorage set in A	B sees neither
getDisplayMedia on the page and in a cross-site iframe	NotAllowedError in both
Camera and microphone	the fake devices
Strict: fetch to loopback, and a WebSocket to Strom's /api/ws	Failed to fetch, WebSocket error
Loose: the same	reached, WebSocket opened (measured without authentication, since /api/ws refuses a WebSocket without credentials)
Loose source on http://127.0.0.1:8080/	page and scripts load
Right click through remote control	Strom up
Without authentication: page guard, popup, live URL, screen capture, link minting	guarded, URL lands, capture refused, mint 404
Strom process after the whole suite	running, no heap errors in the log

The WebSocket row is new. With 144 and upstream gstcefsrc's single enable-features, WebSocket was never checked. Here strict refuses it and loose allows it.

Tests

• Ran locally on this head (macOS arm64): cargo test --lib (743 passed, 4 ignored), openapi_test, html_remote_control_property_test, pipeline_lifecycle_test. Clippy is clean, native and wasm32. New: html_input::tests::the_viewport_caps_follow_the_plugin, which checks the caps for each plugin.
• The full suite was not run locally; CI runs it.
• The end-to-end suite above is by hand, against a real CEF. Nothing in CI runs a real cefsrc, so the compositor and caps changes have no CI guard beyond the unit test.

Not done

• amd64 is built and published, but not run. Only arm64 was run.
• Widevine (STROM_CEF_WIDEVINE=1, from feat(html): an HTML Input block, and remote control of the page it renders #879) has not been tried with CEF 154.
• CEF 154 under GPU mode (STROM_CEF_GPU=1) has not been tried.
• Long runs: the leak fixes upstream are taken on trust, and no soak test was run.

🤖 Generated with Claude Code