Resolution

In the Control Panel the setting is Browser Resolution, on the Common tab of the app configuration. It offers two things: Dynamic and Custom.

Dynamic (match the viewer's window) is the default, and is what a configuration saved before this setting existed does too.

While a viewer is watching, the Eagle 3D Streaming page measures the area the video occupies and asks the Unreal application to render at that size. It does this again every time the area changes — a resized window, a rotated phone, a sidebar opening on the host page — at most about three times a second, so a slow drag of a window corner does not turn into hundreds of resolution changes.

The result is a picture that is never scaled and never soft from being stretched. On a large monitor it is large. On a phone it is small, which is why the same application looks softer on a phone than on a desktop: the frame really is smaller, and correctly so.

Two details worth knowing

Screen scaling counts, so a 4K laptop is usually fine. The size asked for is measured in the browser's own pixels, not the screen's. A 4K laptop running Windows at 200 % scaling reports a 1920-wide window and streams at 1920 wide. The large sizes come from large desktop monitors running at 100 % scaling, where the window really is 2560 or 3840 pixels across.

Some applications crop on a phone held upright. In a tall, narrow window a few applications lose the right-hand side of the scene, with no black bars to show that anything is missing. That is a camera setting inside the Unreal project, not a fault in the stream: the camera's Aspect Ratio Axis Constraint is set to Maintain Y FOV, which holds the vertical field of view fixed and narrows the horizontal one as the window narrows. Setting it to Maintain X FOV in the project fixes it. Most applications are unaffected.

Choosing Custom shows two boxes, width and height. These are the four standard sizes to type into them, with the connection speed a viewer needs for each:

Any other width and height works too. Use one when the application has to render one exact size — a kiosk screen, a video wall, an ultrawide monitor, a portrait display.

What a good fixed size looks like

• Even numbers. Video encoders work in blocks, and an odd width or height can produce a thin band of mush along one edge.
• Not larger than the screens it will be watched on. Pixels a viewer's monitor cannot show still cost the viewer bandwidth and cost the streaming machine work.
• 1920 × 1080 unless there is a reason. It is what most streams run at and what most screens are.

These are the speeds a viewer's connection needs. A stream that is mostly still — a paused scene, a menu — uses far less than one where the camera is moving, and the figures below are for the moving case, because that is the moment a connection that is only just fast enough starts to struggle.

The recommended figures are deliberately higher than the busiest measured ones. A connection that only just meets the average stutters the moment the picture starts moving, which is exactly when somebody is looking at it.

There is a ceiling. A single stream is capped at 20 Mbps however fast the viewer's connection is. At 1280 × 720 and 1920 × 1080 that cap is never reached. At 3840 × 2160 it is the limit on how good the picture can get, which is part of why 4K is rarely worth its cost for a remote viewer.

These two are easy to confuse, and knowing the difference explains most of what a stream does on a slow connection.

So the common assumption — it adapts, so a slow connection will be fine — is half true. What adapts is the quality. The size stays exactly where it was set. Asking for a big picture on a slow connection does not produce a smaller picture; it produces a big blurry one.

If the audience is unknown — a link on a public website, a QR code at an event — 1280 × 720 fixed is the setting that disappoints nobody. It looks slightly softer on a large monitor and it works on a phone on mobile data, which is the trade most audiences want made for them.

Configurations saved before this setting existed follow each viewer's window, which is the default. Nothing needs changing unless a fixed size is wanted.

Older configurations set to 720p, 1080p or Max are treated as a fixed size: the player follows the window only when the setting is exactly Dynamic. If an older configuration is meant to follow the window, open it and choose Dynamic.

Guests invited into a session watch at a fixed size and cannot change it. Only the person who started the session drives the resolution, so one viewer resizing a window never resizes the picture for everybody else.

When the stream is embedded in your own website, the resolution can be changed at runtime instead of being fixed in the configuration — pinned to a size, or released to follow the window again. Both calls are on Controlling the stream, along with the reason a raw resolution command does not work.