I have MediaMTX server running in “Computer 1” (Windows 10), this computer is the one where I also have OBS making sending the streaming itself to MediaMTX.
OBS → MediaMTX
(Sends using the RTMP protocol rtmp://localhost:1935 key: myStream)
Ok, MediaMTX receives it without problems;
INF [RTMP] [conn [::1]:62013] opened
INF [RTMP] [conn [::1]:62013] is publishing to path 'myStream', 2 tracks (H264, MPEG-4 Audio)
I have tested reading the stream using VLC and it works.
I have forwarded the port 8554 on my router to “Computer 1”. I use the following address to read on VLC.
rtsp://MY-PUBLIC-IP:8554/myStream
The problem comes when I go into VRChat media player, Popcorn palace or whatever and try to use the same address to read from the server. The MediaMTX server receives the VRChat connection but destroys it for some reason.
INF [RTSP] [session b531b833] created by VR-CHAT-IP:62383
INF [RTSP] [session b531b833] is reading from path 'myStream', with UDP, 2 tracks (H264, MPEG-4 Audio)
INF [RTSP] [session b531b833] destroyed: torn down by VR-CHAT-IP:62383
INF [RTSP] [conn 190.48.211.52:62383] closed: EOF
This keeps going over and over, what is happening exactly?
Is it something related to the way OBS streams? The encoding? What?
If I’m not wrong I believe this happens due to VRChat trying to receive content over UDP.
Try using rtspt:// instead of rtsp://
This should hopefully establish a connection using TCP.
Additionally I believe you can also change MediaMTX config in a way so that it only accepts TCP connections, but it’s still preferred to use rtspt:// for a URL either way.
Another thing worth nothing is that quest users will need to somehow be served a separate MPEG-TS/HLS URL in VRChat as apparently they don’t seem to support RTSP.
Two separate things to note, I believe @Uvita666 is running into the first.
Not all routers support “U-turn Routing”
So you need some way to give VRChat a URL that will resolve to PUBLICIP for other people, and LOCALIP for you. Personally I use a dynamic DNS, and in my Windows PC hosts file I have an entry for that host that points the hostname to the computers LAN ip. But maybe 127.0.0.1 would work. (Crossed out as I think you’re using a different PC to stream than play VRC) Make sure you’re pointing at the correct PC C:\Windows\System32\drivers\etc\hosts is the file, personally I open up notepad as administrator, and then edit the hosts file. I actually close all notepad windows before doing that, just so I make sure I don’t leave any notepads running as admin.
Some routers also support custom DNS, but that gets complicated, as you have to be sure that your PC actually talks to the router for DNS, and set it up there. But that would be useful if you’re using Quest Standalone
Protocol conflict between Windows and Android with RTSP
Summary: RTSP works so weird I’d say it almost works on Quest
UDP RTSP doesn’t work through most NAT firewalls
ExoPlayer (Quest/Android) doesn’t support rtspt:// protocol, and with rtsp:// protocol it requires to be offered UDP, when told an invalid transport, that counts as an error in the version that VRChat/AVPro is running
ExoPlayer will try and play a UDP stream for about 8 seconds, and then try TCP
rtspt:// protocol is used for PC clients to have the media engine require a TCP connection
But then i ran into another problem: Most video players have a timeout of 10 seconds. Getting a Quest 2 user to connect to RTSP takes almost 10 seconds, so with someone fairly close to me, the connection takes a few tries to get going.
So after you raise the general timeout from 10 seconds to 15 seconds for your world, things work. But if a Quest user needs to resync the video, they need to be told to give it 10 seconds
Here is a link to a Canny where someone is asking for RTSP to just be forced to use TCP
Please give it an upvote.
In the mean time you could try a world called Black Gold, it has a video player where you can give Quest users a separate link from the PC users. Other worlds have features like that, but I know that black gold works.
I finally “fixed” this by moving MediaMTX from my Windows 10 computer to a second computer running Linux - Ubuntu (aka a home-server)
In Ubuntu, I installed MediaMTX through docker by using Docker Compose (if you’re going to do it, do it this way) with the following configuration in the “compose.yaml”
For this, in my router I had to forward the ports 1935, 8854, 8888 so they would point to my Ubuntu machine (set them to forward both TCP/UDP).
So anyway, now it runs perfectly, HLS protocol having a 7s delay in all worlds & RTSP protocol having 4s delay. I’ve tested and RTSP protocol can run in VRChat with PC-VR, but I haven’t tested with stand-alone Quest.
