[wagenet]

Caution

Hold. The premise below is wrong and this must not merge as written.

The startup codec discovery does fail for H.264 on macOS, exactly as described. But its result (stream.out_caps) is read only by request_webrtcbin_pad's media: None branch — the branch taken when webrtcsink creates the offer. In WHEP the client offers: whep_signaller's send_counter_offer defaults to false and Strom never sets it, so select_codec runs instead. That builds its candidates from the client's media.formats() against the global codec table, never consulting stream.out_caps, and re-runs discovery with the client's SDP caps — where force_profile is false, the constrained-baseline demand disappears, and vtenc passes.

So H.264 is dropped from a list nothing downstream reads, and consumers that ask for H.264 get it. Verified two ways: a whepclientsrc restricted to video-codecs="<H264>" negotiated to stable and got rtph264pay, and a separate session put real Chrome on a WHEP feed with no rank override and saw rtph264pay decoding at 1280x720 while 6 discovery failures were logged.

This PR would therefore report "H.264 was dropped from the offer" on every macOS WHEP flow while viewers are receiving H.264 — a false alarm, which is worse than the silence it set out to fix. The reporting mechanism and BlockDiagnostic are sound; what they are pointed at is not. Being reworked to report a codec a consumer asked for and did not get.

---

Stacked on #786, which this needs for BlockHealth. The first four commits are that PR; review it first. Only feat(whep): report codecs whepserversink drops from the offer is new here.

Long body: it carries the verbatim upstream evidence for a bug that belongs in gst-plugins-rs, and the measurements behind deciding not to ship the obvious workaround.

The defect

whepserversink proves each codec in a throwaway pipeline before offering it — encoder, parser, a codec-parser-caps capsfilter, payloader, appsink — and lookup_caps swallows each failure with a gst::warning!, "as long as we end up with one potential codec for each input stream".

None of that escapes the element. The discovery pipeline's bus sync handler returns BusSyncReply::Drop, consumer-pipeline-created fires only for real sessions, no property lists the survivors, and the sink still reaches PLAYING on whatever is left. A WHEP output that asked for four codecs and got three is indistinguishable from one that got four.

Verified 2026-09-10 on the five-seat rig, GStreamer 1.28.6, Apple Silicon, changing one environment variable between two runs of the same flow:

server env	discovery failures	codecs actually offered
default	4 (2 per WHEP sink)	AV1, H265, VP9
GST_PLUGIN_FEATURE_RANK=x264enc:300	0	AV1, H264, H265, VP9

Chrome will not decode H265 over WebRTC in most builds, so Chrome viewers fall back to VP9, encoded per consumer in software: 31% of one core at rest to 91% with five viewers.

What this changes

The block hands an identity to request-encoded-filter. PayloadChainBuilder::build links that element immediately downstream of codec-parser-caps — the capsfilter that does the rejecting — so an EVENT_DOWNSTREAM probe on its sink pad sees a CAPS event exactly when that codec got past the encoder, and nothing when it did not. encoder-setup names the encoder per codec, keyed by the media type the encoder factory's src pad template produces, since the discoveries run concurrently and call order proves nothing.

Worth a reviewer's eye: discovery passes None as the consumer id to request-encoded-filter but the string "discovery" to encoder-setup. The filter is returned only when that id is None, so nothing is spliced into a live viewer's pipeline.

The verdict reaches block health as a new BlockHealthStatus::Degraded, logged at warn!, broadcast as BlockHealthChanged, and shown in amber in the flow list and detail panel:

Block 'whep_out' in flow 'Meeting' is degraded: H.264 was dropped from the offer:
vtenc_h264 failed codec discovery. The pipeline still reports Playing

Degraded deliberately does not satisfy has_failed_block() — the output still serves every viewer that can decode a surviving codec.

BlockDiagnostic is the general hook. The stalled-pad-task scan reaches the flow pipeline's own elements and nothing else; a codec that fails discovery stalls no pad anywhere in it.

The report waits 15 s after the last discovery pipeline is built before calling a verdict, so a slow software AV1 encoder is not mistaken for a dropped codec.

Only the first round of discovery counts, and that is load-bearing. The first round runs when the input caps arrive, with output caps of ANY; its result becomes the codec list the sink will answer a viewer with. Every later round belongs to a viewer that has already connected, and asks a different question: its output caps come from that viewer's SDP, so force_profile is false, codec-parser-caps stops demanding constrained-baseline, and H.264 negotiates on the viewer path even though it failed at startup. Folding that in cleared the verdict. Live on a real backend, before the fix: degraded at 16 s after the flow started, then healthy again 16 s after a viewer connected, while the codec list the sink answers with still had no H.264 in it. The first round's verdict is now final and later rounds are not instrumented at all.

Root cause, for a human to file upstream

Isolated with no webrtcsink in the pipeline. With no profile requested, Codec::parser_caps(force_profile=true) builds video/x-h264, stream-format=avc, profile=constrained-baseline. vtenc_h264 has no profile property and cannot emit it:

gst-launch-1.0 videotestsrc num-buffers=30 ! video/x-raw,width=640,height=360,framerate=30/1 \
  ! videoconvert ! vtenc_h264 ! h264parse \
  ! video/x-h264,stream-format=avc,alignment=au,profile=constrained-baseline ! fakesink

Fails with flow-return=(int)-4. The same line with profile=baseline or profile=main passes. Inside webrtcsink:

vtenc  gst_vtenc_encode_frame:<vtenc_h264-0> Output loop stopped with error (not-negotiated)
GST_CAPS pre_eventfunc_check:<codec-parser-caps:sink> caps video/x-h264, ...,
  stream-format=(string)avc, ..., profile=(string)baseline, ..., lcevc=(boolean)false
  not accepted
webrtcsink lookup_caps: Codec discovery pipeline failed: Internal data stream error.

force_profile is output_caps.is_any() && needs_encoding, and the startup discovery call site passes a hardcoded gst::Caps::new_any(), so nothing outside the element can relax it. gst-plugins-rs does not accept AI-written issues or merge requests, so this is written out for a human to file rather than filed from here. Standalone repro:

gst-launch-1.0 videotestsrc is-live=true pattern=smpte \
  ! video/x-raw,width=1920,height=1080,framerate=30/1 ! whepserversink

Why no workaround ships

Ranking x264enc above vtenc_h264 restores H.264 to the offer but not the reason to want it: x264enc is software, and the hardware encode is the thing that is broken. Total CPU for 30 s of 1080p30, each encoder configured as configure_encoder configures it, two passes in both orders to control for order bias:

encoder	CPU seconds (pass 1 / pass 2)
no encoder: source, videoconvert, fakesink	6.2 / 5.2
vp9enc — today's Chrome fallback	15.5 / 11.4
x264enc — what the rank override selects	16.2 / 15.0
vtenc_h264 — what is broken	5.1 / 4.8

x264enc was dearer than the vp9enc it would replace in both passes. vtenc sits at the no-encoder floor. So the rank change swaps one software encoder for another, process-globally across ingest and recording too, for no measurable server gain — consistent with the earlier rig finding that both arms landed at ~90% of a core for five viewers. Constraining vtenc's caps has no lever either: no profile property, and the demand comes from a hardcoded Caps::new_any() inside the element.

Setting GST_PLUGIN_FEATURE_RANK=x264enc:300 still makes sense for viewer-side decode and battery, but that is a deployment decision, not something to hardcode.

Tests

backend/tests/whep_codec_discovery_test.rs builds a real WHEP Output block through WHEPOutputBuilder, feeds raw video into a real whepserversink, and asserts H.264 is reported as dropped. It forces the failure by removing h264parse from the registry rather than relying on Apple's encoder, so it runs on Linux CI — the same shape, not a different path: request-encoded-filter has already fired for H.264 by the time build_parser errors, so the block sees a codec attempted and never negotiated, exactly as vtenc produces. CODECS is a LazyLock built once per process, so the registry surgery keeps this file to one test.

Ran, green on this branch:

• the integration guard, and confirmed it guards: with attach() stubbed to a no-op it fails; with it, passes
• six unit tests in whep/codec_report.rs (verdict text, missing-encoder branch, no-discovery-yet, hold-across-a-later-round)
• full backend suite with STROM_REQUIRE_GST_PLUGINS=1: 684 passed, 0 failed
• cargo test --test openapi_test after updating the snapshot; types suite; cargo clippy --all-targets -D warnings; frontend clippy for wasm32-unknown-unknown

Verified on this machine but not shipped as a test: the unmodified block against the real vtenc_h264 reports H.264 was dropped from the offer: vtenc_h264 failed codec discovery. CI runs tests on Linux only, so a vtenc assertion would guard nothing there and would start failing the day upstream fixes it.

Also verified end to end on a running headless backend, which is what caught the viewer-round bug above: a flow of videotestsrc into a WHEP Output reports degraded in flow.block_health and in a warn! line 16 s after start, stays running: true with gst_state: Playing, and now holds that verdict across a connecting viewer for 50 s and six discovery rounds with a single health transition logged.

Risk

BlockHealthStatus gains a degraded variant, so openapi.json is regenerated. Additive, but the contract check may flag a new enum value on a response type, and any client matching exhaustively on that enum needs the arm.

backend/src/blocks/builtin/whep.rs is now 2758 lines and wants splitting like pipeline.rs and app.rs. New code went into whep/codec_report.rs rather than growing it further; the split is not in this PR.

🤖 Generated with Claude Code

[wagenet]

Closing: the premise does not hold.

The startup codec discovery failure this was built to surface reaches no WHEP consumer. stream.out_caps is read only by request_webrtcbin_pad's media: None branch, taken when webrtcsink creates the offer; a WHEP client always offers, so select_codec runs instead and re-discovers from the client's SDP caps, where force_profile is false and vtenc passes. Verified with real Chrome (rtph264pay decoding at 1280x720 with no rank override, alongside six logged discovery failures) and with a whepclientsrc pinned to video-codecs="<H264>".

So this would report a lost codec on every macOS WHEP flow while viewers receive it. What survives is BlockDiagnostic and BlockHealthStatus::Degraded, which now have no caller; infrastructure without a consumer is not worth a review. The branch stays if a real trigger turns up.

The underlying gst-plugins-rs defect is real and still worth fixing upstream — the discovery round rejects a working encoder over a constrained-baseline profile the element itself chose, and on a signaller where webrtcsink does create the offer it would cost the codec.