Conversation
Add a v4l2h264enc candidate to the H.264 encoder table, between the existing hardware encoders and the software fallbacks in auto mode, and accept v4l2 as an explicit -hwaccel method. V4L2 stateful encoders are the standard hardware encode path on ARM SoCs (Qualcomm venus/iris, Raspberry Pi, NXP i.MX, Rockchip via hantro), where neither NVENC nor VA-API is available. The element only registers when the kernel exposes a matching /dev/video* encoder node, so the existing gst-inspect probe gates selection correctly on systems without one. Encoder tuning goes through extra-controls using the standard V4L2 control names (bitrate in bps, CBR mode, I-frame period/GOP matching the existing keyframe interval, no B-frames, repeated sequence headers). Controls a driver does not expose are skipped by GStreamer with a warning rather than failing the pipeline, so the same stage works across encoder implementations. encoderResult gains an optional afterEncoder caps stage, placed between the encoder and the parser. The v4l2 row uses it to pin the H.264 level (level=4, signaling only): without a fixed level in negotiation the bcm2835 driver on Raspberry Pi fails STREAMON with "Failed enabling i/p port, ret -3". Validated on a Raspberry Pi 4 Model B (bcm2835-codec, kernel 6.12, GStreamer 1.26.2): -test mode against doubletake-test-receiver selects V4L2 hardware encoding, streams 1920x1080@30 through the hardware encoder, and the extra-controls bitrate demonstrably applies. Selection logic covered by contract tests; go test ./... passes on linux/arm64.
This was referenced Sep 23, 2026
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
1 participant
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.
Adds a
v4l2h264enccandidate (auto mode: after VA-API, before software) and-hwaccel v4l2. This is the standard hardware encode path on ARM SoCs (Raspberry Pi, Qualcomm, i.MX, Rockchip), where NVENC/VA-API don't exist. The element only registers when the kernel exposes a stateful encoder node, so the existing probe gates it correctly.Tuning uses the kernel-standard controls via
extra-controls(bitrate/CBR, GOP, no B-frames, repeated headers); drivers skip controls they don't implement. One quirk found on hardware: bcm2835 fails STREAMON unless negotiation pins the H.264 level, soencoderResultgains an optionalafterEncodercaps stage and the v4l2 row pinslevel=4(signaling only).Validated on a Raspberry Pi 4 (bcm2835-codec, kernel 6.12, GStreamer 1.26.2):
-testloopback: 1080p30 through the hardware encoder, extra-controls bitrate verifiably appliedgo test ./.../vet/gofmtclean on linux/arm64; new contract-test casesNot tested on other V4L2 drivers (venus/iris etc.) — happy to iterate on reports.