To stream HDR on YouTube Live, start with genuine HDR footage, encode it as HEVC/H.265 with the correct 10-bit colour signalling, and send it through an ingest path your encoder supports. Then confirm playback on a supported HDR device; the Live Control Room preview is not a reliable visual check.
An HDR label in a camera menu or game setting is only the start. The source, capture, encoder metadata and YouTube ingest all need to agree, and viewers without compatible displays will receive SDR instead.
Confirm the source is genuine HDR
HDR is a property of the captured or rendered image, not a label that can be added at the end. You need a camera recording HDR footage using PQ or HLG, or a game producing HDR output with its HDR option enabled. YouTube’s Live HDR guidance describes compatible HDR content and an encoder that can carry it.
For camera footage, check the exact model’s manual for HDR video recording and whether it supports PQ or HLG. A camera that records ordinary SDR does not become an HDR source because an encoder is set to an HDR colour space. Similarly, footage that looks bright or colourful on an SDR display is not proof of HDR capture.
For a game, enable HDR both in the game and in the relevant operating-system or console display settings, then check that the capture route receives the HDR output. Menus vary by platform and hardware, so consult the game and capture-device documentation rather than assuming that a setting with “HDR” in its name guarantees the whole path is active.
If your existing asset is an SDR video, keep it SDR. You can make a stream more consistent by avoiding mismatched colour conversion, but you cannot recover highlight and shadow detail that was never captured. YouTube’s separate HDR upload instructions also require HDR metadata in the codec or container for uploaded files; that is a different workflow from live streaming.
Capture HDR gameplay or camera footage
A live chain begins before the encoder. For gameplay, the console or computer renders HDR, and the capture device and software must preserve that output rather than convert it to SDR. Check capture-card passthrough and capture modes, and verify the software recognises the signal as HDR. If you are using a camera, choose its actual PQ or HLG recording/output mode and ensure downstream capture hardware accepts that mode.
Signal handling can fail quietly. A preview may appear washed out, clipped or merely different from what you expected, but appearance alone is an imperfect test because applications and displays handle HDR previews differently. Confirm the input mode in the camera, console, capture utility and encoder where those controls are available. Keep the chosen transfer function consistent through the chain.
A simple capture test before a long broadcast can save a night of troubleshooting. Record or preview a short section with both bright highlights and darker detail, then inspect the source format and capture settings. Do not use the test to claim HDR solely from a file extension or a colourful preview; check the signal information available in the capture software and the device documentation.
This matters particularly for continuous channels. If you are making a 24/7 prerecorded live stream, the source file and the live encoder are still separate stages: the fact that a file is HDR does not mean the output stream preserves HDR. Keep an original copy and make a brief end-to-end test before replacing a stable channel workflow.
Set the encoder to HEVC and signal HDR correctly
YouTube Live HDR currently requires H.265/HEVC. The encoder also needs to signal a 10-bit HDR image correctly: YouTube specifies BT.2020 primaries, a PQ/ST 2084 or HLG transfer function, and the BT.2020 non-constant-luminance matrix. Use the values that match the source. Setting metadata to PQ or HLG when the source was not produced that way does not convert it to genuine HDR.
For an OBS workflow, YouTube documents a compatible hardware HEVC encoder, Main 10 profile, HDR enabled, P010 (4:2:0), and Rec. 2100 PQ or HLG colour space for its described setup. The documented RTMP route specifies OBS 30.1 minimum. These details are specific to the documented configuration, not a promise that every encoder, graphics card or OBS build exposes identical controls. Follow YouTube’s current instructions and the manufacturer’s documentation for your exact hardware and software.
YouTube recommends HLG in its listed OBS setup, but the decisive point is that the transfer function must match your source and workflow. If your camera or game path produces PQ, do not label it HLG merely because a guide recommends HLG for a different setup. Colour fields may be named differently across applications; look for equivalent controls and verify how the encoder writes the output signal.
The codec choice for a live stream should not be confused with the codec options for an HDR upload. YouTube’s upload guidance lists other supported options, including VP9 Profile 2 and AV1, but the current live HDR guidance calls for HEVC. Choosing an upload codec from an export menu will not establish that your live encoder is sending HDR.
Configure the YouTube Live ingest path
Create or manage the stream in YouTube Live Control Room, then select an ingest protocol your encoder can implement with the required HDR capabilities. YouTube supports RTMP(S) or HLS for HDR, subject to encoder compatibility, and recommends HEVC over RTMP(S) for HDR when the encoder supports it. If the required capabilities are not available over RTMP(S), consider HLS only when your encoder’s HLS implementation meets YouTube’s requirements.
In Live Control Room, leave “Turn on manual resolution” unchecked for this setup. For an HLS stream, choose a stream key configured for HLS and keep that manual-resolution option unchecked. Follow the current instructions shown by YouTube and your encoder; do not publish the stream key, because it provides access to your broadcast path.
HLS is not simply a protocol switch. YouTube’s documented requirements for hardware HLS include HEVC, 10-bit depth, BT.2020 primaries, PQ or HLG transfer as appropriate, and the BT.2020 non-constant-luminance matrix. Its segment and playlist requirements include TS segments between 1 and 4 seconds, no byte range, a rolling playlist with no more than five outstanding segments, HTTPS POST/PUT, and no encryption other than HTTPS. Your encoder may present these controls under different names, or manage them automatically; verify its manual and YouTube’s current guidance rather than guessing.
| Ingest choice | When it may fit | What to verify |
|---|---|---|
| RTMP(S) | Your encoder supports YouTube’s HEVC HDR requirements on this path | HEVC HDR signalling is available end to end, and YouTube stream settings match the chosen path |
| HLS | Your encoder supports YouTube HLS and the RTMP(S) route lacks the required HDR capabilities | HLS segment, playlist, transport and colour requirements are met by the encoder |
Do not choose HLS because it sounds more advanced, or RTMP(S) just because it is familiar. The practical choice is the path your particular encoder supports correctly. For general YouTube stream health checks, remember that a healthy connection and an HDR-recognised image are separate checks: one does not prove the other.
Check the stream preview and viewer playback
The Live Control Room preview does not show HDR colours, as YouTube states in its Live HDR help page. Use the preview to check that the stream is arriving and that the picture is broadly present, not to decide whether the HDR grade is being displayed correctly. A normal-looking or flat preview on its own does not settle the question.
For a more useful check, open the live playback on a device and display that support HDR, then open the playback quality settings. On supported playback, YouTube may show an “HDR” label next to a quality option. Check that label rather than relying only on perceived brightness; display settings and ambient light can change how an image looks.
If you are preparing a long-running channel, test with the same type of encoder, ingest path and source you plan to use live. Confirm the stream is recognised as HDR on an HDR-capable display, then also check the SDR fallback on an ordinary display. A bitrate and resolution checklist can help you assess continuity and image quality, but bitrate alone does not identify HDR signalling.
Troubleshoot an HDR stream showing as SDR
First establish whether the test device supports HDR playback. If it does not, YouTube’s SDR delivery is expected and does not by itself indicate an encoder fault. Try a supported HDR display and inspect playback quality settings for the HDR label before changing your stream configuration.
If a supported device still shows no HDR option, work from the source towards YouTube rather than changing several settings at once:
- Confirm the source is actually HDR: game HDR is enabled, or the camera output is PQ or HLG.
- Check that the capture path preserves HDR and has not converted the signal to SDR.
- Verify the encoder is sending HEVC, 10-bit video and the matching BT.2020 and PQ/HLG signalling.
- Confirm the Live Control Room protocol and stream-key selection match the encoder, and that manual resolution is unchecked.
- Recheck playback on a supported HDR device after the stream is running.
These are diagnostic checks based on YouTube’s published requirements, not a guarantee that every missing HDR badge has one cause. If you alter the transfer function, codec or ingest configuration, make one change, then test again. Keep a record of the known-good values so a change intended to fix HDR does not introduce a separate stability problem.
Some encoder interfaces make the colour fields easy to overlook. A label such as “10-bit” describes bit depth, but does not alone identify HDR; similarly, a BT.2020 selection does not prove the source is HDR. All the signal components need to describe the same real source. For a separate audio drift issue in a continuous stream, investigate synchronisation on its own rather than treating it as evidence about colour format.
What viewers on SDR displays see
YouTube automatically delivers HDR to supported devices and SDR to devices that do not support HDR. That fallback is normal. A viewer using an older screen, an SDR monitor or a device whose playback path does not support HDR should not be expected to see the HDR version, even when your stream is correctly configured.
This caveat matters when you ask viewers for reports. One person may see an HDR label while another sees SDR because their screens and playback devices differ. Ask the first person to check the playback quality menu on an HDR-capable device, and avoid using an SDR viewer’s report as proof that ingest failed.
Plan the image so it remains legible in SDR as well. Avoid placing essential text only in subtle highlight detail, and check that faces, captions and important graphics remain readable in the fallback. This does not make the SDR version identical to HDR; it makes the programme more usable across the different playback capabilities YouTube serves.
For a devotional, study or ambience channel, the practical aim is a correctly signalled HDR stream for viewers who can display it, with a reasonable SDR presentation for the rest. There is no configuration that promises HDR playback on every viewer’s device. If your channel uses a fixed video loop rather than live camera or gameplay capture, decide separately whether YouTube’s HDR upload workflow is appropriate; do not assume a live HDR setup converts an SDR loop into HDR.
Keep a repeatable HDR test
Once the stream works, record the actual source mode, capture settings, encoder profile and colour signalling, and ingest protocol. Save the exact software and hardware model details as well. This turns the next update or equipment change into a comparison against a known configuration, rather than a fresh series of guesses.
Repeat the test after changing the camera, capture device, encoder software, graphics hardware or YouTube ingest settings. A small change can affect the point at which HDR is lost. Check both the HDR playback label on a supported display and the SDR appearance on a non-HDR path, while keeping connection health and colour recognition as distinct observations.
For channels with a fixed schedule, make the test before a planned switch, not during the overnight run. StreamNeo can remove the need to leave your own computer running for an uploaded-file broadcast, but it does not turn SDR media into HDR or replace the need to prepare a genuine HDR source and verify YouTube’s HDR requirements. It is designed for YouTube, so keep the HDR capture and ingest checks tied to the workflow you actually intend to use.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I stream HDR on YouTube?
Use genuine HDR content from an HDR-enabled game or a camera that outputs PQ or HLG. Encode it as HEVC/H.265 with 10-bit, BT.2020 and matching PQ or HLG signalling, then use a YouTube-supported ingest path and confirm the HDR label on a supported playback device.
Why is my YouTube stream not showing HDR?
The source or capture path may be SDR, the encoder may not be sending HEVC and correctly matched HDR metadata, or the viewer’s device may not support HDR. Check those stages in order and test playback on an HDR-capable display before diagnosing an ingest problem.
Can I stream HDR with OBS?
YouTube documents an OBS HDR setup using a compatible hardware HEVC encoder and specified HDR settings, including Main 10 and P010. Check YouTube’s current instructions and your exact OBS and hardware documentation; the available controls vary with the encoder and ingest route.
Will every viewer see my stream in HDR?
No. YouTube serves HDR to supported devices and SDR to devices that do not support HDR. Check the HDR label on a supported device, and make sure important content remains clear in the SDR fallback.