A 4K output is not automatically an HDR stream. To send 4K HDR from AWS Elemental Live to YouTube, you need compatible HDR source content, HEVC encoding and correctly signalled colour, as well as an HLS output configured for YouTube.
The values below come from an AWS worked example published in 2021. Use them as a configuration reference, not a current universal preset: check YouTube’s current HDR and live encoder guidance and the documentation for your installed Elemental Live version before you schedule a broadcast.
Check the source and HDR compatibility
Start by confirming what the input actually contains. A 3840×2160 picture can be SDR, HDR10 or HLG; resolution alone does not tell Elemental Live or YouTube how the image should be displayed. Check the camera, file or upstream feed documentation and inspect its format and colour metadata where possible. You need genuine HDR content in a format your installed Elemental Live system can accept and process.
YouTube’s HDR streaming guidance specifies HEVC and a 10-bit signal for HDR, with BT.2020 colour primaries and matrix plus a transfer characteristic matching the content: PQ (ST 2084) or HLG. The source, encoder conversion and outgoing metadata must agree. Forcing HDR10 metadata onto SDR material does not create HDR detail; it can instead make colours and brightness look wrong on viewers’ devices.
Write down the source’s resolution, frame rate, codec, bit depth and HDR format before configuring an output. If the feed is HLG, do not assume that an HDR10 preset is the right conversion. If it is SDR, make a deliberate decision about whether to stream it as SDR rather than labelling it HDR. Where the source format or metadata is unclear, resolve that with the camera operator or content supplier before the event.
Also establish what the installed appliance and software version support. AWS’s Elemental Live documentation describes output colour-space requirements, but available options depend on the installed system and licensing. AWS’s note about a particular 4K appliance-series requirement concerns Dolby Vision output; do not generalise that specific restriction to HDR10. Check your own version’s colour-space output requirements and confirm HEVC Main10 capability.
If you are deciding between a specialist encoder workflow and a file-led channel, first be clear about what the broadcast needs to do. A local-file setup such as the one in this guide to streaming videos from local storage with OBS may suit a simpler SDR loop, but it is not a substitute for verifying an HDR chain end to end.
Choose YouTube HLS ingest and an HLS stream key
The AWS example uses an Apple HLS output group directed to YouTube’s HLS ingest endpoint, with the channel’s stream key inserted into the destination. In YouTube Live Control Room, create or select an HLS stream key for the HDR broadcast and leave “Turn on manual settings” unchecked, as YouTube’s current HDR instructions specify. Do not copy a key into notes, a public ticket or a published configuration example.
Use the ingest URL shown in the current YouTube setup instructions rather than relying on a 2021 screenshot or copied endpoint string. AWS’s worked URL includes a trailing ampersand; endpoint syntax and interface labels can change, so use the exact current address and credential format YouTube supplies. Treat the key as a credential: restrict who can see it, and replace it if it is exposed.
HLS is not just a destination name. YouTube specifies transport-stream segments, HTTPS POST or PUT, no byte ranges and no encryption beyond HTTPS. Its HDR HLS guidance also specifies rolling playlist behaviour. These requirements belong in the output configuration, not merely in the stream-key label. Check the current YouTube HDR HLS requirements as you set up the event, especially if your Elemental interface uses different terms from YouTube’s documentation.
Before you start a live event, confirm that the stream key is HLS, that the destination is for the intended channel, and that the event is configured for the same ingest protocol. A key intended for another protocol is not interchangeable simply because the channel is the same. You can use YouTube’s live encoder settings alongside its HDR page to check current encoder and frame-rate guidance.
Configure the Elemental Live HLS output
In AWS’s 2021 walkthrough, the operator creates an event, configures the input, adds an Apple HLS output group, and sets the YouTube destination and stream key. The example uses Basic PUT and a two-second segment length. Those are the values shown in that particular tutorial; check the installed Elemental Live controls and YouTube’s current HLS requirements before carrying them over.
A practical configuration pass should keep the destination, transport and playlist choices together. First select the HLS output group. Then enter the current YouTube endpoint and the channel’s HLS stream key in the appropriate destination fields. Select the supported HTTPS method and confirm that the output is not using byte ranges or additional encryption. Finally, set segment and rolling-playlist behaviour to match YouTube’s current requirements.
Avoid treating a field label as proof that a requirement is met. For example, an output named “HLS” may still have a segment duration or playlist setting that needs adjustment. Read the generated output details, validate the destination syntax and review the event status before the scheduled start. If a field in your software is absent or named differently from the older AWS article, use the current installed-version manual rather than guessing from an old screenshot.
Keep the event configuration separate from any notes that contain credentials. Record non-sensitive details such as source format, selected codec, frame rate, segment duration and test outcome. That gives the next operator a useful checklist without leaving a reusable stream key in a shared document. If you also run a long-form channel with a different workflow, this guide to running a 24/7 stream from a VPS explains why a persistent stream has operational considerations beyond the encoder’s picture settings.
Set video resolution, codec, frame rate and bitrate
The AWS worked setup uses 3840×2160, HEVC, 59.940 frames per second and 20,000,000 bits per second. It also specifies Main10/main profile, two B-frames, a closed GOP cadence of one, one reference frame and scene-change detection. Read that as a documented example configuration, not as a promise that every source, appliance or event should use those exact values.
| Setting | AWS 2021 worked example | What to check for your event |
|---|---|---|
| Resolution | 3840×2160 | Match the intended output and the source’s usable detail. |
| Codec and profile | HEVC, Main10/main profile | Confirm HEVC Main10 support and a genuine 10-bit HDR path. |
| Frame rate | 59.940 fps | Match a supported rate to the source and YouTube’s current guidance. |
| Video bitrate | 20 Mbps | Consult YouTube’s current table for your codec, resolution and frame rate. |
| GOP | 2 seconds | Keep the keyframe interval within current YouTube guidance. |
For a stable picture, avoid converting frame rate or resolution without a reason. If the incoming camera feed is 30 fps, selecting 59.94 fps does not add motion detail; it can add processing work and duplicate or interpolate frames. A 4K output from a lower-resolution source similarly does not restore detail that was never captured. Match the output to the source where practical, then make any required conversion intentionally.
Bitrate is a trade-off between picture detail, encoder capability and the available upload path. AWS’s 20 Mbps is not a universal YouTube recommendation. YouTube publishes guidance by resolution and frame rate, and you should check the current value for the actual codec and frame rate you intend to send. Its general encoder guidance also calls for a two-second keyframe frequency and says not to exceed four seconds; use the current official page rather than treating this article’s example as a substitute.
The bitrate setting is not the same as the internet connection’s full requirement. Leave headroom for other traffic and account for audio and protocol overhead, then test from the actual venue or network. A connection that appears adequate during a quiet office test may behave differently when other users are uploading. For a channel based on repeated videos rather than a live camera, compare the separate concerns in this guide to looping pre-recorded videos through Owncast; changing the playback route does not remove the need to meet YouTube’s ingest requirements.
Configure HDR10 signalling and colour conversion
In the AWS example, the operator enables the colour corrector and selects Force HDR10. Do not interpret that as an instruction to force HDR10 on every source. The conversion and outgoing metadata should represent the source’s actual HDR format. YouTube’s supported HDR signalling includes BT.2020 primaries and matrix with either PQ/ST 2084 or HLG transfer characteristics consistent with the content.
This is where an apparently successful stream can still be wrong. A 10-bit HEVC encode and a 4K frame do not, by themselves, establish that the colour transfer function is correct. Check the input’s HDR format, the conversion settings and the output signalling together. If you convert HLG to PQ or otherwise transform the colour, use a workflow supported by your installed Elemental version and verify the result with suitable HDR monitoring. Do not simply change a menu option to obtain an HDR label.
The correct choice depends on the content and the delivery chain. A camera feed mastered or captured as PQ should not silently be signalled as HLG; an HLG source should not be labelled PQ without a deliberate conversion. When the source is mixed, unknown or already processed by upstream equipment, confirm where the colour transform happens so that the signal is not converted twice or tagged inconsistently.
YouTube says viewers on supported HDR devices can receive HDR, while viewers on devices without HDR support receive an SDR version. That delivery behaviour does not let you infer that the source was correctly signalled. Check the current YouTube help page and the Elemental output requirements, and if you cannot verify the source or conversion, consider sending an SDR stream rather than mislabelling the picture.
Match GOP, segments and playlist behaviour
The AWS example uses a two-second GOP, which is aligned with YouTube’s general guidance for a two-second keyframe frequency. In the example’s video settings, the GOP is closed and its cadence is set to one. YouTube’s general guidance says not to exceed a four-second keyframe interval. Confirm how your installed Elemental Live version expresses GOP size and cadence, then verify the encoded output rather than relying only on a number typed into a field.
HLS segments have their own timing. YouTube’s HDR HLS requirements specify MPEG-2 transport stream segments from one to four seconds and rolling playlists with no more than five outstanding segments. The AWS example uses two-second segments. A segment duration and a GOP duration are related operational choices, but they are not the same setting: check both. Where possible, avoid segment boundaries that create irregular keyframe spacing or a playlist that accumulates segments beyond the allowed behaviour.
YouTube specifies HTTPS POST or PUT for HLS ingest, no byte ranges and no encryption other than HTTPS. Confirm the selected method and playlist mode in Elemental Live, and check that the output is not applying a feature that conflicts with those requirements. Exact interface wording may vary by software release. If your installed version does not expose an option that appears in the older example, consult the current AWS guide for that version and YouTube’s current HLS instructions.
These details matter particularly for an event that will run unattended. A playlist that looks acceptable during a brief test may behave differently once it rolls for longer. Review the output state and logs during a sustained test, and retain the settings that worked without storing secrets. If your operation also depends on a timed schedule, the considerations in separate morning and evening YouTube live playlists can help distinguish scheduling questions from ingest and encoding questions.
Test the feed and verify YouTube preview
Test with the actual source, event configuration and network before an audience is waiting. Start the output, confirm Elemental Live reports a healthy input and output, and check that YouTube receives the feed in Live Control Room. A test should run long enough to observe segment and playlist behaviour, not just the first few seconds after pressing start. Do not publish the key or leave the event configured with a temporary credential that someone else can reuse.
Check the preview for continuity, framing, audio and obvious encoding errors, but do not use it as proof of HDR appearance. YouTube notes that the Live Control Room preview does not display HDR colours, so it cannot reliably confirm how the stream will look on a supported HDR screen. For visual confirmation, use an appropriate HDR-capable viewing path and device, and confirm the signal metadata separately. A preview that appears flat or SDR-like does not alone settle what the final viewer receives.
A useful test record includes the source format, output codec and profile, frame rate, bitrate, keyframe interval, HLS segment duration, playlist behaviour and any warnings. Note whether YouTube accepted the feed and whether the stream remained stable through the test. If the picture is wrong, investigate source metadata and colour conversion before changing several encoder values at once. If YouTube rejects the feed, compare the actual stream key type, endpoint and HLS transport options against the current official instructions.
Before an event, recheck the current YouTube HDR page and the documentation for the Elemental Live version installed at the venue. The AWS tutorial dates from 2021; it is useful as a worked path through the interface, but not evidence that its screens or exact values remain current. A short, controlled test is more useful than discovering a protocol or colour mismatch after the channel is live.
If your requirement is instead a recurring file-based channel and you do not need to operate a specialist encoder at the venue, StreamNeo can remove the need to leave a local computer running by taking an uploaded video and broadcasting it to YouTube. It is YouTube-only, so it is not a replacement for an Elemental workflow when you need the specific live HDR ingest configuration described here.
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
Does AWS’s 20 Mbps example guarantee YouTube 4K HDR will work?
No. It is the bitrate in AWS’s 2021 worked setup, not a universal target or guarantee. Check YouTube’s current bitrate guidance for your chosen codec and frame rate, and test the full source-to-ingest path on the installed system.
Can I make an SDR video HDR by selecting Force HDR10?
No. HDR signalling should accurately describe compatible HDR source content and any deliberate colour conversion. Forcing HDR metadata onto SDR footage does not create HDR detail and can make the image look wrong.
Is a 4K HEVC stream enough to count as HDR?
No. YouTube HDR also requires compatible HDR content and the right 10-bit colour signalling, including BT.2020 and a matching PQ or HLG transfer characteristic. Confirm those alongside HEVC encoding.
Can I confirm HDR by looking at the Live Control Room preview?
Not reliably. YouTube says the Live Control Room preview does not display HDR colours. Use it to check that the feed arrives and looks continuous, then verify signalling and view through an appropriate HDR-capable path.