SRT publish with KLV does not have valid KLV on RTSP pulls

[dbussert]

Which version are you using?

d5d1de0

Which operating system are you using?

Linux amd64 standard

Describe the issue

When MPEG-TS SRT with KLV is published, that KLV is available in SRT reads, but RTSP pulls do not have valid KLV. ffmpeg does not recognize the stream as KLV.

Input #0, rtsp, from 'rtsp://127.0.0.1:554/test':
  Metadata:
    title           :
  Duration: N/A, start: 0.025733, bitrate: N/A
  Stream #0:0: Video: hevc (Main), yuv420p(tv), 1920x1080, 29.97 tbr, 90k tbn, 90k tbc
  Stream #0:1: Data: none

Describe how to replicate the issue

1. Use a source that has KLV

Input #0, mpegts, from '<mpegts source>':
  Duration: N/A, start: 6240.863889, bitrate: N/A
  Program 1
  Stream #0:0[0x41]: Video: hevc (Main) ([36][0][0][0] / 0x0024), yuv420p(tv), 1920x1080, 30 fps, 30 tbr, 90k tbn
  Stream #0:1[0x42]: Data: klv (KLVA / 0x41564C4B)

2. Publish a SRT stream with KLV ffmpeg -i <mpegts source> -c copy -map 0 -f mpegts "srt://<ip>:8890?streamid=publish:test&pkt_size=1316"
3. Confirm SRT stream from MediaMTX has KLV ffprobe "srt://<ip>:8890?streamid=read:test"

Input #0, mpegts, from 'srt://127.0.0.1:8890?streamid=read:test':
  Duration: N/A, start: 31.159833, bitrate: N/A
  Program 1
  Stream #0:0[0x100]: Video: hevc (Main) ([36][0][0][0] / 0x0024), yuv420p(tv), 1920x1080, 29.97 tbr, 90k tbn, 90k tbc
  Stream #0:1[0x101]: Data: klv (KLVA / 0x41564C4B)
Unsupported codec with id 100356 for input stream 1

4. Observe RTSP does not have valid KLV

Input #0, rtsp, from 'rtsp://127.0.0.1:554/test':
  Metadata:
    title           :
  Duration: N/A, start: 0.025733, bitrate: N/A
  Stream #0:0: Video: hevc (Main), yuv420p(tv), 1920x1080, 29.97 tbr, 90k tbn, 90k tbc
  Stream #0:1: Data: none
Unsupported codec with id 0 for input stream 1

MediaMTX configuration

MediaMTX logs

Publish SRT

2026/03/25 15:07:48 INF [SRT] [conn 10.0.0.3:64092] opened
2026/03/25 15:07:48 INF [path test] stream is available and online, 2 tracks (H265, KLV)
2026/03/25 15:07:48 INF [SRT] [conn 10.0.0.3:64092] is publishing to path 'test'

Read SRT

2026/03/25 15:09:57 INF [SRT] [conn 127.0.0.1:52487] opened
2026/03/25 15:09:57 INF [SRT] [conn 127.0.0.1:52487] is reading from path 'test', 2 tracks (H265, KLV)
2026/03/25 15:10:02 INF [SRT] [conn 127.0.0.1:52487] closed: EOF

Read RTSP

2026/03/25 15:09:17 INF [RTSP] [session 01953d59] created by 127.0.0.1:41734
2026/03/25 15:09:17 INF [RTSP] [session 01953d59] is reading from path 'test', with TCP, 2 tracks (H265, KLV)
2026/03/25 15:09:18 INF [RTSP] [session 01953d59] destroyed: torn down by 127.0.0.1:41734

Packet dump

No response

[RogerHardiman]

ffmpeg does not recognise KLV in RTSP streams. It can only report it as "Data" with "Unsupported codec id".
I raised a ticket on this with ffmpeg recently (on code.ffmpeg.org) as I was thinking of implementing the missing bit of code in ffmpeg but got no interest on the Issue Report.

[dbussert]

ffmpeg does not recognise KLV in RTSP streams. It can only report it as "Data" with "Unsupported codec id". I raised a ticket on this with ffmpeg recently (on code.ffmpeg.org) as I was thinking of implementing the missing bit of code in ffmpeg but got no interest on the Issue Report.

ffmpeg can see KLV on RTSP fine for me. If I publish RTSP + KLV to MediaMTX, I can pull RTSP + KLV fine (the probe below). The issue I'm seeing is SRT + KLV being transmuxed to RTSP + KLV isn't working, which indicates to me something in MediaMTX isn't handling it right.

Input #0, rtsp, from 'rtsp://<my server>:554/3cdbef1772f4b8368bfec1315cbb79b4':
  Metadata:
    title           : Session streamed with GStreamer
  Duration: N/A, start: 67691.267100, bitrate: N/A
  Program 1
  Stream #0:1: Video: hevc (Main) ([36][0][0][0] / 0x0024), yuv420p(tv), 1920x1080, 30 tbr, 90k tbn
  Stream #0:0: Data: klv (KLVA / 0x41564C4B)
Unsupported codec with id 98311 for input stream 0

[RogerHardiman]

@dbussert . Thanks for the extra information.
I've not had the same results as you but I think I know what has happened.

MediaMTX can carry KLV data in two ways.

1. MPEGTS-over-RTSP is passed into MediaMTX. MediaMTX then outputs the MPEGTS-over-RTSP to ffprobe.
   This works. ffprobe sees KLV data

2. MPEGTS (UDP or via SRT) is passed into MediaMTX. (note this is not MPEG-TS over RTSP).
   MediaMTX then processes the Video and KLV frames.
   But the output from MediaMTX is not MPEG-TS over RTSP.
   The output from MediaMTX is a RTSP with a RTP Video Stream with a RTP SMPTE336M KLV data stream.

This is where ffmpeg fails. It does not know that RTP SMPTE336M data is KLV.

I recreatet this as follows

1. I publish MPEGTS from a file to MediaMTX as UDP (and not SRT)
   ffmpeg -re -stream_loop -1 -i ABC.ts -map 0 -c:v copy -f mpegts udp://127.0.0.1:8960?pkt_size=1316
   This uses a setting in mediamtx.yml for "my_camera" to receive udp+mpegts on Port 8960

2. I use ffprobe and get DataLNone

Input #0, rtsp, from 'rtsp://127.0.0.1:8554/my_camera':
  Metadata:
    title           :
  Duration: N/A, start: 0.000000, bitrate: N/A
  Stream #0:0: Video: hevc (Main), yuv420p(tv), 1280x720, 29.97 tbr, 90k tbn, start 0.066000
  Stream #0:1: Data: none
Unsupported codec with id 0 for input stream 1

And this happens because MediaMTX is sending RTP Video and RTP SMPTE336M data

If MediaMTX combined the Video and KLV into a MPEGTS-over-RTSP output, ffprobe would show KLV
But currently it does not do that.

We need ffmpeg to know what RTP SMPTE336M is.

So I am pretty sure this is what is happening here.
But let me know if I've got something wrong

Roger

[dbussert]

I think you're right. Although ffmpeg understanding RTP SMPTE336M would be useful, it would be just as helpful if MediaMTX transmuxed UDP/SRT MPEG-TS inputs into RTSP MPEG-TS which is a format ffmpeg already understands. Is it useful to anyone in the world to have separate RTP KLV (especially since ffmpeg doesn't understand it)?

[RogerHardiman]

Is it useful to anyone in the world to have separate RTP KLV (especially since ffmpeg doesn't understand it)?

Yes, it is useful.
FFmpeg does understand that there is a "data stream" and will output the data stream as raw payload data. It is just that it does not match a "codec type". I know of two commercial applications using the ffmpeg libraries that handle MediaMTX RTP SMPTE336M output, and of other open source libraries (Yellowstone) that handle it.

I assume MediaMTX did this way to support KLV over WebRTC.
WebRTC uses RTP as the video/audio/data payload.

[dbussert]

I assume MediaMTX did this way to support KLV over WebRTC. WebRTC uses RTP as the video/audio/data payload.

Great point that it is useful, but I come back to the inconsistency where MediaMTX treats RTSP with MPEG-TS KLV different than SRT with MPEG-TS KLV. Why not make the output of both the same (MPEG-TS KLV or RTP KLV).

[aler9]

Hello, the standardized way of transmitting KLV with RTSP/RTP is RFC6597, which was referred here as "RTP SMPTE 336M":
https://datatracker.ietf.org/doc/html/rfc6597

In MediaMTX, when KLV comes in from another protocol, it is converted into RTP SMPTE 336M.

If FFmpeg does not support that, it's a FFmpeg issue, not a MediaMTX one.

We cannot and will not output RTSP tracks as MPEG-TS-inside-RTP to work around a FFmpeg issue, since it's a waste of bandwidth, makes packet reordering and stream healing worse, and would cause incompatibilities in any other area other than KLV.

You can either improve FFmpeg or use another protocol to read KLV.