OBS 32.2 SDR and HDR Scene Checklist for Cloud OBS Streams

Why SDR and HDR need a separate test

OBS Studio 32.2 beta release notes list a new filter to compose SDR into HDR. That sounds like a small color-management feature until you put it in a real streamer scene collection: an HDR camera feed, SDR chat overlay, SDR alert browser source, SDR sponsor graphic, clips scene, fallback video, and a YouTube destination that may require HEVC, 10-bit color, and specific color settings.

The useful takeaway is not that every Cloud OBS stream should switch to HDR. Most should not. The useful takeaway is that mixed SDR and HDR scenes are becoming more common because phones, action cameras, capture cards, game consoles, and YouTube output options keep pushing creators toward HDR while the overlay world is still mostly SDR. If you do not test the mix, viewers may see washed-out overlays, dim fallback scenes, wrong colors, or a stream that only looks good on the producer's monitor.

For StreamableRun, keep HDR as an output and scene-design decision, not a last-minute quality checkbox. Send the source into StreamableRun, stage the Cloud Hosted OBS profile privately, test the SDR/HDR mix, and keep a normal SDR rollback profile ready. The public stream should stay recoverable even while color experiments are being evaluated.

Who should care

Care if your stream has any real HDR input or HDR output goal. That includes YouTube-first events, console capture, camera feeds from modern phones, action cameras, high-end capture cards, stage cameras, or polished studio content where archive quality matters. Also care if your stream mixes live camera with browser sources, because overlays are usually where the color mismatch becomes obvious.

Ignore it for now if your whole workflow is SDR and platform-safe H.264. A clean SDR stream with good audio, stable fallback, and sane bitrate beats a half-tested HDR output every time. HDR only earns its place when the source, OBS canvas, encoder, destination, monitors, and fallback scenes all agree.

The StreamableRun operator question is simple: can a producer tell whether the source, scene, and final platform output are correct without being a color scientist? If the answer is no, keep the public output SDR and test HDR privately until the workflow is obvious.

• Care if YouTube is the primary destination and HDR is part of the show promise.
• Care if the main source is HDR but chat, alerts, clips, and sponsor graphics are SDR.
• Care if an action camera, phone, capture card, or console source looks different in preview and public playback.
• Care if the producer monitors on one display but viewers watch on phones and TVs.
• Wait if nobody on the team can explain the SDR rollback path.

Start by deciding the show output

Do not start with the camera. Start with the final show. Is this stream supposed to be SDR or HDR? A mixed scene collection can accept HDR sources and still output SDR. It can also try to preserve an HDR output while bringing SDR overlays into the scene. Those are different jobs.

YouTube's HDR help says OBS HDR streaming requires at least OBS 30.1, a hardware HEVC encoder, Main 10, HDR enabled, P010 color format, and Rec. 2100 PQ or HLG, with YouTube recommending HLG. It also lists hardware-encoder requirements for HLS HDR such as HEVC, 10-bit, BT.2020 primaries, PQ or HLG transfer, and HLS segment rules. Those requirements are not decorations. They decide whether the destination can treat the stream as HDR.

If you are multistreaming to Twitch, Kick, YouTube, and custom RTMP, the shared output should probably stay SDR unless you intentionally split destinations. Kick's normal setup guidance still centers on H.264, CBR, and standard 1080p-style settings. A YouTube-specific HDR experiment should not break the destinations that cannot use it.

• SDR show: keep OBS output SDR, tone-map or adjust HDR sources before they hit the public scene.
• HDR show: confirm source color, OBS canvas, encoder, destination, fallback, and viewer devices.
• Multistream show: default to the profile every destination can accept unless YouTube is intentionally split.
• Archive-first show: test HDR privately and compare the final YouTube archive, not only live preview.
• Chat-heavy show: do not trade readable overlays and low-latency interaction for a color path nobody can monitor.

Build a source and overlay inventory

Mixed color workflows fail because teams only test the hero camera. Make an inventory before you touch the beta. List every source that can appear on program: main camera, backup phone, game capture, local OBS feed, Mevo or YoloBox source, chat browser, alert browser, clips player, sponsor graphic, lower thirds, BRB video, still images, and any emergency slate.

For each source, write whether it is SDR or HDR, whether it can be converted before OBS, whether it appears in fallback, and whether it must stay readable on a normal phone. A sponsor logo that looks clean in SDR may look dull inside an HDR scene. A chat overlay may be too bright. A fallback clip may not carry the metadata you expect. The only honest answer is to test.

Keep fallback scenes boring. The fallback scene should be the place the producer can trust when the main camera or output profile is weird. If the fallback scene is also a pile of fragile HDR clips and browser sources, it cannot do its job.

• Mark every camera or capture source as SDR, HDR PQ, HDR HLG, or unknown.
• Mark every browser source and graphic as SDR unless you have tested otherwise.
• Mark which sources appear in fallback, clips, and technical slate scenes.
• Check text readability on a normal phone, not only the production monitor.
• Keep one plain SDR fallback scene ready even during HDR tests.

Test OBS 32.2 beta without risking production

OBS 32.2 is still a beta as of this run, and the existing stable download page lists OBS 32.1.2 for normal users. That matters. A beta feature can be worth testing, but it should not replace the production Cloud OBS profile five minutes before a stream. Duplicate the profile and scene collection first.

Use a private StreamableRun output for the beta test. Send the same source into both the stable profile and the beta profile when possible. Compare the main HDR scene, SDR overlay scene, fallback, clips, and destination output. Trigger scene switches through the same producer controls the team uses live. If WebSocket buttons, hotkeys, plugins, or browser sources behave differently, the color test is not the only result.

Write down the version and result. OBS 32.2 beta adds more than the SDR-to-HDR filter, so if something changes, you need to know whether it is color handling, plugin behavior, audio routing, browser-source reload, or a producer-control issue.

• Duplicate the stable Cloud OBS profile and scene collection.
• Run the OBS beta only on a staged profile or private server.
• Use the same field source, overlays, and fallback scenes as production.
• Compare stable SDR output, beta SDR output, and beta HDR output separately.
• Promote only if color, audio, browser sources, controls, fallback, and destination output pass.

Monitoring is the hard part

HDR monitoring is where teams lie to themselves by accident. The Cloud OBS preview may not match the platform preview. The producer's monitor may not match a viewer's iPhone. YouTube may process or display HDR differently by device. An SDR browser overlay may look correct in one preview and wrong after encoding. The only way through is to define what counts as truth.

For live production, the truth is layered. Cloud OBS tells you the scene is composed. StreamableRun preview tells you the production path is alive. YouTube Live Control Room or the destination dashboard tells you what the platform thinks it is receiving. A normal viewer device tells you what the audience sees. For HDR, use at least one HDR-capable viewer device and one SDR viewer device.

Do not ask chat to be the color meter. Chat can report obvious issues, but color comments are messy because people watch on different screens. The producer should have a pass/fail checklist: readable text, normal skin tones, no washed-out fallback, no over-dark scene, no unreadable sponsor logo, no audio drift, and a known SDR rollback.

• Check one HDR-capable viewer device and one ordinary SDR viewer device.
• Check platform preview after a scene switch, not only during the opening shot.
• Check fallback and clips under the same output profile as the main scene.
• Check audio and sync because color tests often distract from sound.
• Write a producer rule for when to abandon HDR and return to SDR.

StreamableRun setup path

The clean setup path is layered. The source can be a phone, action camera, capture card, console, local OBS machine, Mevo, YoloBox, or hardware encoder. Send that source into a named StreamableRun ingest. Build Cloud OBS scenes for main HDR or SDR source, SDR overlays, fallback, clips, technical slate, and destination test. Then send output to a private destination before touching the public event.

If the show is SDR, use Cloud OBS to make the HDR source look right inside the SDR scene and keep output platform-safe. If the show is HDR, make the SDR overlays earn their place. Test them against the OBS 32.2 beta filter, the destination, and real devices. If a browser overlay looks bad in HDR, make a simpler HDR-safe overlay or leave it off the HDR scene.

StreamableRun is the best default place to run this test because the producer can recover from source and color mistakes without ending the public stream. The team can keep a conservative SDR profile ready, test the HDR profile privately, and promote only after the exact scene collection passes.

• Create a private StreamableRun destination for the SDR/HDR test.
• Build main, fallback, clips, slate, and destination-test scenes in the staged profile.
• Keep one SDR output profile ready as the event rollback.
• Have the producer test scene switching, browser-source readability, and platform preview.
• Promote the HDR profile only when the public device checks are boring and repeatable.

Other resources

Use these pages to verify current OBS beta release notes, OBS stable availability, YouTube HDR requirements, platform output constraints, and StreamableRun production features before using mixed SDR and HDR scenes live.