RTSP SDP Parameters / H265 HDMI Extender Decoder #3505
Replies: 1 comment
-
Hello,
Your analysis is correct, in MediaMTX the control attribute contains an absolute path, while in other RTSP implementations you can find a relative one. We did this change in bluenviron/gortsplib#210 because GStreamer was unable to merge together all the elements that make a RTSP path, that are the base URL inside If you need a different behavior, you can download gortsplib and remove these lines: Then download MediaMTX, edit go.mod and add a link to your custom gortsplib:
Then compile the server:
|
Beta Was this translation helpful? Give feedback.
-
Question
Version: MediaMTX v1.8.3 on Debian 12
I came up with an interesting use of MediaMTX but I've hit a bit of a snag.
Background:
I have been testing a h264/h265 media decoder: HDC-E5200K, rebranded as a "Monoprice Blackbird H.265 HDMI over IP Decoder/Receiver" https://www.monoprice.com/product?p_id=43625
The thought was that MediaMTX could be used as a software-based routing solution for many of these decoders.
These decoders immediately power on and search for an RTSP server to stream from at 192.168.10.10
The main issue that I am running into is that the SDP control parameters returned by MediaMTX causes the decoder to have a malformed RTSP request.
MediaMTX log:
This is the SDP response from the official encoder:
This is the SDP response from MediaMTX:
It looks like this is because the SDP control parameter consists of the entire media RTSP path rather than just the track name. I have gone through the documentation and config files, but haven't found any obvious ways to manipulate the SDP responses for troublesome clients.
Beta Was this translation helpful? Give feedback.
All reactions