Unable to open srt stream from haivision srt gateway AWS appliance. astits: fetching next packet failed: astits: fetching next packet from buffer failed: astits: reading 188 bytes failed: max buffer size exceeded

[gargolito]

Which version are you using?

1.9.3

Which operating system are you using?

Linux amd64 standard

Describe how to replicate the issue

My use case is to read an encrypted stream from a haivision srt gateway appliance on AWS.

1. start the server
2. publish with HLS (although I've tried rtsp and just srt with with the same problem)
3. read with srt.

I am able to read the same feed with ffmpeg and vlc. Unfortunately I cannot change the configuration on the srt gateway - I intended to use mediamtx to monitor srt feeds at lower resolutions with hls. I have changed my mediamtx config to only do srt and hls and turned off all other options trying to isolate the problem I've tried both with and without SourceOnDemand, but same issue reading - I'm guessing that reading is the actual problem. I'm attaching my config here: mediamtx.yml.gz

the gateway is configured as a listener with these parameters:
link: mtu 1496, ttl 64, ToS 0x68
srt: Latency 300, Encryption AES128

A POSSIBLE SEPARATE ISSUE TO MAKE YOU AWARE OF

Although the transcode to hls does not work for me in this use case, the server continues as though the HLS feed is working, I would expect it to fail or at least indicate that there's a problem, so I think there is something in the code that is not catching the error - I would expect something to the effect of "no sources available."

Server logs

srt_problem_mediamtx.log

Network dump

srt_problem_mediamtx.pcap.gz

[gargolito]

bump

[secit]

@gargolito You might want to take a look at issue #3756, particularly the last comment from me there. This issue discusses similar SRT issues related to higher latency environments and might offer some insights or workarounds relevant to your case.

[gargolito]

@gargolito You might want to take a look at issue #3756, particularly the last comment from me there. This issue discusses similar SRT issues related to higher latency environments and might offer some insights or workarounds relevant to your case.

I cloned your fork and but it failed to compile, I got this message:
# github.com/bluenviron/mediamtx/internal/protocols/mpegts
internal/protocols/mpegts/from_stream.go:32:15: undefined: srtgo.SrtSocket
It seems to me the the go-astits library is the biggest issue here though. bluenviron hasn't updated its dependency on it and the go-astits seems to be stale, the last release was on 8 Aug 2023. There was a commit six months ago that appears to address some issue with descriptors, but it hasn't been released.

I cloned your repo from the refactor-to-srtgo branch, I looked at the diffs in your commit but couldn't see how to resolve the compile error. The imports in the offending file are mostly from mediacommon

PS: I'm using go version go1.24.0 linux/amd64

[secit]

It seems to me the the go-astits library is the biggest issue here though. bluenviron hasn't updated its dependency on it and the go-astits seems to be stale, the last release was on 8 Aug 2023. There was a commit six months ago that appears to address some issue with descriptors, but it hasn't been released.

Thanks for the heads-up on go-astits, you might be right that go-astits is the biggest issue.
I might have a little look at it.

I cloned your repo from the refactor-to-srtgo branch, I looked at the diffs in your commit but couldn't see how to resolve the compile error. The imports in the offending file are mostly from mediacommon

PS: I'm using go version go1.24.0 linux/amd64

Sorry, I forgot to mention that the Makefile doesn't work.
It's because cross compiling CGO is kinda tricky and hasn't been something I've cared about.

Since you're on Linux, it's pretty easy to build the binary.
To get started you have to run go generate ./... and then go build from within the cloned directory.
This will give you a binary that you can run on your system: ./mediamtx

You may have to install libsrt if you haven't done so already, on Ubuntu/Debian it's apt install libsrt-openssl-dev.
There might be other dependencies as well, like g++, etc.
You'll just have to see when you run go build.

[onorua]

what about CPU utilization by srtgo implementation? I've made the changes to my system and it utilizes around 160% of CPU per stream, if the stream is fast enough due to CGO calls.
I had to create my own version of nonlocking srtgo that can handle almost any traffic for about 1.5% of CPU per stream. Which is pretty got for us.

[secit]

@onorua - With 160% CPU per stream, it sounds like you're CPU transcoding on each stream?
The SRT libraries, both srtgo and gosrt should not consume that much CPU.

There is some performance loss with CGO, but if that's an issue then you're already at your HW limit.
I'm currently running 16 input streams and 32 output streams, while transcoding from H264 to H265 with a single Jetson Xavier without any issues. This is with the changes I've made, and it works for me. I was not able to get it to work with the pure go srt library.

[onorua]

I've created PR to srtgo project Haivision/srtgo#77
but it seems it is going to be a dead end, the last PR merged was more than 2 years ago.
With those changes my CPU utilization dropped from 160% to 2% per stream.
If srtgo team will merge the changes, I have a complete srtgo implementation for mediamtx, with all the metrics, logging etc because we use it in production. Alternatively I'll just replace srtgo with my own fork in go.mod

[aler9]

Hello, although opinions about the underlying SRT library are interesting, they are completely off topic here, since the error is related to MPEG-TS, which is a layer below the SRT layer, so you can move the discussion somewhere else.

[aler9]

@gargolito in order to fix this issue, we need to see the unencrypted stream, that unfortunately cannot be inferred from network dumps, since SRT is encrypted. I've created a custom server version that prints the stream in the console (https://github.com/bluenviron/mediamtx/tree/dev/3960), please download it from here (click on "artifacts", "binaries"):

https://github.com/bluenviron/mediamtx/actions/runs/15959278854

then attach a sample log, up to the moment in which you see error "astits: fetching next packet failed: astits: fetching next packet from buffer failed: astits: reading 188 bytes failed: max buffer size exceeded".

[gargolito]

I did not get the issue from the astits libary again but I got some 500 (http) errors, couldn't play the stream in browser with hls.js, ffplay or vlc. This stream goes to our gateway from a different provider, I won't have any ingests from the provider that triggered the astits errors until next month. Here's the log and also some of the output from stdout.

new_log_#3960.zip

[aler9]

@gargolito the dump you posted corresponds to a stream different than the one that triggered the original error, it has a completely different issue, which is not related to SRT ingestion, but is related to HLS remuxing, and furthermore it cannot be used to replicate the second issue too since it's truncated and contains a single packet.

If you want to report bugs, you also have to provide a way to replicate the issue, otherwise we cannot do anything here. If you still have problems, open another bug report and provide a completely way to replicate the issue, either by using dumps or public sources.

[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.