Unclear problem with RTSP URL parameter

[neilyoung]

Question

Hi,

I'm a big fan of MediaMTX. It is a perfect sample of a well working server app, written in GO. I really like it.

I'm having several AWS installations using a fork of MediaMTX 1.6.0, which work flawlessly.

Today I came across a problem which I currently not really understand. Maybe one of you is having a hint how to approach.

Since months I'm using FFMPEG to loop-stream MP4 files towards the RTSP server for redistribution, mostly like so:

ffmpeg -re -stream_loop -1 -i 1.mp4 -c:v libx264 -bf 0 -rtsp_transport tcp   -f rtsp "rtsp://server.com:8554/stream?mode=inference"

The stream then is re-distributed to several inference instances which act as MediaMTX RTSP clients, but this is not the point.

I found, that FFMPEG is really a resource hammer, especially if it comes to transcoding (which is done here), so having this command line once works good, but don't try to stream 3 or 4 like so on an ordinary machine. It will explode :)

I found that a re-streaming w/o transcoding of prepared MP4 files (MOOV Atom available and such) works way less problematic w.r.t. system resources, so an equivalent command line would be like so:

gst-launch-1.0 filesrc location=1.mp4 ! qtdemux ! h264parse ! rtspclientsink location=rtsp://server.com:8554/stream

You might already have notices, that I dropped the ?mode=inference parameter from the URL, because - while working with the FFMPEG command line - exactly this is now NOT working with GStreamer towards MediaMTX.

I'm having attached the obfuscated logs of the initial connection establishment from my machine for the three cases: GST without parameter (works), FFMPEG with parameter (works) and GST with parameter (is refused with 400).

gst-ok-without-parameters.txt

ffmpeg-with-parameter-ok.txt

gst-fail-with-parameter.txt

The traces have been taken with Wireshark on my local machine, which issues the a.m. commands in a console. The command, which fails is

gst-launch-1.0 filesrc location=1.mp4 ! qtdemux ! h264parse ! rtspclientsink location="rtsp://server.com:8554/stream?mode=inference"

The only difference compared to the working GST command it the extra "?mode=inference" URL parameter.

It does also not matter to have a "/" before the "?" or to omit the quotation marks... Doesn't work with the parameter. The traces only show the very first few steps of SDP negotiation, no RTP data contained. Slight obfuscation applied (w.r.t. server names etc).

Any friendly pointer highly appreciated.

[neilyoung]

OK, the problem is somewhere in how the URLs are constructed in /go/src/pkg/mod/github.com/bluenviron/gortsplib/[email protected]/server_session.go, to be found with function findMediaByURL:

In case I don't attach a parameter:

// rtsp://127.0.0.1:8554/stream

call u1.String()
"rtsp://127.0.0.1:8554/stream/stream=0"

call u.String()
"rtsp://127.0.0.1:8554/stream/stream=0"

call baseURL.String()
"rtsp://127.0.0.1:8554/stream/"

=> find positive

In case I attach a parameter:

// rtsp://127.0.0.1:8554/stream?mode=inference

call u1.String()
"rtsp://127.0.0.1:8554/stream?mode=inference/stream=0"

call u.String()
"rtsp://127.0.0.1:8554/stream/stream=0?mode=inference"

call baseURL.String()
"rtsp://127.0.0.1:8554/stream?mode=inference/"

=> find negative

[aler9]

Hello @neilyoung, the URL-related issue with rtspclientsink and rtspsrc was reported in #3295 and fixed with bluenviron/gortsplib#619

[neilyoung]

Confirmed. Thanks