WebRTC Listener not working after reading before publishing

[Velt1]

Which version are you using?

v[0.23.6]

Which operating system are you using?

• [x] Linux amd64 standard
• [ ] Linux amd64 Docker
• [ ] Linux arm64 standard
• [ ] Linux arm64 Docker
• [ ] Linux arm7 standard
• [ ] Linux arm7 Docker
• [ ] Linux arm6 standard
• [ ] Linux arm6 Docker
• [ ] Windows amd64 standard
• [ ] Windows amd64 Docker (WSL backend)
• [ ] macOS amd64 standard
• [ ] macOS amd64 Docker
• [ ] Other (please describe)

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]

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

[vicmassy]

Same issue here

[aler9]

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]

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]

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]

This is what it looks like:

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:

[aler9]

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:

• Raspberry Pi 4 A

• Firefox

• FFmpeg with

  ffmpeg -re -f lavfi -i testsrc=size=1920x1080:rate=30 -pix_fmt yuv420p -c:v libx264 -g 600 -keyint_min 600 -preset ultrafast -b:v 600k -f rtsp rtsp://192.168.3.98:8554/stream
  

Firefox is able to connect without any problems:

The two things that come to my mind are:

• Raspberry Pis may have connectivity issues in case of insufficient power supply, these can be monitored by using dmesg

• If the Raspberry Pi doesn't have internet access, it is not able to access the STUN server (that by default is stun.l.google.com) and may get stuck during the WebRTC handshake. Disable the STUN server and force webrtcICEHostNAT1To1IPs and webrtcICEUDPMuxAddress as explained in the README:

  webrtcICEHostNAT1To1IPs: [if.of.your.raspberry]
  webrtcICEUDPMuxAddress: :8189