Note: Several Mistika applications have streaming capabilites. This document use Mistika VR on Windows for all the examples, but the rtsp streaming is pretty similar for Ultima & Boutique and also for other operating systems. 

MistikaVR support two different video streaming methods using different protocols for different purposes, it is important to understand the differences:

- RTSP Streaming & Remote Connection Manager:  It works as in the above picture, and the rtsp is the only video streaming method covered in this document.

- Headset preview: This is the old VR Headset preview icon typically used to preview stills. This method uses a different streaming method not covered in this document. 

These are the two VR tools covered by the diagnostics below:

RTSP Streaming:


Accesed via File->Options->Streaming, and also via the Remote Connection Manager below. 

It is based on a 3rd party (open source) rtsp server named rstp-simple-server  

Both the rstp-simple-server and the Mistika streaming configuration files are installed in this folder:

Mistika VR: SGO AppData/vr/config/streaming

Mistika Ultima & Boutique: SGO AppData/Mistika/config/streaming 

(If you have both Boutique and VR products installed then make sure to look in the right configuration folder for the product you are trying to diagnose or to change its settings) 

Mistika Remote Connection Manager:

Accesed via Tools->Remote Sessions menu. This is a Mistika optional component for remote control of certain parts of Mistika applications. It only needs a network port to work, which is also covered in some of the diagnostics below.

There are two common causes for Streaming failures, codec setttings and problems with network ports. Both cases are examined  in the diagnostic procedures below.

Diagnostic procedures

1 - Start with a fresh reboot and open Mistika VR. The rtsp server will not be launched yet. 

2 - To start diagnostics it is recommended to start with something basic:

- Open VR in low resolution (HD/2K, the resolution needs to be selected in the Mistika VR startup dialog "ProjectManager->Edit").

- Select the video codec that you are going to use (if not yet). In Mistika VR this is done in his menu:

 File->Options->Streaming->Video codecs 

To start with select the GenericH264 codec, as that should work no matter the hardware configuration.

If it works with those basic settings but not later with your desired settings, then check that you have selected a valid codec for the current resolution and GPU model. 

- H264 codecs are limited to 4K resolution. 

- Codecs with the NVIDIA label on them will only work on modern nvidia boards with nvenc capabilities and modern nvidia drivers installed

- AMD GPUs do not work with NVIDIA codecs, use the genericH264 codec. 

 If an invalid codec is selected for your current configuration, you will get an error in next step

3 - Now we will start testing interconnection between the necessary elements. We need to launch the rstp server. In Mistika VR it is launched when doing any of these actions:

- File->Options->Streaming->Start server (streaming only)

- Tools->Remote Connect->Quick session->Start session (streaming and remote control)

Click on one of those (first one is simpler). The rtsp server will open a new window "rtsp-simple-server.exe", which is very useful for diagnostics. 


At that point the Start button will change to Stop Server or Disconnect (you do not need to exit Mistika to test with different streaming settings). 

4 -  If the rtsp-simple-server window does not open (Mistika will probably show an error dialog) then it is probably a problem with the configuration settings. In that case:

4.1 - Check the codec settings, as previously explained. 

4.2 - Check the availability and permissions for network ports (Go to point 7) 

 5 - If it opens, it will show some output as follows (the example is for the default ports):

022/10/14 11:32:01 INF rtsp-simple-server v0.17.17

2022/10/14 11:32:01 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)

2022/10/14 11:32:01 INF [RTMP] listener opened on :1935

2022/10/14 11:32:01 INF [HLS] listener opened on :8888

In the second line we have two ports of interest for our diagnostics:

8001:  rtsp server port to which Mistika will connect to send the streaming to the rtsp server.

8554 : rtsp server port where media players and headset will normally connect to get the streaming 

(other ports are mentioned there, but are much less common for our purposes and will normally remain unused)

At this point the rtsp server is launched but Mistika has not connected to it yet. Mistika should connect to it after a couple of seconds, and when it does it will show additional lines:

2022/10/14 11:32:03 INF [RTSP] [conn] opened

2022/10/14 11:32:04 INF [RTSP] [session 371036475] opened by

2022/10/14 11:32:04 INF [RTSP] [session 371036475] is publishing to path 'vr', 1 track with UDP

If you do not see those lines, then you will need to check network port connections (Go to point 7)

The interesting bit here is the "is publishing to path 'vr'" message:  In this case "vr" is the name of the stream, and it will appear at the end of the url for the media player.  Now we should be able to connect to the stream, which we will do in next point:

Note: It has been reported in some early betas a failure to configure the stream name. If you see "publishing to path #PRODUCT#" then replace #PRODUCT# by vr in this configuration file:

SGO AppData/vr/config/streaming/rtsp-tcp.prl

The STREAMING_URL  line should be like:

STREAMING_URL rtsp://%s:%s/vr

6 - Test the stream url in a media player supporting rtsp protocol. A very common one is VLC (open source), which you can download from Once in VLC, use Media->OpenNetworkStream to open the url.  According to the previous steps you will need to put this url:   (valid for a local connection inside the Mistika VR computer)  (example url to connect from other computers in the local network, this example is supposing that the Mistika VR computer has the ip )

At which point these lines should appear in the rtsp server console:

2022/10/14 12:28:46 INF [RTSP] [conn] opened

2022/10/14 12:28:46 INF [RTSP] [session 432091326] opened by

2022/10/14 12:28:46 INF [RTSP] [session 432091326] is reading from path 'vr', 1 track with UDP

Note: In principle you can test it in the local computer and it may work, but for proper diagnostics it is recommended to watch the stream in a different computer or device. This is because having the 3 processes (Mistika VR, the stream server, and the media player) running in the same computer could overload it, in which case VLC will may show a black image all the time, or random interruptions and video glitches, or even timeouts trying to connect. So it could lead to a wrong diagnostic.

Depending on the output:

- If you don't see those lines, then go to point 7.

- If you see those lines then it means the connection from Mistika to the end player is working as expected. If your video stream is still not appearing in the player or if it has glitches then it probably means a problem in the player side, either because of hardware limitations, codec incompatibilities, or network issues. But the player side issues are out of scope of this document. In any case, in case of problems we recommend to go trough point 7 to confirm the ports are really working as expected.

Also please check that the url you are using in the client has exactly the correct syntax, like in the above example (it is case sensitive):


7 - Port diagnostics for the required ports:

These network ports are needed for the streaming to work. By default:

- 8001:  rtsp server port to which Mistika will connect, for sending the video stream to the rtsp server.

- 8554 : rtsp server port where media players and headset will connect to get the streaming 

26950: The (optional) Remote Connection Manager server is needed for additional data streams (remote control). This is unrelated with the video stream, but it will be necessary for optional plugins trying to control Mistika VR remotely.  

(Ignore any other port numbers, they are not relevant for these diagnostics)

A port may fail for multiple reasons (security reasons & paranoid firewalls, being blocked by other applications, etc).  We will go through the most probable causes:

First thing on Windows, when an application tries to use a port for the first time it will ask the user to approve the connection, but sometimes those dialogs appear hidden or minimized for unknown reasons. Check the taskbar for unseen notification dialogs about this, as they cannot hide from there. 

If it was not that, starting from a fresh reboot check if the ports are blocked by other applications. To see which ports are being used by which applications open a Power Shell as Administrator user and type:

netstat -abn

Now search the ports in that list. The command will throw a long list of ports, with the applications using them in the line below. To simplify your search, you may prefer to redirect the output to a text file: 

netstat -abn > PathToYourTextFile.txt

The rtsp streaming ports (8554, 8001) should not appear in that list until we launch our rtsp server, and neither the 26950 port until we launch a Remote Connection Manager.  If they appear before that then you have found the cause of the problem, write down the programs using them and either reconfigure those programs to use different ports or reconfigure the rtsp server and Mistika to use other ports.

Once Mistika launches the rtsp server you should see this output from the same command:

netstat -abn

 TCP               LISTENING


  UDP           *:*


And if you are using the Remote Connection Manager you will also get some items in this style, for port 26950:

 TCP              LISTENING


 TCP    [::]:26950             [::]:0                 LISTENING


  TCP    [::1]:26950            [::1]:59784            ESTABLISHED


If the expected ports do not appear, then it probably means that your security firewall is blocking the connection. Try again after deactivating the firewall temporally. Do not continue with next steps until you have it solved.

If the required ports appear in that list then we will use this other command in the Power Shell to test the server port for the streaming players, but this time run the Power Shell as your mistika user, not as Administrator:

Test-NetConnection -ComputerName localhost -Port 8554

Before opening Mistika VR and rtsp server (after a fresh reboot), those commands should return a failed connection error, this is good as it means the ports are not in use (as in the previous example).

WARNING: TCP connect to (::1 : 8554) failed                                                                             WARNING: TCP connect to ( : 8554) failed                                                                       

After opening Mistika VR and launching the server, the port 8554 should respond to that command, and you should get this result:

Test-NetConnection -ComputerName localhost -Port 8554

ComputerName     : localhost

RemoteAddress    : ::1

RemotePort       : 8554

InterfaceAlias   : Loopback Pseudo-Interface 1

SourceAddress    : ::1

TcpTestSucceeded : True

Without going into details, that means that the rtsp server is accepting the type of connection that we need for the media players. Then:

- If it still says connection "failed" then it probably means that your security firewall is blocking the connection. Try again after deactivating the firewall temporally. If it works in that way, then check your operating system documentation about how to open firewall ports, so that you can reactivate the firewall without blocking the applications.

- If the command works as said, but your player doesn't, then the problem is probably in your player application, not in the server

8 - Connection Manager session list:

This is useful when you have already started a session in the Connection Manager, and you are now starting a new client connection. When the connection is stablished, it must appear in the session list at the bottom of the Mistika application, as in this image:


It will indicate the name of the device and its ip address (just the local host in the above example). 

If it does not appear in the list then the connection has not been stablished, and we need to find at what side is it failing. We can test the server side fsimilar to what we did in point 7. Open a Power Shell (as your mistika user, not Administrator) and execute:

 Test-NetConnection -ComputerName localhost -Port 26950

You should get an output as follows:

ComputerName     : localhost

RemoteAddress    : ::1

RemotePort       : 26950

InterfaceAlias   : Loopback Pseudo-Interface 1

SourceAddress    : ::1

TcpTestSucceeded : True

- If it says connection "failed" then it means the Mistika server side is not working (check firewall issues as explained in point 7)

WARNING: TCP connect to (::1 : 26950) failed

WARNING: TCP connect to ( : 26950) failed

ComputerName           : localhost

RemoteAddress          : ::1

RemotePort             : 26950

InterfaceAlias         : Loopback Pseudo-Interface 1

SourceAddress          : ::1

PingSucceeded          : True

PingReplyDetails (RTT) : 0 ms

TcpTestSucceeded       : False

- If it works, then the problem is (most probably) in the client device or its connection. If using a Quest device check that it has  Internet connection (a local   network connection with the Mistika VR system is not enough, as those headsets  need to login before using the app).