Setting Up Unreal Pixel Streaming

Install and Enable the Plugin

Open your project in Unreal Editor 5.x and go to Edit, then Plugins. Search for "Pixel Streaming" in the plugin browser. You will find two options in UE 5.4 and later:

Pixel Streaming (original): The established plugin that has been available since UE 4.27. It works reliably and has extensive community documentation and troubleshooting resources. Choose this if you need compatibility with older projects or if you find that community resources for the newer version are still sparse.

Pixel Streaming 2: The refactored version introduced in UE 5.4. It offers a more modular architecture, improved WebRTC internals, better signaling protocol, and a more extensible frontend library. New projects should use this version as it represents Epic's current development direction.

Enable your chosen plugin and restart the editor. After restart, verify the plugin is active by checking the Plugins window again, the plugin should show as enabled with a green checkmark.

If you are using the Pixel Streaming Infrastructure plugin (which provides the reference signaling server and frontend), enable it as well. This plugin is separate from the core Pixel Streaming plugin and provides the server-side components you need for deployment.

Configure Encoder and Stream Settings

Navigate to Project Settings and find the Pixel Streaming section. These settings control how your application encodes and streams video to connected browsers.

Resolution: Set the streaming resolution independently from the application's rendering resolution. For most use cases, 1920x1080 provides good quality on desktop browsers. If bandwidth conservation is a priority or your audience is primarily mobile, consider 1280x720. You can also enable adaptive resolution, which allows the system to dynamically reduce resolution under poor network conditions.

Frame Rate: The MaxFPS setting caps both the rendering and streaming frame rate. 60fps is standard for interactive applications. Setting 30fps halves bandwidth requirements and works well for slower-paced experiences like architectural walkthroughs or product configurators. Set MinFPS equal to MaxFPS if you want consistent frame timing rather than variable frame rate.

Bitrate: The encoder bitrate range determines the quality-to-bandwidth tradeoff. Set the minimum to approximately 5 Mbps and the maximum to 15-20 Mbps for 1080p content. The encoder uses variable bitrate within this range, allocating more bits to complex frames (detailed scenes, fast motion) and fewer to simple ones (static views, minimal movement).

Codec: H.264 (AVC) has universal browser support and should be the default choice. H.265 (HEVC) provides approximately 30-40% better compression efficiency but has limited browser support through WebRTC, primarily working in Safari and some Chromium builds with hardware decode support. Use H.264 unless your audience is limited to browsers where you have confirmed H.265 WebRTC support.

Keyframe Interval: The interval between full keyframes (I-frames) affects both stream quality and recovery from packet loss. A shorter interval (every 1-2 seconds) means faster recovery when frames are lost but uses more bandwidth. A longer interval (every 3-5 seconds) is more bandwidth efficient but takes longer to recover from stream disruptions.

Set Up Network and Firewall Rules

Pixel streaming requires several ports to be open on your server. The exact ports depend on your configuration, but the defaults are:

Port 80 (HTTP): The signaling server serves the web frontend on this port. In production, this is typically replaced by port 443 (HTTPS) with TLS termination at a reverse proxy.

Port 8888 (WebSocket): The signaling server listens for WebSocket connections on this port. The browser's frontend JavaScript connects here to negotiate the WebRTC session. In production with a reverse proxy, this traffic is usually routed through port 443 as well.

UDP Ports 49152-65535: WebRTC media transport uses UDP for video and audio. The specific ports are negotiated during the ICE process, but they fall within this range by default. You can narrow this range in the plugin settings if your firewall requires it, though narrowing it too much may limit the number of concurrent connections.

On AWS, configure your security group to allow inbound TCP on port 443 (or 80 and 8888 for testing), and inbound UDP on your configured port range. If you use a separate TURN server, it also needs its own port configuration (typically TCP/UDP 3478 for TURN and 49152-65535 for TURN relay).

Configure STUN and TURN Servers

WebRTC uses ICE (Interactive Connectivity Establishment) to find a network path between the browser and the server. STUN and TURN servers facilitate this process.

STUN servers help clients discover their public IP address and port mapping when behind a NAT. Google operates free public STUN servers (stun:stun.l.google.com:19302) that work for most deployments. STUN handles the majority of connection scenarios where both parties can communicate directly once they know each other's public addresses.

TURN servers act as relays for the small percentage of users (typically 10-15%) whose network configuration prevents direct connections. Corporate firewalls, symmetric NATs, and some mobile carrier configurations require TURN relay. Without a TURN server, these users simply cannot connect.

For production deployments, run your own TURN server using open-source software like coturn. Deploy it in the same region as your GPU servers to minimize relay latency. Configure the TURN server credentials in the Pixel Streaming plugin settings so the signaling server can provide them to connecting clients during ICE negotiation.

TURN relay traffic is bandwidth-intensive (it relays the full video stream through the server), so factor this into your infrastructure costs. A single coturn instance can handle many relay connections, but the bandwidth cost can be significant at scale.

Package and Deploy the Application

Package your project through the editor using File, then Package Project, then your target platform. For cloud deployment, Linux is the standard choice. Windows packaging works for development servers and local testing.

Transfer the packaged build to your server. The package includes the game executable, all content, and the engine runtime. Typical package sizes range from 1GB to 10GB depending on content volume.

Launch the application with command-line parameters that configure pixel streaming behavior. Essential parameters include:

-AudioMixer to enable audio capture for streaming, -RenderOffScreen to run without a visible window on headless servers, -PixelStreamingURL to specify the signaling server WebSocket endpoint the application should connect to, and -Res to set the rendering resolution if different from the default.

Deploy the signaling server by installing Node.js, navigating to the signaling server directory, running npm install, and starting it with node cirrus.js (or the equivalent entry point for Pixel Streaming 2). Verify that it binds to the configured ports and logs that it is waiting for connections.

Set Up TLS and Domain Configuration

Production WebRTC requires HTTPS. Browsers will not allow WebRTC connections from pages served over plain HTTP (with the exception of localhost for development). You need a valid TLS certificate for your domain.

The most common approach is to use Nginx as a reverse proxy in front of the signaling server. Nginx handles TLS termination using a certificate from Let's Encrypt or your certificate provider, and forwards decrypted HTTP and WebSocket traffic to the signaling server running behind it.

Configure Nginx to proxy both regular HTTP requests (for the frontend page) and WebSocket upgrade requests (for the signaling channel) to the signaling server. The WebSocket proxy configuration requires specific Nginx directives (proxy_set_header Upgrade, proxy_set_header Connection "upgrade") to handle the protocol upgrade correctly.

Point your domain's DNS to the server's public IP address, wait for DNS propagation, and verify that the frontend loads over HTTPS. Test the WebRTC connection to confirm that the TLS configuration does not interfere with the streaming pipeline.

Test and Validate the Setup

Thorough testing across browsers, devices, and network conditions prevents surprises in production. Test systematically:

Browser compatibility: Verify in Chrome, Firefox, Safari, and Edge. Each browser has slightly different WebRTC implementations, and subtle differences in codec negotiation or ICE handling can cause issues in specific browsers.

Mobile testing: Test on both iOS Safari and Android Chrome. Verify that touch input is captured correctly, that the video stream adapts to the mobile screen resolution, and that the experience remains usable on cellular connections.

Latency measurement: Use chrome://webrtc-internals to measure round-trip time, frame rate, bitrate, and packet loss. Total round-trip latency should be under 100ms on a local network and under 150ms over the internet for an acceptable experience.

Load testing: Connect multiple simultaneous users to verify that the server handles concurrent sessions without degradation. Monitor GPU utilization, CPU usage, memory consumption, and network throughput during load testing.

Recovery testing: Deliberately disconnect and reconnect to verify that the frontend handles session interruption gracefully. Test what happens when the Unreal application crashes or the signaling server restarts.