Ultrawide gameplay in a standard horizontal video: layouts that keep the HUD and the action.

The short answer

A wide recording has three honest futures inside a 16:9 video. Keep its own shape and let the player draw the bars: nothing lost, nothing to do. Scale it to the width inside a 16:9 file, with bars of your own above and below: nothing lost, picture smaller. Scale it to the height and cut the sides: the biggest picture, with a slice gone from each edge, about a quarter of the width for the common ultrawide shapes. The developer’s own recordings are 1920 × 804, a 2.39:1 frame, and the channel publishes them at that shape; the bars you see around them on the session pages are the player’s. Below: the three layouts drawn, the numbers for 2560 × 1080, 3440 × 1440 and 1920 × 804 sources into 1920 × 1080, what each loses, where the Broker ends up, and the OBS settings that decide it before you press record. A vertical clip is a different problem with its own page: the vertical clip planner.

Three ways a wide frame becomes 16:9

The same 2.39:1 recording, three times. Each drawing is a layout example, not a still; its proportions are exact for a 1920 × 804 source, which is what the developer’s recordings are.

1. Keep the shape: the player draws the bars

The file stays 21:9 or 2.39:1, and whoever plays it fits it into their frame. Most players, YouTube’s included, keep a 16:9 frame and draw a bar above and below a wider video; on a phone held upright everything gets bars anyway. Every pixel of the recording survives, there is nothing to set, and the bars cost you nothing because they are not in your file. What you give up is control of the frame: thumbnails and embeds show the bars, and the picture is as small on a viewer’s screen as it would be with bars of your own.

2. Scale to the width: bars in the file

A 16:9 file, with the whole picture scaled to its width and centred, and bars of your own above and below. Nothing is lost, the picture is smaller, and everything in it shrinks by the same factor, the Broker’s captions included. The bars are yours: black by default, or room for something else.

3. Crop the sides: scale to the height

The picture is scaled until it is 1080 tall and the file keeps the middle 1920 pixels. The picture is as big as it can be, and the outer eighth of each side is gone: corner HUD elements first, then anything else that lives at the edges. A source shorter than 1080 is scaled up on the way (× 1.34 for 1920 × 804), which softens it.

Worked numbers: three sources into 1920 × 1080

Four rules produce every number: scaling to the width multiplies by 1920 ÷ source width; scaling to the height multiplies by 1080 ÷ source height; a bar is (1080 − scaled height) ÷ 2; the kept slice of a crop is source height × 16 ÷ 9 wide, in source pixels. Heights are rounded to even pixels, as encoders want them.

Scale to the width, bars in the file. The first layout (keep the shape) has the same proportions: the player’s bars take 25.0% or 25.6% of its frame, and the file loses nothing. A 3440 × 1440 frame scaled to 1920 wide is 1920 × 804 to the pixel, the size of the developer’s recordings, so every 1920 × 804 figure on this page is also the figure for a 3440 × 1440 source that has been scaled to width first.

Crop the sides, scale to the height. The width lost and the area lost are the same percentage because the full height is kept.

What the crop takes: the outer eighth

A crop removes a vertical strip from each edge, top to bottom, 12.5% of the width for 2560 × 1080 and 12.8% for the 2.39:1 shapes. Which HUD elements that takes depends on the game; the placement guide sorts HUDs into three families, and the strip treats each differently. The bars layouts keep every one of them, smaller.

The positions named are read from frames of the developer’s recordings and are approximate. Before you crop anything, take one screenshot of your game, mark every element a viewer must be able to read, and check that none of them sits in the outer eighth; the arithmetic above is exact, what it cuts in your game is not.

Where the Broker survives

In the developer’s recordings the Broker stands at the bottom, left of centre, with his bubble opening to the right above him. The rectangle the site’s clip renderer draws around the bubble is x 380 to 1080 of a 1920-wide frame, 20% to 56% of the width, in the bottom 42% of the height. The crop keeps 12.8% to 87.2%, so the bubble and the avatar survive it with room to spare. That is placement, not a property of the overlay: the Bottom left preset puts him in the bottom-left corner of the Browser source, and where the source sits on the canvas is yours to set in OBS.

Put the source where the source-size article puts it for a 2560 × 1080 canvas, Bottom left at X 51, and the source spans x 51 to 851. A crop that removes everything left of x 320 takes the first 269 px of the 800-px source, a third of it, which is where the preset puts him; the bubble, opening toward the middle, loses its left end. On a 3440 × 1440 canvas with the same 2% margin (X 69) and a cut at 440, the crop takes 371 px of the source, nearly half. The whole figure goes, the end of the caption stays.

Three ways out, in order of preference:

1. Crop in OBS, not afterwards. With a 1920 × 1080 canvas, the Browser source sits on the final frame and the crop only ever touches the game source (next section). Nothing placed on the canvas can be cropped away by it.
2. If the crop happens later, in an editor, keep the source inside the slice that will survive: on a 2560 canvas X at least 320 plus your margin (X 371 keeps the 2% margin from the future edge), on a 3440 canvas X at least 440 plus margin (X 509). The overlay layout preview lets you drag the source there and copy the numbers.
3. With bars, nothing to fix, only something to check: everything shrinks by the scale factor, so captions laid out for an 800-pixel-wide page come out at 0.56 of that size for a 3440 × 1440 source. Raise Dialogue size in the app before enlarging the source in OBS; a scaled-up source only enlarges pixels that were never there.

Bars I can live with. A crop, I want to see first.

The OBS settings involved: canvas, source transform, output

In OBS, Settings → Video has the two numbers that decide the layout before anything is recorded. The Base (Canvas) Resolution is the frame you compose; every source is positioned and scaled inside it, and anything outside it is not encoded. The Output (Scaled) Resolution is what the file or stream is encoded at; keep it the canvas’s shape, and a downscale multiplies every number below by the same factor and changes nothing else. The source-size article has the full relationship between canvas, output and the Browser source’s own 800 × 600 viewport, which none of the following changes.

The Crop values are in source pixels, which is why they differ from the file-pixel figures in the second table. A 2560 × 1080 source at Position −320, 0 on a 1920 × 1080 canvas is the same crop without the Crop fields, because OBS encodes only what is inside the canvas. Whichever you use, the Browser source is placed on the 1920 × 1080 canvas and keeps its viewport; the voice is unaffected by any of it, because the overlay has no sound of its own and the voice reaches OBS through Desktop Audio.

Limits, and the next step

Everything above is arithmetic on frame sizes, not a measurement of the real overlay: the Broker’s size inside the Browser source and the caption wrapping are the app’s, how the overlay page lays him out in a viewport other than 800 × 600 is not documented by the app, and the HUD positions come from three games and will differ in yours. Nothing here changes the sound: his voice is in Desktop Audio together with the game, with no separate track yet. For the vertical case, the inset-plus-full-frame layout, the centre crop and the letterbox are computed, drawn and exported by the vertical clip planner; this page does not repeat them.

Next: decide the layout, then place the source for it in the overlay layout preview, start a session, record thirty seconds and watch the file with the HUD in mind. If a corner element is missing, the crop took it; if the captions are small, the scale did.

Limits

• Arithmetic on frame sizes, not a measurement of the real overlay: the Broker’s size inside the Browser source and the caption wrapping are the app’s, and how the overlay page lays him out in a viewport other than 800 × 600 is not documented by the app.
• HUD positions are read from frames of three games and differ in yours; the crop percentages are exact, what they cut is not.
• The overlay has no sound of its own; the voice reaches OBS through Desktop Audio, and no layout here changes that. Vertical clips are the planner’s job, not this page’s.
• Founder Alpha is early-access software; the commentary can be wrong, repeated or badly timed, and it is sold to customers in the United States only.