SRT/MPEG-TS source: audio track not detected at stream start (HEVC + AAC), only after mediamtx restart

Which version are you using?

v1.19.2 (FreeBSD) — also reproduced on v1.20.1 (Ubuntu Linux amd64)

Which operating system are you using?

Other (please describe)

Describe the issue

FreeBSD (primary/production environment), also reproduced on Linux amd64 standard (Ubuntu) with the latest version to rule out a version-specific bug.

When ingesting SRT/MPEG-TS from a cellular link-bonding encoder (Kiloview P3 Mini via KiloLink bonding), mediamtx frequently detects only the video track (H265) and never the audio track (AAC) at stream start, even though the audio is genuinely present in the stream.

Log at stream start:

INF [path camera3] stream is available and online, 1 track (H265) WAR [SRT] [conn :] 46 decode errors, last was: received data from undeclared track with PID 482

PID 482 is our audio track. It is never declared, so every subsequent audio packet is rejected as "undeclared track" for the entire lifetime of that path/session.

Restarting mediamtx while the same source keeps streaming immediately fixes it — both tracks are then detected correctly. This confirms the audio is present in the stream from the start; mediamtx simply fails to see it during its initial detection window.

We believe the root cause is a combination of (1) mediamtx performing track detection in a single pass on the first packets of a new SRT connection, and (2) our bonding aggregator needing 1-3 seconds to synchronize its multiple cellular links after starting a session, during which the resulting MPEG-TS stream is measurably corrupted. We verified this independently with ffprobe against the same raw source, which reports repeated errors during the first seconds:

[hevc @ ...] PPS id out of range: 0 [hevc @ ...] Error parsing NAL unit #0.

...but still correctly identifies both HEVC video and AAC audio tracks, because its default analyzeduration/probesize (5s) is long enough to look past this corrupted startup window — unlike mediamtx's detection, which appears to be fixed and not reconsidered later.

Workaround confirmed in production: inserting an ffmpeg relay between the encoder and mediamtx (ffmpeg -analyzeduration 2000000 -probesize 2000000 -i srt://... -c copy -f mpegts srt://127.0.0.1:8890?streamid=publish:camera3) reliably absorbs the corrupted startup window. Both tracks are then detected correctly by mediamtx on every test (dozens of start/stop cycles).

Feature request: a configurable analysis window for SRT/MPEG-TS sources (similar to ffmpeg's analyzeduration/probesize), e.g. an optional mpegtsAnalyzeDuration (default 0 = current behavior, to avoid changing behavior for existing users), would let us remove the external ffmpeg relay entirely. This would help anyone ingesting from bonding/aggregation encoders, where the very start of a session is inherently less reliable than steady state.

For context, we also tested the same source against Nimble Streamer, which detects both tracks correctly from the start without requiring any relay — suggesting this is specifically related to mediamtx's detection window rather than an inherent limitation of the source stream.

Describe how to replicate the issue

1. Configure a path with source: publisher (SRT listener mode), expecting HEVC video + AAC audio over MPEG-TS.
2. Start a source where the first ~1-3 seconds of the stream contain corrupted/incomplete TS packets — reproducible with any encoder/network path exhibiting startup jitter (in our case, a cellular link-bonding aggregator; likely also reproducible by artificially corrupting/dropping the first ~1-2s of packets of any HEVC+AAC SRT stream).
3. Observe mediamtx logs only 1 track and rejects subsequent audio packets as "undeclared track".
4. Restart mediamtx while the source keeps streaming → both tracks are now detected correctly.

MediaMTX configuration

default settings:

srt: yes
srtAddress: :8890

paths:
  camera1:
    source: publisher

MediaMTX logs

INF [path camera3] stream is available and online, 1 track (H265) WAR [SRT] [conn :] 46 decode errors, last was: received data from undeclared track with PID 482

Yes (see log excerpt above). Happy to attach a full log file or a packet capture (pcap) of a reproducing session if useful — let me know the preferred format.

Packet dump

No response