Dual-Format Twitch Streams: Paid Alerts, TTS, and Overlays for the Vertical Canvas

Two outputs, one paid-moment queue

Twitch dual format lets one OBS send a standard horizontal stream and a vertical one at the same time. Twitch's rollout put it in front of every streamer, and the setup guides agree on the broad shape: a recent OBS Studio, Enhanced Broadcasting turned on, and a second canvas at 1080 by 1920 that you build alongside the main one. Phone viewers in portrait get the vertical version, and rotating the phone gives them the horizontal one.

That is great for reach and awkward for paid overlays, because your alerts were designed for a 16:9 frame. Your TTS alert, your viewer image corner, and your tip goal all assume a wide canvas. A queue that behaves perfectly on the horizontal output can look cramped, double-play audio, or show a viewer's image cropped to nonsense on the vertical one. This post is about those three problems.

What the setup guides say

StreamElements' SE.Live guide says dual format needs OBS Studio 32.0.0 or newer, the vertical canvas selected under Additional Canvas in OBS's stream settings with Enhanced Broadcasting enabled, and a canvas of 1080 by 1920. It also says to uninstall Aitum Vertical before using SE.Live's dual format, because running both plugins can crash OBS. Twitch's help article is the reference for hardware and upload requirements, and one third-party guide summarizes them as about 12.5 Mbps upload for 1080p dual format when Twitch transcodes server-side and more when it does not. Treat that as a pointer and confirm the current numbers with Twitch.

The same third-party guide notes that Twitch draws its own chat over the vertical view, so a custom chat box overlay is not needed, and it suggests rebuilding HUD elements as separate cropped sources with larger text for phones. It also reports that vertical VODs expire sooner than horizontal ones. Verify retention in Twitch's help center before telling viewers what to expect.

None of those guides are about paid alerts specifically. The rest of this post applies their facts to a paid queue.

Do not run the same alert page twice

This is the mistake that costs the most. A paid-alert overlay is a web page loaded in a browser source. If you add a brand-new browser source with that URL to the vertical scene while the horizontal scene already has one, OBS now has two separate page instances. Depending on how your queue hands out items, you can get two playbacks of the same TTS message, two copies of an image, or items split between the instances so each one plays half of the queue.

OBS lets you add an existing source to more than one scene, which keeps it as a single source rather than creating a second one. Use that for anything that produces audio or consumes the queue. Then check how the source appears in both canvases, because sharing a source also shares its size and crop unless you handle placement in the scene.

Whatever your setup, the test is the same. Trigger one paid TTS message and listen to the public vertical stream and the public horizontal stream. The message should play exactly once on each, in the same order, with no echo.

Separate the sound from the picture

A clean way to avoid doubles is to separate the audio-bearing instance from the visual ones. One instance of the paid overlay lives in a scene that carries the audio and may be hidden or minimal visually. Visual-only alert cards, which have no sound and no queue authority, are what you rebuild separately for the vertical canvas.

Whether that is possible depends on your overlay. If the overlay page does audio and visuals together, you will have to keep a single instance and design the placement to work on both canvases. If it supports a visual-only mode or lets you configure the layout per scene, use that. Check the actual options in your dashboard rather than assuming they exist.

• One instance per overlay URL that plays sound or takes items from the queue.
• Visual-only cards can be duplicated per canvas if they never act on the queue.
• After any plugin or scene change, repeat the one-message listen test.

Rebuild the layout for portrait, not shrink it

A 1080 by 1920 canvas is shown on a phone that is roughly six inches tall. Text that looks fine on a widescreen monitor becomes unreadable when it is scaled down to a narrow portrait strip. Plan alert cards that use most of the width, with big names, short message text, and fewer elements.

Twitch adds chat to the vertical view automatically, according to the setup guide above, so keep important alert elements out of the lower area where chat sits. The exact position is Twitch's design and can change. Open your stream on a phone in portrait and look at where chat and controls appear before you pick a position.

Do not copy the horizontal layout and scale it down. Make an alert that works at the narrow width, with a clear name line, a short message area, and a short duration. A good starting point, which you should tune on a real phone, is a name line that stays readable when you hold the phone at arm's length.

Viewer uploads need a crop you can approve

Viewer-submitted images are a special problem because their shape is unpredictable. A landscape screenshot fits the horizontal canvas well and gets cut to a thin strip in a portrait frame. A vertical phone photo does the opposite. When a moderator approves an image after seeing it in a wide preview, the vertical output may show something different.

Make the vertical crop part of the approval step. The moderator should see how the image will look in both frames, or at least in the one that is more likely to cause trouble. If your preview only shows one, say so in the moderator notes and decide which output is the reference.

Cropping can hide or reveal text near the edges, such as a username, a message, or a private detail on a screen. A reviewer who only saw the wide version may miss something that the vertical version shows, or the reverse. Treat both crops as part of the same decision.

Scenes, not just overlays

The setup guides describe building vertical scenes and linking them to horizontal ones, so switching scenes on the main canvas activates the matching one on the vertical canvas. Your paid moments live inside those scenes. A full-screen takeover, a sponsor segment, a Just Chatting layout, and a BRB scene each need a portrait counterpart, and each needs a decision about where alerts sit.

Keep the set small. Two or three vertical scenes cover most shows, and the more scenes you add, the more chances there are to forget an alert placement. Name the scenes so a moderator can tell which pair is live, and list the pairs on the moderator sheet.

Performance and crash recovery

Two canvases mean more rendering work, and a heavy animated alert on both can add up. The third-party guide warns about GPU headroom and dropped frames. Test with real alert traffic, not just an empty scene, because a burst of paid items is the moment the stream is most loaded.

If OBS crashes or you have to restart it, browser sources reload and the queue may need to recover. Decide beforehand how the queue handles items that were playing when the stream dropped, and rehearse it once. The plugin conflict mentioned earlier is a known crash risk, so avoid installing a second vertical plugin an hour before a stream.

A pre-stream check on a real phone

Go live to a private test if you can, or use a short unannounced test stream. Open the stream on a phone, first in portrait and then rotated. Trigger one of each paid item and watch where it lands.

• TTS plays once on each output, with no echo.
• Alert text is readable at arm's length in portrait.
• Nothing sits under Twitch's chat or controls in the vertical view.
• A tall image and a wide image both look acceptable in the vertical crop.
• Scene switches carry the right alert placement to the vertical canvas.