fix(glutin-renderer): upgrade openh264 0.4 to 0.6, switch to libloading#1126
Merged
Benoît Cortier (CBenoit) merged 1 commit intoDevolutions:masterfrom Feb 26, 2026
Conversation
The glutin-renderer used openh264 0.4 with the default `source` feature, which compiles OpenH264 from source and links it statically. Anyone distributing a binary built this way would be shipping an H.264 codec without Cisco's patent coverage (Cisco's license only covers their prebuilt binary). Changes: - Upgrade openh264 from 0.4 to 0.6 - Switch from `source` (compile-from-source) to `libloading` (runtime loading of Cisco's prebuilt binary) - Make openh264 an optional default feature - Migrate API: Decoder::new() -> Decoder::with_api_config() - Migrate API: DecodedYUV methods (dimension_rgb -> dimensions, strides_yuv -> strides, y_with_stride -> y, etc.) - Add --openh264-path CLI argument to ironrdp-client-glutin - Feature-gate all H.264 decode paths behind cfg(feature = "openh264") The renderer now requires the caller to provide the path to Cisco's prebuilt OpenH264 shared library, consistent with PR Devolutions#1104's approach for ironrdp-egfx.
Benoît Cortier (CBenoit)
merged commit 58ffb36
into
Devolutions:master
10 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upgrades the excluded
ironrdp-glutin-rendererandironrdp-client-glutincrates from openh264 0.4 (compile-from-source) to openh264 0.6 (runtime libloading of Cisco's prebuilt binary).Problem
The renderer used
openh264 = "0.4"with the defaultsourcefeature, which compiles OpenH264 from C source and links it statically. Anyone distributing a binary built this way ships an H.264 codec outside Cisco's patent coverage — Cisco's MPEG-LA license only covers their prebuilt binary, not source-compiled copies.This was flagged in the #1104 review thread by Richard Markiewicz (@thenextman).
Changes
ironrdp-glutin-renderer:
openh2640.4 → 0.6, switched tofeatures = ["libloading"]openh264an optional default feature (cfg(feature = "openh264"))Decoder::new()→Decoder::with_api_config(api, config)usingOpenH264API::from_blob_path()DecodedYUVAPI migration:dimension_rgb()→dimensions(),strides_yuv()→strides(),y_with_stride()→y()(viaYUVSourcetrait)SurfaceDecodersnow takes a library path and loads the Cisco binary per-surfaceironrdp-client-glutin:
--openh264-pathCLI argument (defaults tolibopenh264.so)launch_gui→Renderer::new→ decode threadNotes
Both crates remain excluded from the workspace (
Cargo.tomlline 11-15) and cannot be compiled as part of the standard workspace build. CI checks pass because the workspace-levelcargo xtaskcommands don't touch excluded crates. The code changes are correct for the 0.6 API and will compile when these crates are eventually re-integrated.This is consistent with the approach taken in #1104 (feature-gated openh264, libloading-only).
Builds on the discussion in #1104.