YouTube documents H.265, also called HEVC, as a supported codec for YouTube Live ingest over RTMP or RTMPS, and it also supports H.265 through HLS. That does not mean every H.265 file or encoder configuration will work unchanged: the encoder must send a valid live feed using a supported protocol and suitable settings.
For a typical SDR stream, start with CBR, a two-second keyframe interval, and a bitrate selected for the resolution and frame rate you actually send. YouTube’s figures can change, so check its current live encoder settings before you configure a scheduled broadcast.
Can YouTube Live ingest H.265?
Yes. YouTube’s general live encoder guidance lists H.265 (HEVC) alongside H.264 and AV1 for RTMP/RTMPS ingest. Its HLS documentation also supports H.265, with HDR streaming handled through a more specific HLS workflow. The format is therefore not inherently barred from live transmission.
There is an important distinction between a video file and a live encoder feed. An HEVC file may be stored in a container or encoded with properties that the tool you use cannot pass through as a continuous stream. Your encoder may need to decode and re-encode it, or otherwise produce a compatible live output. Check the encoder’s output settings and the status shown in YouTube Live Control Room; a filename ending in a familiar extension does not prove that the live feed is compliant.
For prerecorded playback, preserve the original frame rate and aspect ratio where practical, but choose the ingest resolution that the encoder is actually sending. If a file is 1080p, for example, selecting a 4K output setting does not make its picture 4K. YouTube indexes its bitrate recommendations by ingest resolution and frame rate, so use the output characteristics, not a hoped-for upscaling result.
Also check channel eligibility before investing time in a test. YouTube’s live streaming eligibility guidance says a channel must be verified and must not have had live-streaming restrictions in the preceding 90 days. Its current start guidance also sets an age requirement. Check the official page for the rules that apply to your account.
If you are assembling a source file for repeated playback, make the loop and file itself reliable before choosing the live settings. The workflow in making a video repeat automatically on YouTube Live is a useful companion for the playback side; it does not replace checking the encoder’s codec and output configuration.
RTMP/RTMPS and HLS: choose by workflow
For ordinary SDR streaming, YouTube documents RTMP and RTMPS. RTMPS encrypts the transport, and YouTube recommends it where available. HLS is another ingestion option when your encoder requires HLS output; it is also the protocol required by YouTube’s HDR live workflow. Confirm that the encoder supports both the chosen codec and protocol, rather than assuming H.265 support automatically implies every protocol is available.
| Workflow | Protocol to consider | What to keep in mind |
|---|---|---|
| SDR live feed | RTMPS, or RTMP if that is what the encoder supports | YouTube’s general encoder guidance covers these protocols; use the current settings page for the latest details. |
| HLS-required encoder | HLS | Verify codec and HLS output compatibility, then review the encoder’s HLS settings against YouTube’s instructions. |
| HDR live feed | HLS | YouTube’s HDR procedure requires HLS and has additional video and metadata requirements. |
The trade-off is not just a menu choice. HLS sends video in segments rather than as a continuous RTMP-style feed, and YouTube notes that HLS has more latency. Ultra-low latency is not available when HLS is selected. That usually matters less for a devotional loop, study ambience or a scheduled prerecorded programme than it does for an interactive broadcast, but you should still allow for the delay when checking the viewer-facing page.
The official HLS ingestion instructions describe implementation details such as segment and playlist handling. These are not settings to guess at from the label “HLS”: use an encoder that exposes the required options, and follow its current documentation as well as YouTube’s. For an FFmpeg-based setup, this guide to configuring YouTube RTMPS in FFmpeg may help with the protocol side, but does not establish that a particular FFmpeg build supports your HEVC feed.
Core SDR settings: CBR and keyframes
For standard dynamic range (SDR), YouTube recommends constant bitrate (CBR). CBR keeps the stream’s outgoing rate comparatively consistent, which makes the feed easier to plan against an upload connection. A variable rate can rise during complex scenes; if that peak exceeds the real available upload capacity, the stream may buffer or drop. CBR does not itself guarantee a clean stream, so leave capacity for other network use and any backup feed.
YouTube recommends a keyframe interval of two seconds and sets a maximum interval of four seconds in its general encoder settings. A keyframe is a frame that can be decoded without relying on earlier picture data. Regular keyframes help the platform and viewers begin decoding at predictable points. Set the interval explicitly if your encoder permits it; do not assume the source file’s GOP structure will be preserved by a live re-encode.
The same general guidance recommends progressive scan, square pixels, two B-frames, one reference frame and CABAC. These are advanced encoder parameters. If your software presents them, compare the values with YouTube’s current page and the encoder’s own compatibility notes. If the control is absent or managed automatically, do not force an unrelated workaround: first verify that the actual output is accepted and stable in a test.
For SDR, YouTube lists Rec. 709 colour and 8-bit video. Keep the signal description consistent with the actual material and output. A mismatch between what the encoder says it is sending and what the video contains can produce incorrect colour, even if the stream connects successfully.
Audio should be checked as part of the outgoing feed, not treated as a separate afterthought. YouTube’s general RTMP/RTMPS guidance lists AAC or MP3; it specifies AAC for 5.1-channel audio, with different sample-rate and bitrate guidance for stereo and 5.1. If you are carrying stereo audio, use the current official table rather than copying a setting from an unrelated guide. For a playlist with inconsistent source levels, normalising before the live session can reduce abrupt changes; see normalising audio across an FFmpeg playlist.
Choose bitrate for resolution and frame rate
YouTube’s current published table gives minimum and recommended ingest bitrates for AV1 and H.265. The following values are in Mbps and refer to the encoder’s outgoing ingest resolution and frame rate, not the original file’s nominal quality. They are platform recommendations, not independently measured guarantees of picture quality. The figures below were checked against YouTube’s settings page on 3 October 2026; verify them again before relying on them for a live event.
| Ingest resolution / frame rate | Minimum | Recommended |
|---|---|---|
| 2160p / 60 fps | 10 Mbps | 35 Mbps |
| 2160p / 30 fps | 8 Mbps | 30 Mbps |
| 1440p / 60 fps | 6 Mbps | 24 Mbps |
| 1440p / 30 fps | 5 Mbps | 15 Mbps |
| 1080p / 60 fps | 4 Mbps | 12 Mbps |
| 1080p / 30 fps | 4 Mbps | 10 Mbps |
| 720p / 60 fps | 2 Mbps | 6 Mbps |
| 720p / 30 fps | 2 Mbps | 6 Mbps |
| 480p / 30 fps | 0.3 Mbps | 3 Mbps |
| 360p / 30 fps | 0.3 Mbps | 3 Mbps |
For example, if your encoder sends 1080p at 30 fps using H.265, YouTube’s listed recommendation is 10 Mbps; for 1080p at 60 fps it is 12 Mbps. The table does not say that every source needs the highest possible setting or that a lower number will always fail. It gives a practical reference point for the chosen output mode.
Resolution and frame rate should reflect the material and the viewing purpose. A static image with slow movement does not gain much from a frame rate higher than its source, while a nature scene with moving water or a news ticker may expose compression more clearly. H.265 is more efficient than older codecs in many use cases, but do not use that general characteristic to invent a separate bitrate target: YouTube publishes the same AV1/H.265 table, so follow its row for the output mode.
The chosen bitrate must also fit the upload connection. YouTube advises that the total outgoing stream bitrate cannot exceed available upload bandwidth and recommends 20% headroom. That means a nominally adequate speed test result is not enough if other devices are uploading, the connection varies, or you send a primary and backup stream. Check the actual path and leave margin rather than aiming to consume all measured capacity.
For a continuous prerecorded stream, reliable capacity matters more than a brief peak reading. Test from the location and network that will run the event, ideally at a time resembling expected network load. If you are comparing a local computer with a remotely managed workflow, account for who will monitor interruptions and restart playback; cloud streaming versus a spare PC lays out that operational distinction without changing YouTube’s bitrate requirements.
Check SDR and HDR requirements separately
Do not carry the SDR checklist into an HDR stream unchanged. YouTube’s HDR guidance specifies HEVC, 10-bit video, BT.2020 primaries and transfer characteristics of ST 2084 PQ or HLG, matched to the source, along with BT.2020 non-constant-luminance matrix coefficients. HDR also uses HLS. If your source is SDR, declaring HDR metadata will not create HDR detail and can lead to incorrect rendering.
A proper HDR pipeline depends on the source and every conversion step preserving the intended signal. Confirm that the file is genuinely HDR, that the encoder can retain or produce its required metadata, and that the stream key and protocol are configured for HLS as YouTube directs. If you are not certain about those parts, a correctly described SDR feed is preferable to a nominal HDR setting that misrepresents the picture.
HLS has its own transport requirements, including short TS segments, a rolling playlist, HTTPS transfer and restrictions on byte-range and encryption modes. Those details are relevant when configuring a compatible encoder, not a reason to select HLS for an ordinary SDR stream by default. Recheck YouTube’s current HDR live streaming guidance and HLS instructions because protocol requirements can change.
Verify the encoder and test the complete path
You do not need to assume that a physical encoder is required. YouTube’s encoder directory includes software, hardware and cloud categories, including tools for continuous prerecorded playback. The useful question is whether your selected tool supports H.265 in the required protocol and can keep the stream running with the schedule, monitoring and recovery you need. A directory listing is not a guarantee that a given product, version or plan accepts your particular file.
For an always-on channel, the practical burden is often not initial configuration but what happens after a file ends, a connection drops or audio falls silent. StreamNeo is relevant when the specific pain is keeping a prerecorded YouTube feed running without leaving your own computer on; whichever approach you use, confirm codec compatibility and check its output in YouTube before depending on it overnight.
Use a short representative test before a scheduled programme. Include motion similar to the real content and its actual audio, since a still frame cannot expose every encoding or continuity problem. Inspect the source file and the encoder output for resolution, frame rate, SDR or HDR state, audio codec and uninterrupted sound. Then open Live Control Room, confirm the incoming stream details and preview the viewer-facing output.
YouTube’s operational tips recommend setting up in advance and starting the encoder before the event; treat those as preparation advice, not a promise that failures cannot occur. Verify that the stream appears on the channel or watch page, check the local archive if you are recording one, and monitor picture and audio. For a file-based feed, also check what happens at the end of the source or playlist, including whether playback returns cleanly to the intended start.
If a test fails, change one part at a time. Confirm protocol first, then output codec, resolution and frame rate, followed by bitrate and keyframe interval. Check network headroom before repeatedly lowering quality, and inspect audio independently. This makes it easier to identify whether the issue is incompatibility, an encoder setting or the connection rather than changing several variables without learning which one mattered.
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
Can I stream an H.265 file directly to YouTube Live?
YouTube accepts H.265 live ingest, but that does not establish that every file can be sent unchanged. The tool must produce a valid continuous feed using a supported protocol, and its output settings matter as much as the file’s codec. Test the actual encoder output in Live Control Room.
What bitrate should I use for 1080p H.265?
YouTube’s published recommendation is 10 Mbps for 1080p at 30 fps and 12 Mbps for 1080p at 60 fps, as checked on 3 October 2026. The table is indexed by the output sent to YouTube, so confirm both the resolution and frame rate the encoder is transmitting. Recheck the official page before a scheduled stream.
Is HLS better than RTMPS for H.265?
Neither is universally better. YouTube documents RTMP/RTMPS for the general SDR path and HLS for HDR or when an encoder requires HLS; HLS has more latency. Choose a protocol supported by your encoder and appropriate to the type of stream.
Do I need HDR settings for an HEVC video?
No. HEVC describes a video codec, not whether the content is HDR. For SDR, use the SDR colour workflow; HDR requires genuine HDR source material, 10-bit output, matching metadata and HLS under YouTube’s current guidance.