Hosting and Networking Guide

Even without prior experience developing or deploying web services, you should be able to get the Pixel Streaming setup described in the Overview and Quickstart Guide pages to work within a simple local area network. However, if you try to deploy your service over more complex networks or over the open Internet, or if you want to redesign the user experience and connection flow, you might need to rethink your setup.

The signalling server, web server, and matchmaker server that accompany Pixel Streaming are a reference implementation only. We do not view them as being a complete solution for all cases, rather, we encourage you to modify them for your own purposes. To this end, we provide the signalling server and web server in the newly made Pixel Streaming Infrastructure (external website) so they can be freely distributed as per the Unreal Engine EULA (see Distribution and sublicensing of Examples).

For more information regarding the Pixel Streaming front end and web servers, please refer to the Pixel Streaming Infrastructure page.

STUN and TURN Servers

In order for the Signaling and Web Server to be able to negotiate a direct connection between the Unreal Engine application and the browser, each party needs to send the other its own IP address. The browser needs to be able to access the IP address sent by the UE5 application, and vice-versa.

Within a simple local area network, each endpoint can usually assume that the other party can access it using the private IP address known to its own network card. Over the open Internet, across subnets, or when network address translation (NAT) services intervene between the browser and the UE5 application, this is not usually the case. Instead, each party needs to find out its own publicly visible IP address by querying a server that implements the STUN (Session Traversal Utilities for NAT) protocol. After the STUN server tells each endpoint its publicly visible IP address, the Signaling and Web Server can continue brokering their direct connection.

Alternatively, you can use a TURN server to relay the media stream between the UE5 application and the browser. With the TURN protocol, the TURN server connects to both the UE5 application and to the browser. The UE5 application sends all of its streamed data to the TURN server, which forwards the data on to the browser. In this case, there is no direct connection between the UE5 application and the browser. If you need to support mobile devices over wireless carrier networks or clients on secured enterprise networks, you may have no choice but to use a TURN server. Mobile and enterprise networks often prevent clients from successfully connecting using the WebRTC protocol.

The STUN and TURN protocols together, along with the ability to fall back from one server to another, make up the ICE (Interactive Connectivity Establishment) framework.

You can find several open-source implementations of STUN and TURN servers on the Internet. There are even public STUN servers that you can use for free instead of hosting your own, although you should exercise caution when using a service that you are not hosting yourself. Because of the throughput and bandwidth involved in relaying media through the TURN protocol, public TURN services are rarely available for free.

To set up Pixel Streaming to use ICE connections, you need to set the host names of the STUN and TURN servers you want to use in the peerConnectionOptions configuration parameter for the Signaling and Web Server. For details on how to format this parameter, and how to supply it, see the Pixel Streaming Reference.

In addition, if you're hosting your own STUN or TURN server, you must make sure that the IP address and port you specify for it in the peerConnectionOptions parameter are visible on the open Internet.

Multiple Player Endpoints

You may want all users to be in the same Unreal Engine session, but not have exactly the same ability to control that session.

For example, you might want to create an experience like a presentation, where the presenter has full control over the Unreal Engine from their browser, but other users are only able to view the stream. Or, you may want to create customized sets of controls for different users, so that they can cooperate to control different aspects of the experience in real time.

For these kinds of scenarios, you can have one Unreal Engine instance running with one stack of web services, but create different player HTML pages on the Signaling and Web Server:

In this scenario, you could customize each different HTML player page and its JavaScript environment to expose only the controls you want. Then, each class of users would need to request a different URL from the Signaling and Web Server. For example, maybe the presenter loads http://yourhostname/presenter.html and other users load http://yourhostname/attendee.html.

For more details on how to customize the player page, see Customizing the Player Web Page.

Scaling on Demand

For a production Pixel Streaming deployment, we recommend a dynamic scaling solution. While running a fixed number of Unreal Engine applications may be viable for small-scale deployments, a more dynamic approach is necessary for larger or on-demand scaling. Without it, you risk either wasting resources on idle servers or forcing users to wait for a free connection. Ideally, your scaling solution should provision a new Unreal Engine instance instantly whenever a user connects.

In the past we provided a simple matchmaking server for use with the Pixel Streaming infrastructure that would match unused Unreal Engine instances with users wanting a Pixel Streaming experience. However, this matchmaking was not a dynamic scaling solution and was not a good foundation for building such a solution so we deprecated it in Unreal Engine 5.5. While a complete, ready-made scaling solution is outside the scope of what we provide, the Pixel Streaming repository contains all the essential components and libraries to build your own. We encourage you to extend these libraries with your own business logic to create a solution that is perfectly suited to your needs.

Alternatively, there are a number of cloud-based solutions and service providers who offer dynamic scaling solutions for Pixel Streaming. We recommend researching the market to find an option that aligns with the goals and business constraints of your project.

What is the SFU?

A Selective Forwarding Unit (SFU) is a server which intelligently routes media streams between participants. In Pixel Streaming the role of the SFU is to receive stream data from the Unreal Engine application and deliver it to the recipient's peers (typically connected web browsers), optionally subsetting the data to adapt to the prevailing network conditions of each recipient peer.

When using the SFU Pixel Streaming, it implements the simulcast strategy for adapting stream bandwidth. In the simulcast strategy, the Unreal Instance generates multiple streams at different resolutions. The SFU then selects which quality variant of the stream to transmit to the recipient based on the recipient's network conditions.

When to Use an SFU

An SFU enables a one-to-many stream where there can be more peers connected than would be typically available if all the peers were connected to the Pixel Streaming application in a peer-to-peer fashion. The use of an SFU is often appropriate when your Pixel Streaming application requires multiple connected recipients and those recipients are in varying network conditions that call for different quality stream quality levels (for example, lower bitrates, resolutions, or framerates).

SFU Configuration

Configuration of the SFU can be achieved by modifying the config.js file found in PixelStreamingInfrastructure/SFU/.

The SFU is configured by default to provide three quality levels: one full, one half, and one quarter resolution streams. This configuration can be changed using -PixelStreamingEncoderEnableSimulcast (See the Pixel Streaming reference for details).

Host Machine Hardware Capabilities

If you choose to use a service provider such as Amazon (AWS) or Microsoft Azure to host your Unreal Engine application and Pixel Streaming web services, you may have a choice between multiple different tiers of hosts with different hardware capabilities. Keep in mind that the capabilities of the host may affect the quality of the stream that you can offer.

For example, if you opt for hosts with less powerful GPUs or less memory, you may not be able to get the maximum video quality possible in your streams.