RTSP runOnDemand keeps Gstreamer source running until 60s session timeout #3109
Replies: 2 comments 4 replies
-
|
Yes it is because the the RTSP session is not being torn down correctly, so it's keeping the listener around in case of a potential reconnect. This timeout duration is hardcoded in some library (gortsplib? cant remember, its been a while) and not configurable via mediamtx. One way around this is to create some IPC "callback" in the runOnUndemand hook. There, you can notify your application that all stream consumers have abandoned your stream and decide if you want to tear down the RTSP session ahead of the timeout. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your assistance. I've been trying to wrap my brain around what that might entail and haven't come up with anything to try yet. Would you or someone be able to provide an example/hint of what to put in the runOnUnDemand hook or further explain what an IPC "callback" would look like? I'm currently thinking that this would be something like knowing the process ID generated from the runOnDemand call and killing it when somehow detecting the "2024/02/25 00:13:23 INF [RTSP] [conn 192.168.10.133:58145] closed: EOF" in MediaMTX. That seems likely to cause problems with the runOnDemand command closing though. As I currently understand, I'm configured to have MediaMTX be my "application" and am wanting to keep it that way, if possible. Thank You |
Beta Was this translation helpful? Give feedback.
-
|
When it comes time for a hook to be run, MediaMTX will attempt execute whatever value you have configured for that hook. So whatever it is that you need to do, you could do it there with some shell command. |
Beta Was this translation helpful? Give feedback.
-
|
Doing some experiments using a shell script to start and stop the gstreamer video stream I observed that the runOnUnDemand still doesn't execute until after the session timeout so this doesn't seem like a viable workaround to me currently. I did find if I killed the gstreamer stream process manually/externally to MediaMTX that the "readTimeout" parameter in the mediamtx.yml file is respected and destroys the session according the provided time. But then I receive system messages: Is it not a bug that MediaMTX isn't destroying the session when receiving the "INF [RTSP] [conn [::1]:34110] closed: EOF"? Best Regards |
Beta Was this translation helpful? Give feedback.
-
|
There are other hooks. Like runOnUnRead. I wouldn't call it a bug. It allows time for a reconnect in the event of a network drop. |
Beta Was this translation helpful? Give feedback.
-
|
Moving the gstreamer command to runOnRead or runOnReady both result in: (As a side note, I did try changing the sessionTimeout in the gortsplib>server.go file, s.sessionTimeout = 1 *2 * time.Second) and this did stop the steam like I want so I can start it again but I understand better now why this isn't a great thing to do). Perhaps using the runOnDemand isn't the correct method either. I can't seem to restart my stream that way which was basically the reason behind creating this discussion. It looks like the preferred way is to start up MediaMTX and then publish a stream to it. I tried this originally (using the same command I put in runOnDemand in the OP) but for reasons unknown to me I can't get VLC or AgentDVR software to display a stream and it is sending ~200-500 byte RTP packets instead of the more typical ~1500 byte packets I see when it is working, as observed with Wireshark . Any idea what might cause this? 2024/03/11 14:24:40 INF MediaMTX v1.6.0 (Above I see that VLC sends a TEARDOWN which closes the session, as expected) Best Regards |
Beta Was this translation helpful? Give feedback.
-
Question
Greetings,
I'm new to MediaMTX but impressed with what I've seen with its functionality and community support. I'm currently observing an issue on my custom Onvif image sensor setup. I'm currently using the built release file v1.6.0_linux_arm64v8 (I was also having the same issue on v1.5.1 that I built from source). I'm using AgentDVR crossplatform software to capture the steam from an embedded system running Yocto Kirkstone Linux that has the image sensor attached.
There are a few hardware related plugins in my gstreamer command but the runOnDemand is as follows:
runOnDemand: gst-launch-1.0 v4l2src io-mode=dmabuf-import device=/dev/video3 ! video/x-bayer, width=2600, height=1952, format=grbg10 ! tiovxisp sink_0::device=/dev/v4l-subdev2 sensor-name=SENSOR_ONSEMI_AR0521 dcc-isp-file=/opt/imaging/ar0521/linear/dcc_viss_GRBG_10b_2600x1952.bin sink_0::dcc-2a-file=/opt/imaging/ar0521/linear/dcc_2a_GRBG_10b_2600x1952.bin format-msb=9 sink_0::pool-size=8 src_0::pool-size=8 ! queue ! v4l2h264enc ! rtspclientsink location=rtsp://localhost:554/testHere is the output of my server log:
I'm not sure why it is keeping the session open after receiving "2024/02/25 00:13:23 INF [RTSP] [conn 192.168.10.133:58145] closed: EOF"
I can't start streaming from the image sensor successfully again unless I let it timeout, which is unwanted behavior for me. Perhaps I can easily change the Session Timeout time (perhaps just as a test)?
Or is this perhaps due to AgentDVR not sending the proper message to disconnect and close the session?
I was (perhaps incorrectly) expecting an RTSP TEARDOWN but didn't see one in Wireshark using an rtsp filter. AgentDVR is able to stop and start as fast as I can manually enable and disable the stream using another Onvif image sensor product however.
I also don't experience this issue using Gstreamer's gst-rtsp-server library's test example instead but getting away from that is why I'm evaluating MediaMTX.
Thank you for your support
Beta Was this translation helpful? Give feedback.
All reactions