SRT source from Sony A40 camera doesn't work

[llamafilm]

Which version are you using?

1.15.1

Which operating system are you using?

Other (MacOS arm64) (same issue in Docker too)

Describe the issue

I've been using MediaMTX successfully with SRT source from Panasonic AW-UE50 camera. Now I'm trying a new camera, Sony SRG-A40 and it doesn't work.

Describe how to replicate the issue

1. start the MediaMTX with this config
2. read with WebRTC. (RTSP and SRT readers have the same problem too)

The issue seems to happen only with this specific SRT source so I'm not sure how to reproduce without having that camera. I tried replicating the SRT source as close as possible using ffmpeg but could not get it to fail that way.

MediaMTX configuration

logLevel: debug
authMethod: internal
authInternalUsers:
- user: any
  permissions:
  - action: read
paths:
  sony:
    source: srt://192.168.20.123:2020?passphrase=12345678901234567890
  panasonic:
    source: srt://192.168.4.192:2020?passphrase=12345678901234567890

MediaMTX logs

mediamtx.log

Network dump

https://drive.google.com/file/d/1zsjkU9fFauLymU1HaI_raAzPt6cE8VmH/view?usp=sharing

[llamafilm]

The packet capture shows SRT video being received from both cameras and I don't see any signs of error there. I tried disabling the passphrase and that didn't help.

FFmpeg can read the Sony stream just fine.

 % ffplay -hide_banner "srt://192.168.20.123:2020?passphrase=12345678901234567890"
Input #0, mpegts, from 'srt://192.168.20.123:2020?passphrase=12345678901234567890':
  Duration: N/A, start: 3.303300, bitrate: N/A
  Program 1 
  Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(tv, bt709, progressive), 1920x1080, 29.97 fps, 29.97 tbr, 90k tbn, start 3.303300

If I use ffmpeg to remux the SRT and publish to mediaMTX like this then it works OK:

ffmpeg -hide_banner -i "srt://192.168.20.123:2020?passphrase=12345678901234567890" \
  -c copy -f rtsp rtsp://localhost:8554/proxy

It seems like there is something about the video essence that MediaMTX doesn't like, but ffmpeg can tolerate. I would be willing to sponsor development on this.

[secit]

@llamafilm Have you had a chance to test my Haivision fork yet? If not, could you check whether the same issue occurs there as well? This might help determine whether the problem stems from the SRT implementation or elsewhere.

Unfortunately, since the Haivision library isn’t pure Go, I haven’t provided precompiled binaries for macOS. You’ll need to install libsrt manually and compile mediamtx from source on your Mac.

Best option would be if you have a Linux system you can test on — then you can just download the binaries from my forked repo, which would save time and avoid the need for manual compilation.

If you need guidance with the installation or compilation process, feel free to open a ticket in my forked repository. That way, we can keep this thread focused on the main topic while addressing technical details in the appropriate place.

[llamafilm]

@secit thank you for the advice! I tried your binary in a Docker container and it has the same issue.

[llamafilm]

The debug log I shared before was from a WebRTC client which is my real goal, but that protocol is rather complicated, so here's the result from ffmpeg trying to read as SRT. My guess is the problem lies in the mpegts parser but I don't know enough to dig further than that.

% ffmpeg -hide_banner -i "srt://127.0.0.1:8890?streamid=read:sony" 
[mpegts @ 0x140a04d60] Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
Input #0, mpegts, from 'srt://127.0.0.1:8890?streamid=read:sony':
  Duration: N/A, start: 341.141333, bitrate: 127 kb/s
  Program 1 
  Stream #0:0[0x100]: Video: h264 ([27][0][0][0] / 0x001B), none, 90k tbr, 90k tbn
  Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 127 kb/s, start 341.141333

[secit]

@llamafilm I think you're absolutely right. It appears SRT itself is functioning correctly, and the issue likely stems from the encapsulated MPEG-TS data.

It's been a few years since I analyzed raw MPEG-TS/h264 data, but would you be able to share a similar network dump without SRT encryption applied?

[llamafilm]

Sure, here it is without encryption. This shows the initial connection from mediamtx, and a few seconds of video while the ffmpeg reader tries to start. This video should be 1920x1080, 29.97, yuv420p, high profile, CBR 8Mbps, with I-frames once per second, and no audio. (This problem is the same with or without audio, so I disabled it on the camera to simplify)

https://drive.google.com/file/d/1mUv51RsP2yIPFTeEvHPGLI_q2wHxiRxf/view?usp=sharing

[secit]

Great — I dug into the network capture you attached and here are the findings.

I extracted the MPEG‑TS packets from the capture, replayed the extracted stream into MediaMTX and reproduced the exact behavior you reported. I traced the packets through MediaMTX and narrowed the problem to the MPEG‑TS parsing stage. Testing the same data directly with the Go library go-astits produced the same incorrect behavior.

Next steps would be to validate whether the issue is caused by malformed MPEG‑TS packets or by the go-astits parser.

My current hypothesis is that the TS-level packets look well-formed and the problem is in the stream of PES packets or how they are parsed by go-astits. Because FFmpeg plays the extracted stream without issues, this points toward a parser compatibility bug in go-astits rather than corrupted stream from the camera.

Caveats: the go-astits repository appears inactive, so a PR may not be reviewed or merged promptly. My time and resources for further investigation are limited, so I can’t commit to a timeline for fixing it myself either.

Preliminary conclusion: the issue reproduces outside MediaMTX and most likely originates in the go-astits MPEG‑TS PES parsing rather than from corrupted camera stream.

Maybe a bug ticket should be opened there instead?

[llamafilm]

I appreciate your help. I did some investigation and I agree, it seems like astits only finds 1 PES packet in this file. I opened an issue over there with sample code and video file from a different camera which works fine.

[secit]

I’ve opened a PR against go-astits.
Once it’s merged, MediaMTX can be updated with it and this should resolve the issue

[bluenviron-bot]

This issue is being locked automatically because it has been closed for more than 6 months.
Please open a new issue in case you encounter a similar problem.