Regression in v1.19.0: H.264 RTSP sources with packetization-mode 0 are rejected ("unsupported packetization mode: 0"), worked in v1.18.2 (original) (raw)

Which version are you using?
v1.19.0 (regression from v1.18.2)

Which operating system are you using?
Linux amd64 (also reproduced with the official linux_amd64 release binary)

Describe the issue

After upgrading from v1.18.2 to v1.19.0, a number of our H.264 IP cameras stopped delivering any media. MediaMTX connects to the source, the H.264 track is announced, and then the source errors out with:

[path xxx] [RTSP source] unsupported packetization mode: 0

The path reports ready: true and a single H264 track, but bytesReceived stays at 0 and no HLS/RTSP output is ever produced — the stream is effectively dark.

These same cameras ingest and serve normally on v1.18.2. Rolling the node back to v1.18.2 immediately restores them.

I traced this to the v1.19.0 changelog entry "forbid H264 packetization mode zero", which pulls in gortsplib PR bluenviron/gortsplib#1072 (merged 2026-05-24, commit 2f2779cad7a54f18df884ca53e16f2394f1cec07). I understand this was deliberate, with the stated rationale that "packetization mode zero requires allowing inefficient and brittle fragmented UDP packets."

The trigger is RTP H.264 packetization-mode 0 (single NAL unit mode) — cameras whose SDP a=fmtp line sets packetization-mode=0 or omits packetization-mode entirely (RFC 6184 §8.2.1 treats the absent attribute as mode 0). This is common on budget/older IP cameras; in our fleet it affects a meaningful number of Hikvision-compatible units we cannot reconfigure source-side.

The reason for filing: the stated rationale is specifically about UDP packet fragmentation, but our affected sources are pulled over TCP (interleaved), where that concern doesn't apply — there's no MTU/fragmentation problem on a TCP transport. Despite that, v1.19.0 rejects mode 0 unconditionally, regardless of transport. Since v1.18.2 handled these streams without issue, this is a breaking change for anyone fronting older cameras over TCP.

Would you consider one of:

  1. Restoring mode-0 ingestion, at least when the source is read over TCP/interleaved (where the fragmentation rationale doesn't hold); or
  2. Making the rejection opt-in / overridable via a per-path or per-source flag, rather than a hard, unconditional refusal?

Describe how to replicate the issue

  1. Point a v1.19.0 path source: at an RTSP H.264 camera that advertises packetization-mode 0 (or whose fmtp omits packetization-mode), using rtspTransport: tcp.
  2. Observe in the log: [RTSP source] unsupported packetization mode: 0.
  3. GET /v3/paths/get/<path> shows ready: true, one H264 track, bytesReceived: 0.
  4. Run the same source against v1.18.2 → ingests fine, media flows, HLS/RTSP output works.

I verified this side-by-side on the same host with the same source URL and tcp transport: v1.18.2 delivers media, v1.19.0 rejects with the error above and delivers zero bytes.

Did you attach the server logs?
Can provide on request — relevant lines are started → stream is available and online, 1 track (H264) → unsupported packetization mode: 0, repeating on each retry.

Did you attach a network dump?
Can provide a sanitized SDP / capture of an affected source on request (credentials and addressing redacted).