Which version are you using?
1.19.3
Which operating system are you using?
Linux arm64 standard
Describe the issue
Description
When playing an H.264 stream over MoQ using Safari on iOS 26.5.2 (the first Safari
version to add WebTransport support is since 26.4), the browser fails to decode the video with
the following error, retried indefinitely:
"the browser you are using does not support video codec avc3.640028, retrying
in some seconds"
The same path/stream plays correctly in Chrome and Edge. Streams encoded in
H.265 (hev1/hvc1) work fine in Safari as well — the issue appears specific to
the H.264 "avc3" (in-band parameter sets) codec string.
Environment
- mediamtx version: v1.19.3 (same result was already present on v1.19.2)
- Server OS: Debian 13 (Raspberry Pi)
- Browser: Safari on iOS 26.5.2
- Source codec: H.264, resolution 1280x720, "avc3.640028" as reported by the
player error
Steps to reproduce
- Configure a MoQ-enabled path in mediamtx backed by an H.264 RTSP source
- Open the built-in MoQ player page (https://:/) in
Safari on iOS 26.4+
- Observe the codec error above; video never starts
Expected behavior
Video should decode and play, as it does in Chromium-based browsers.
Additional context / possible cause
Per the W3C WebCodecs Codec Registry, the "avc3." codec string prefix is
intentionally treated as equivalent to "avc1." by a spec-compliant decoder —
the difference (in-band vs out-of-band SPS/PPS) is not meant to be a material
distinction for decoder input. It's possible Safari's very recent WebCodecs
implementation does not yet perform this avc3 → avc1 normalization internally,
while it does correctly report support for streams announced with the "avc1."
prefix and an out-of-band description.
Would it be feasible for mediamtx's MoQ player/publisher to advertise H.264
tracks as "avc1." (with out-of-band parameter sets/description) instead of
"avc3." — either unconditionally, or specifically as a fallback when the
client is detected as Safari/WebKit? Happy to help test if there's an
experimental build or flag to try.
Describe how to replicate the issue
- start the MediaMTX
- publish with ...
- read with ...
MediaMTX configuration
MediaMTX logs
No response
Packet dump
No response
Which version are you using?
1.19.3
Which operating system are you using?
Linux arm64 standard
Describe the issue
Description
When playing an H.264 stream over MoQ using Safari on iOS 26.5.2 (the first Safari
version to add WebTransport support is since 26.4), the browser fails to decode the video with
the following error, retried indefinitely:
"the browser you are using does not support video codec avc3.640028, retrying
in some seconds"
The same path/stream plays correctly in Chrome and Edge. Streams encoded in
H.265 (hev1/hvc1) work fine in Safari as well — the issue appears specific to
the H.264 "avc3" (in-band parameter sets) codec string.
Environment
player error
Steps to reproduce
Safari on iOS 26.4+
Expected behavior
Video should decode and play, as it does in Chromium-based browsers.
Additional context / possible cause
Per the W3C WebCodecs Codec Registry, the "avc3." codec string prefix is
intentionally treated as equivalent to "avc1." by a spec-compliant decoder —
the difference (in-band vs out-of-band SPS/PPS) is not meant to be a material
distinction for decoder input. It's possible Safari's very recent WebCodecs
implementation does not yet perform this avc3 → avc1 normalization internally,
while it does correctly report support for streams announced with the "avc1."
prefix and an out-of-band description.
Would it be feasible for mediamtx's MoQ player/publisher to advertise H.264
tracks as "avc1." (with out-of-band parameter sets/description) instead of
"avc3." — either unconditionally, or specifically as a fallback when the
client is detected as Safari/WebKit? Happy to help test if there's an
experimental build or flag to try.
Describe how to replicate the issue
MediaMTX configuration
MediaMTX logs
No response
Packet dump
No response