WebRTC Playback in MistServer

What is WebRTC

WebRTC stands for Web Real-Time Communications, and it is one of the more modern low-latency capable protocols available right now. It is supported by all modern browsers and platforms; however, it requires a little bit of setup. If you'd like to know more, we recommend reading the WebRTC protocol information page.

WHIP, WHEP, and Others

You have most likely used WebRTC before without knowing it. Almost all conference applications are built with it. However, a big problem was that WebRTC didn't have true standardization, meaning everyone would build their own flavor that was incompatible with others. The WHIP/WHEP specification has been successful in becoming that standard, and support for it has been growing. One thing to remember about WebRTC is that even if you're only playing it, there's always some communication both ways. This helps keep the stream as close to live as possible.

MistServer supports WHIP/WHEP and also our own flavor of WebRTC because, of course, we had finished our own before the specification came out. No sense in removing it.

Setting Up MistServer for WebRTC Playback

The bare minimum for WebRTC isn't that hard—it only requires two things:

• UDP ports need to be open.
• The "correct" interface needs to be selected.

There are optional settings you can configure, like STUN/TURN servers, but they shouldn't be needed if your server is openly available. Even an SSL certificate for HTTPS isn't needed for playback. WebRTC over the browser does require a proper SSL certificate to push camera/microphone streams over WebRTC, however.

For this guide, we'll focus purely on getting playback on a normal open server. If you're working in specific network/routing conditions, feel free to contact us for help!

warning

• HTTP and HTTPS do not mix, please make sure to match them properly
• Keep in mind that WebRTC requires HTTPS for camera usage

MistServer Settings

Before we start, HTTP and/or HTTPS is a requirement for WebRTC. You will need to have one or both set up to use it. If you're using the default MistServer options, then you'll have HTTP on port 8080.

The most important settings within MistServer are the bindings for the UDP bind address (internal) and UDP bind address (public). These determine where MistServer can listen for WebRTC data and how it should answer.

• UDP bind address (internal): This is the interface MistServer will expect the WebRTC data on. It defaults to whatever interface received the WebRTC request, which is fine 99% of the time. To ensure it works properly, we recommend setting it to 0.0.0.0 to bind all possible interfaces.
• UDP bind address (public): This is the interface MistServer will attempt to send WebRTC data from. By default, it uses whatever your system has as an internal address, which is essentially a coin toss on whether it is correct. We recommend setting this to your publicly available interface (your network address with an internet connection). For example, one of our test servers at 141.105.120.235 has the following setup:

Server/Routing Settings

WebRTC connections go over UDP and will use your ephemeral range. For Linux, that is typically between 32768 and 60999. There are differences between OS and platforms, but generally, you should expect WebRTC connections to travel over these ports. WebRTC will always work if one of the sides is open. Should both sides be more restrictive, you will require a TURN setup. At that point, it’s best to contact us for tips.

To ensure WebRTC always works, it’s easiest to open up the UDP range for the server your viewers connect to.

Stream Encoding

Your encoding settings are important as well. WebRTC does not work with every codec and even needs specific options for codecs it does support.

Video

WebRTC supports H264, H265 (HEVC), VP9, and AV1. Some browsers prefer one codec over another, but generally, H264 works well.

One thing to keep in mind: B-frames should not be present in your stream.
Most browsers have a WebRTC implementation incompatible with B-frames, causing the stream to look jittery or feel like the video isn’t playing in the right order. B-frames are often the cause, and MistServer specifically disables WebRTC playback if B-frames are present.

Most encoders allow you to disable B-frames by setting them to 0 or turning them off.

Audio

WebRTC only supports OPUS audio. If your stream uses AAC audio, you will need to add an encoder for your live streams or choose a different ingest protocol that can handle OPUS, such as SRT, RIST, or even WebRTC itself.

For VoD, your best option is to re-encode the file.

Playback

The WebRTC playback URLs for MistServer are:
https://address:http(s)port/webrtc/streamname

You can try out the WHIP/WHEP test page to see for yourself.

Grab the WebRTC (WHEP) URL from the embed page in your Streams panel. Note that if your stream is set to receive pushes, you could also send in WHIP using this same stream URL.

We have not yet included a default WHEP player in our meta-player. However, our flavor of WebRTC is immediately available from a stream’s HTML page by adding the following parameter to a stream’s .html address:
?forcetype=webrtc

This forces the player to load the WebRTC player and attempt playback over WebRTC. From the interface, you can also directly select WebRTC (WS) from the preview page for the same output. The player will even tell you if you're playing WebRTC(WS)

Troubleshooting

WebRTC Just Shows a Black Screen

Open the browser developer console, reload the page, and try to play again. You should see errors in the console tab and actual addresses in the network tab. Chances are one of them is incorrect—such as attempting HTTP on an HTTPS page or vice versa.

You can also set the WebRTC output to debug level 4. This will print the UDP ports used when a WebRTC request comes in, which you can compare to what the browser is attempting.

WebRTC Is Video/Audio Only

This means the track not working is most likely in a format incompatible with WebRTC. Check the metadata available on the stream preview page for more information. For video, it’s almost always B-frames. For audio, it’s most likely AAC audio or OPUS in an unknown format.