Skip to content

supported_codecs.md

Latest commit

 

History

History
76 lines (61 loc) · 4.15 KB

supported_codecs.md

File metadata and controls

76 lines (61 loc) · 4.15 KB
Raw

Supported Video Codecs & Profiles

srt-whep does not transcode — it forwards whatever the SRT source encodes, so the H.264 profile the browser negotiates against is chosen by your encoder, not by srt-whep. The tables below record which profiles play in each browser, alongside the profile-level-id srt-whep actually advertised in its WebRTC SDP offer.

⚠️ profile-level-id values are encoder-dependent. Browsers accept or reject based on the profile (Constrained Baseline / Main / High / …); the exact hex varies by encoder (constraint-flag bits) and by the level, which depends on resolution/framerate/bitrate. The IDs below were observed at 1280×720, Level 3.1. For example, x264's "baseline" and "constrained-baseline" both emit 42c01f, and only Apple VideoToolbox emits Constrained High 640c1f.

macOS — verified 2026-07-08

Stack: GStreamer framework 1.28.4 (rswebrtc 0.15.2), current Chrome & Safari. Sources generated with x264 (x264enc) except Constrained High, which only Apple VideoToolbox (h264_videotoolbox) emits.

Profile Offered profile-level-id Chrome Safari Notes
Constrained Baseline 42c01f ✅ ✅ The only profile Safari accepts over WHEP.
Baseline 42c01f ✅ ✅ x264's baseline is constrained baseline (it sets constraint_set1); a true non-constrained Baseline (42001f) is not produced by common encoders, so it is byte-identical to the row above.
Main 4d401f ✅ ❌ Safari refuses at SDP negotiation (m=video port 0).
High 64001f ✅ ❌ Safari refuses at SDP negotiation (m=video port 0).
High 4:4:4 Predictive — ❌ ❌ Not deliverable: the WebRTC sink refuses 4:4:4 H.264, so srt-whep never produces an SDP offer (POST /channel → HTTP 503). No browser can connect.
Constrained High 640c1f ❌ ❔ Chrome refuses at SDP negotiation (m=video port 0); Safari could not be confirmed. Treat as unsupported.

Ubuntu — not re-verified (historical)

These rows are from an earlier test pass and were not re-checked on 2026-07-08. The profile-level-id values are the canonical Level-3.1 forms rather than what a specific encoder emits (see the note above).

Profile profile-level-id Chrome
Constrained Baseline 42e01f ✅
Baseline 42001f ✅
Main 4d001f ✅
High 64001f ❔
High 4:4:4 Predictive f4001f ✅
Constrained High 640c1f ❔

Takeaways

  • Safari (macOS) only plays Constrained Baseline over WebRTC/WHEP. For a Safari-compatible stream, encode H.264 constrained-baseline — e.g. x264enc … ! video/x-h264,profile=constrained-baseline or ffmpeg -profile:v baseline.
  • Chrome (macOS) plays Constrained Baseline, Main, and High, but not Constrained High (640c1f) nor High 4:4:4.
  • High 4:4:4 does not work at all on the current GStreamer stack — srt-whep cannot produce an offer for it (this differs from an earlier pass that marked Chrome ✓).

Troubleshooting: "connects but no media" in Safari

If a stream plays in Chrome but Safari shows no media even for Constrained Baseline, the cause is usually the player, not the codec:

  1. Mixed content. The hosted WHEP player is served over HTTPS; a request from it to http://localhost:8000/channel is mixed content, which Safari blocks more aggressively than Chrome.
  2. Wrong WHEP mode. Some players attempt client-initiated WHEP (they POST their own SDP offer). srt-whep is server-initiated only and rejects a non-empty POST body with "Empty body expected. Client initialization not supported."

Use a player served over plain http:// on the same host that speaks server-initiated WHEP: empty POST /channel → read the server's offer and Location → PATCH your answer to that Location.

See also the codec-test harness under .claude/skills/run-srt-whep-codec-test to reproduce this table (per-profile sources + a local diagnostic player).