search

bluenviron / mediamtx

Ready-to-use SRT / WebRTC / RTSP / RTMP / LL-HLS media server and media proxy that allows to read, publish, proxy, record and playback video and audio streams.
MIT License
10.79k stars 1.4k forks source link

WebRTC Listener not working after reading before publishing #2070

Open Velt1 opened 11 months ago

Velt1 commented 11 months ago

Which version are you using?

v[0.23.6]

Which operating system are you using?

Describe the issue

I have a robot that streams its rtsp streams to a mediamtx server. And I have a website that requests the webrtc streams. My robot needs about 90 seconds until he publishes his rtsp stream to mediamtx. Meanwhile my website is trying to get the webrtc streams. In the server logs i can see that the webrtc offers are received but as soon as the rtsp stream is published the webrtc listener doesnt work anymore. If i wait until the rtsp stream is published and then request the webrtc stream, the webrtc listener works fine.

Describe how to replicate the issue

  1. start the server
  2. read with WebRTC
  3. publish RTSP Stream

Did you attach the server logs?

no

Did you attach a network dump?

No

no

IsaiahULife commented 11 months ago

I also had a similar issue with a robot streaming over rtsp on both versions 0.23.6 and 0.23.7

vicmassy commented 11 months ago

Same issue here

aler9 commented 11 months ago

Hello, i tried to replicate the issue but in my case everything worked flawlessly. I opened the WebRTC page in chrome:

http://localhost:8889/stream/

then i published a sample video (H264 + AAC) with RTSP:

ffmpeg -stream_loop -1 -re -i sample_1080p_h264_baseline.mp4 -c copy -f rtsp rtsp://localhost:8554/stream

After some seconds, video appears on the browser without refreshing the page.

Please attach server logs with logLevel: debug in order to analyze the entire process.

Velt1 commented 11 months ago

I found out that if I use "debug" verbose it works fine but if I use the "info" verbose it has the problem i mentioned.

aler9 commented 11 months ago

Without logs it's gonna be very difficult to find out where the issue is. Open Developer Tools in the Browser (F12), replicate the issue and attach a screenshot of the "Network" tab.

Velt1 commented 11 months ago

This is what it looks like: Screenshot from 2023-07-26 15-56-45

These are the mediamtx info logs: Jul 26 04:48:48 raspberrypi sudo[986]: 2023/07/26 04:48:48 INF [WebRTC] [session 17864e05] closed (no one is publishing to path 'stre Jul 26 04:48:48 raspberrypi sudo[986]: 2023/07/26 04:48:48 INF [WebRTC] [session 11301bfb] created by 192.168.111.155 Jul 26 04:48:48 raspberrypi sudo[986]: 2023/07/26 04:48:48 INF [WebRTC] [session 11301bfb] closed (no one is publishing to path 'stre Jul 26 04:48:49 raspberrypi sudo[986]: 2023/07/26 04:48:49 INF [WebRTC] [session f233eb60] created by 192.168.111.155 Jul 26 04:48:49 raspberrypi sudo[986]: 2023/07/26 04:48:49 INF [WebRTC] [session f233eb60] closed (no one is publishing to path 'stre Jul 26 04:48:50 raspberrypi sudo[986]: 2023/07/26 04:48:50 INF [WebRTC] [session b304e068] created by 192.168.111.155 Jul 26 04:48:50 raspberrypi sudo[986]: 2023/07/26 04:48:50 INF [WebRTC] [session b304e068] closed (no one is publishing to path 'stre Jul 26 04:48:50 raspberrypi sudo[986]: 2023/07/26 04:48:50 INF [WebRTC] [session 1d859bc9] created by 192.168.111.155 Jul 26 04:48:50 raspberrypi sudo[986]: 2023/07/26 04:48:50 INF [WebRTC] [session 1d859bc9] closed (no one is publishing to path 'stre Jul 26 04:48:50 raspberrypi sudo[986]: 2023/07/26 04:48:50 INF [WebRTC] [session 688aff58] created by 192.168.111.155 ~ ~ ~ lines 1-20/20 (END) pi@raspberrypi:~ $ sudo systemctl status rtsp-server.service ● rtsp-server.service - MediaMTX Service Loaded: loaded (/etc/systemd/system/rtsp-server.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2023-07-26 04:47:44 HDT; 1min 58s ago Process: 516 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS) Main PID: 986 (sudo) Tasks: 10 (limit: 1911) CGroup: /system.slice/rtsp-server.service ├─986 /usr/bin/sudo /bin/bash -c cd /home/pi/mediamtx_v0.23.7_linux_arm64v8 && ./mediamtx ./mediamtx.yml └─988 ./mediamtx ./mediamtx.yml

Jul 26 04:49:14 raspberrypi sudo[986]: 2023/07/26 04:49:14 INF [RTSP] [session 9409d1b7] is publishing to path 'stream3', with UDP, 1 Jul 26 04:49:14 raspberrypi sudo[986]: 2023/07/26 04:49:14 INF [RTSP] [conn 192.168.123.14:58848] opened Jul 26 04:49:14 raspberrypi sudo[986]: 2023/07/26 04:49:14 INF [RTSP] [session 3013a213] created by 192.168.123.14:58848 Jul 26 04:49:14 raspberrypi sudo[986]: 2023/07/26 04:49:14 INF [RTSP] [session 3013a213] is publishing to path 'stream2', with UDP, 1 Jul 26 04:49:15 raspberrypi sudo[986]: 2023/07/26 04:49:15 INF [RTSP] [conn 192.168.123.13:33896] opened Jul 26 04:49:15 raspberrypi sudo[986]: 2023/07/26 04:49:15 INF [RTSP] [session cfc52bed] created by 192.168.123.13:33896 Jul 26 04:49:15 raspberrypi sudo[986]: 2023/07/26 04:49:15 INF [RTSP] [session cfc52bed] is publishing to path 'stream', with UDP, 1 Jul 26 04:49:15 raspberrypi sudo[986]: 2023/07/26 04:49:15 INF [RTSP] [conn 192.168.123.13:33898] opened Jul 26 04:49:15 raspberrypi sudo[986]: 2023/07/26 04:49:15 INF [RTSP] [session 69375137] created by 192.168.123.13:33898 Jul 26 04:49:15 raspberrypi sudo[986]: 2023/07/26 04:49:15 INF [RTSP] [session 69375137] is publishing to path 'stream1', with UDP, 1 lines 1-20/20 (END)

And this is what it looks like when i refresh the page: Screenshot from 2023-07-26 15-51-17

aler9 commented 8 months ago

I'm still not able to replicate the issue and no one else reported it, although it should manifest when performing a very common task. From the logs it appears that you're using the arm 64 version and a Raspberry Pi, contrarily to what what is indicated in the issue template, so i've used this stack:

Firefox is able to connect without any problems:

Screenshot_20231019_110955

The two things that come to my mind are: