YouTube Vertical and Horizontal RTMPS Streams: Cloud OBS Routing Checklist

The important routing rule

YouTube's current creator guidance says a third-party encoder can send separate horizontal and vertical streams using RTMP(S), with a second stream key for the vertical stream. The practical rule is simple: these are two program outputs with matching content, not one widescreen feed casually squeezed into a phone frame.

Plan the layouts before you create destinations. A horizontal show can support graphics, lower thirds, guest grids, and wide action. A vertical version needs its own safe areas, readable text, and camera framing. If the message is the same but the composition is not intentional, viewers get a cropped program that looks like a technical mistake.

Use StreamableRun and Cloud Hosted OBS to keep the contribution and program decisions apart. Bring the reliable field source into a named ingest, build two clearly named program scenes or scene collections, and send each finished format to its corresponding YouTube key.

Decide whether the event deserves two real layouts

Two outputs are worth the work when viewers will meaningfully use both orientations and the producer can maintain them. A street stream with a host, signs, chat prompts, and close action may need different camera crops and text placement. A static panel may only need one strong horizontal presentation. Do not create a second route merely because a setting exists.

Write the vertical audience goal in one sentence. It might be quick discovery, a phone-first companion stream, or a visual version of the same live event. Then specify what changes: camera crop, graphic safe area, captions, chat placement, and fallback art. That turns a vague format request into an operable show design.

If the team cannot monitor both outputs, start with one. Adding an unobserved destination creates another way to disappoint viewers. A clean main program with a rehearsed fallback is better than two feeds where nobody notices a frozen vertical output.

• Define the vertical audience and interaction expectation.
• Create separate 16:9 and 9:16 graphic templates.
• Choose what happens to a wide guest grid on a phone frame.
• Assign an owner for each destination preview.

Build the two Cloud OBS programs

Start with the same named contribution ingest in StreamableRun. In Cloud Hosted OBS, make a horizontal main scene and a vertical main scene instead of trying to transform the program at the last minute. Each should have its own crop, browser overlays, and text positions. Give the scenes names a producer can recognize during a callout, such as PROGRAM 16X9 MAIN and PROGRAM 9X16 MAIN.

Create matching fallback scenes. The vertical fallback needs vertical-safe typography and an image that does not put a message under platform controls. The horizontal fallback needs the same viewer context but should use its available width well. Keep the audio policy consistent: decide whether both program outputs carry the same program audio and verify that a fallback transition does not create a mute or doubled track.

Use a separate confidence check for each output. A scene may be correctly framed in Cloud OBS and still be linked to the wrong stream key. The only safe confirmation is the actual YouTube preview for both routes.

• Horizontal main, backup, fallback, and technical scenes.
• Vertical main, backup, fallback, and technical scenes.
• Shared contribution labels, different composition labels.
• Explicit audio routing and mute state for every recovery scene.

Treat the two YouTube keys as separate destinations

YouTube says to select the second stream key for the vertical stream when using the third-party dual-streaming path. Keep those key names and StreamableRun destination labels unambiguous. A common failure is sending the horizontal program to the vertical key or reusing a destination entry because the addresses look similar.

Before the show, run a destination dry run with a slate that visibly says which program is playing. Confirm that the 16:9 preview receives the horizontal slate and the 9:16 preview receives the vertical one. Do not use a vague color-bar test that makes a routing swap hard to spot.

Keep credentials and destination URLs out of the show document. The runbook should identify the route by role, explain how to verify it, and tell the producer who can rotate a compromised key. The controlled destination configuration should contain the private values.

Contribution reliability comes first

A two-format event still has one physical reality: the field source can lose signal. Use a contribution method and bitrate that the location can sustain, then let the cloud program layer make the two layouts. Do not attempt to maintain two independent field encodes unless the event has the hardware, network, and operators to prove that path.

For a mobile source, rehearse loss and recovery. Drop the primary contribution, take both Cloud OBS programs to their correct fallback scenes, bring up the backup source, and check both YouTube previews. The producer should know whether one output can return before the other and how to tell viewers what is happening.

A second format should not make the recovery process mysterious. It should be two well-labelled program decisions operating over the same reliable contribution plan.

Monitoring and producer handoff

Monitor ingest health, horizontal Cloud OBS program, vertical Cloud OBS program, horizontal YouTube preview, and vertical YouTube preview. That sounds like a lot, which is why small teams should keep the scene design simple and use a dashboard or roles that make the distinctions clear. The goal is not to stare at five screens; it is to know which layer owns an error.

For handoff, state the active contribution, which scenes are live, both destination labels, backup ingest status, and fallback trigger. A producer taking over should not need to infer that a vertical scene has different safe-area rules or a separate key. Put that in the one-page event sheet.

If a destination fails while the contribution is healthy, keep the program available where it is working, take the affected output to its planned recovery state, and troubleshoot the destination separately. Do not interrupt the healthy program to repair a key.

• Operator A: contribution and StreamableRun ingest.
• Producer: Cloud OBS scene changes and fallback.
• Monitor: both YouTube previews and health state.
• Event lead: decision to continue with one output if needed.

Design vertical graphics for a moving live show

Vertical live production is more than a center crop. Put host faces, key action, captions, alerts, and lower-third information where a phone viewer can read them without fighting the platform interface. Rehearse walking shots, a two-person conversation, a map, and a wide establishing shot because each one exposes a different crop problem.

Do not copy every horizontal overlay into the vertical program. Keep only the information that helps the phone viewer follow the show. A tall chat panel, timer, donation alert, or sponsor mark can consume most of a narrow frame. Build a deliberate compact version, and decide what disappears when the fallback scene is active.

For text, use a large type size and high contrast, but test it on an actual phone rather than a large desktop preview. A graphic that looks tasteful in a studio monitor may be unreadable outdoors. The producer should have a vertical-safe title and a vertical-safe recovery message ready before the first source problem.

Camera choices also change. A wide horizontal camera can leave the host tiny after crop; a closer vertical-aware camera may be necessary. If you cannot frame both formats well from one source, decide which program is primary instead of presenting a compromised version to everyone.

Run a rapid scene-change drill. Move from host to guest to screen share to fallback, then check both platform previews. If the vertical output shows clipped text, wrong overlays, or a scene that is not meaningful on a phone, fix the scene design before the event.

• Keep faces and essential text in a tested center-safe region.
• Build separate vertical titles, captions, and fallback cards.
• Test on a normal phone at the event's expected viewing brightness.
• Decide which output is primary when one camera cannot frame both well.

Event-day checklist

Open both scheduled YouTube events or destination previews, verify each key label in the controlled configuration, and send a labelled test slate through its normal Cloud OBS scene. Confirm that the horizontal preview is 16:9 and the vertical preview is 9:16. Then test program audio, fallback audio, and the return from fallback.

Just before going live, confirm that the active field contribution is the one shown in both main scenes and that the backup source is warm. During the event, log major scene changes and any destination error separately. After the show, note whether viewers actually used both formats; that operational result should guide the next event more than a generic format trend.

Other resources

Re-check YouTube's setup page before the event. Platform tooling and eligibility can change, while the core production rule stays useful: separate the layouts, label the routes, test both previews, and make fallback part of both programs.