YouTube’s live encoder-settings page lists HEVC for RTMP/RTMPS, but a separate official protocol table lists only H.264 for those protocols. The discrepancy is unresolved, so do not assume an FFmpeg HEVC stream sent over RTMP or RTMPS will be accepted.
YouTube’s HLS guide explicitly supports HEVC and sets out a more specific delivery workflow: muxed M2TS audio and video, AAC audio, closed GOPs, and media playlists and segments sent over HTTPS. If you need HEVC, treat HLS as the documented route, then test the complete workflow and account for its higher latency.
Short answer: RTMP/RTMPS guidance conflicts
The concise answer to “Does YouTube support H.265 for live streaming?” is: the answer depends on which official page you read. YouTube’s live encoder settings page places H.265/HEVC in its RTMP/RTMPS settings and supplies corresponding bitrate recommendations. Its protocol comparison instead lists H.264 for RTMP and RTMPS, and HEVC for HLS.
Both are YouTube sources, and the available guidance does not explain why they differ. It does not say that one page is outdated, identify a special RTMP condition, or specify an FFmpeg output that makes the conflict go away. That means you should not treat the encoder-settings codec list as proof that an arbitrary HEVC RTMP/RTMPS stream will ingest successfully.
If your current workflow uses RTMP or RTMPS, H.264 is the codec consistently named for that protocol in the protocol-comparison table. If you want to try HEVC over RTMP/RTMPS because of the encoder-settings page, regard that as a test rather than a production assumption. Keep a known-good fallback available and verify the actual ingest behaviour in the intended channel before an event.
For HLS, the position is clearer: YouTube’s HLS requirements name HEVC, along with particular container, audio, GOP and segment constraints. This is not a claim that every FFmpeg command labelled HLS will meet those requirements. The protocol and packaging need to match the guide.
Compare YouTube’s official protocol pages
The pages answer related but different questions. The encoder-settings table is aimed at configuring a live encoder: it lists codecs and other video settings under an RTMP/RTMPS heading. The protocol-comparison guide sets out what each ingest protocol supports. When the two appear to disagree on HEVC for RTMP/RTMPS, neither page provides a reconciliation.
| Question | RTMP/RTMPS | HLS |
|---|---|---|
| Codec in YouTube’s protocol-comparison table | H.264 | H.264 and H.265/HEVC |
| HEVC in encoder-settings guidance | Listed under RTMP/RTMPS settings | Explicitly covered in the HLS guide |
| Packaging requirements highlighted here | The cited pages do not resolve the HEVC discrepancy | Muxed M2TS, AAC single-track audio, closed GOP, playlists and segments over HTTPS |
| Latency consideration | The cited comparison does not settle the HEVC question | Not suited to ultra-low latency; higher latency may be acceptable for premium, high-quality or high-resolution streams |
This table is a comparison of what YouTube documents, not a promise about a particular encoder build or channel. In particular, “HEVC listed” and “HEVC accepted from this exact FFmpeg output” are not interchangeable statements. Acceptance may depend on details that the public pages do not settle, so avoid turning a codec label into a compatibility guarantee.
Protocol choice also affects workflow. RTMP/RTMPS is familiar to many FFmpeg users who send a continuous encoded stream to an ingest endpoint. HLS, as documented for YouTube, involves media playlists and individual segments delivered using HTTP PUT or POST over HTTPS. That is a materially different output path, not simply a different name for an RTMP URL.
Latency matters alongside codec. The protocol comparison describes HLS as unsuitable for ultra-low latency. If your format depends on very prompt audience interaction, that is a reason to examine the documented RTMP/RTMPS path and use a codec the comparison page clearly lists, rather than choosing HLS solely to use HEVC. For a music, ambience or scheduled programme where a longer delay is acceptable, HLS may be worth testing against its packaging requirements.
Review encoder-setting codec guidance
YouTube’s encoder-settings page provides useful constraints even though the RTMP/RTMPS codec discrepancy remains open. For its listed RTMP/RTMPS settings, it recommends a two-second keyframe interval, with an interval no longer than four seconds; constant bitrate (CBR); progressive scan; square pixels; two B-frames; and one reference frame. It lists support up to 60 frames per second and AAC or MP3 audio. For SDR it specifies Rec. 709 and 8-bit; its general guidance associates HEVC with HDR and lists HDR as 10-bit. Follow the HLS-specific HDR requirements separately rather than assuming these general encoder notes are sufficient for HLS.
The live bitrate table gives different minimum and recommended values according to resolution and frame rate. For instance, YouTube Help lists 4 Mbps as the H.265/AV1 minimum and 12 Mbps as the recommendation for 1080p60; for 2160p60 it lists 10 Mbps minimum and 35 Mbps recommended. These are live-ingest recommendations, not guaranteed picture-quality outcomes and not video-on-demand upload targets. The page groups H.265 and AV1 in this table, so do not read its numbers as a direct measurement of HEVC efficiency or a promise that two codecs at the same bitrate look identical.
Choose a resolution and frame rate that your source and upload connection can sustain, then use the corresponding row as a starting point. A devotional loop made from a mostly static image may behave differently from a local news feed with moving footage, but the settings table does not guarantee that a particular bitrate will look right for either. Check the stream health in YouTube’s Live Control Room while testing representative motion and audio.
YouTube recommends testing upload speed and trying the encoder with audio and representative movement before an event. Leave margin rather than configuring a bitrate that consumes the full measured upstream capacity: other traffic and connection variation can interrupt delivery. If your upload cannot sustain the selected bitrate, reducing resolution or frame rate may be more dependable than insisting on a higher setting.
Check which HEVC encoder FFmpeg can use
FFmpeg does not necessarily include every encoder in every downloaded build. Its codec documentation describes libx265 as the wrapper for the x265 HEVC encoder. The FFmpeg build must have been configured with the libx265 library and enabled with --enable-libx265. If libx265 is absent from your build, a command using it cannot work merely because FFmpeg itself is installed.
Check the encoders available in your actual FFmpeg binary before constructing a workflow. The -encoders option can list available encoders; look for the encoder you intend to use rather than inferring availability from an example found online. A software path such as libx265 and a hardware path such as hevc_nvenc have different prerequisites. FFmpeg documents a hardware-encoding example for hevc_nvenc, but that does not establish support for every GPU model or confirm performance at a chosen resolution.
A compatible GPU is optional, not a requirement for all HEVC encoding. If you are considering one for continuous output, verify the exact model’s encoding capabilities against the manufacturer’s specifications and confirm that your FFmpeg build exposes the relevant encoder. A software encoder may be adequate if your computer can handle the chosen settings, while hardware encoding may be useful when it is available and suitable. Do not buy hardware on the assumption that it will resolve YouTube’s protocol ambiguity.
FFmpeg’s documented options include bitrate (b) and GOP size (g), but the option names alone do not create a YouTube-compliant stream. The output must also have the right codec, pixel format, frame rate, keyframe structure, audio and container for its chosen protocol. In HLS, playlist and segment handling matters as much as selecting an HEVC encoder.
If you are already building a long-running setup, the practical questions around encoder availability and restart behaviour overlap with using NVENC with FFmpeg for a continuous YouTube stream. That guide is relevant to the hardware path, but it does not resolve YouTube’s HEVC protocol discrepancy.
Understand the HLS HEVC route
YouTube’s HLS guide is explicit that HLS supports H.264 or HEVC video. It describes HLS as appropriate for premium, high-quality or high-resolution content when relatively higher latency is acceptable, and says it is not suited to ultra-low latency. That makes it a real option to investigate, not an automatic replacement for an RTMP workflow.
The distinction matters for a 24/7 channel. A continuous loop can often tolerate more delay than a live discussion that depends on quick audience responses, but you still need to test how the selected workflow behaves in the channel. Think through the programme’s actual requirement: if listeners need to react to a moment immediately, HLS’s latency trade-off may be a poor fit. If the content is a scheduled ambience stream, higher latency may be workable, provided the upload and packaging remain stable.
The HLS guide describes sending media playlists and segments over HTTPS, using HTTP PUT or POST. Your output therefore needs to create the required playlist-and-segment workflow and deliver it in the form YouTube expects. Do not assume that changing an RTMP URL to an HLS endpoint is enough; the muxing and segment behaviour must also conform.
If HLS is a candidate, follow the official HLS ingest requirements while checking the endpoint and current instructions in Live Control Room. The guide’s explicit HEVC support is useful, but it does not certify a particular FFmpeg build, command line or hosting arrangement. Confirm the actual output and test it end to end.
For HDR, be particularly careful not to carry settings across protocols by assumption. YouTube’s HLS-specific guidance calls for HEVC with 10-bit PQ or HLG, non-constant luminance, and YUV 4:2:0 10-bit chroma. Selecting an HEVC encoder does not itself establish that the signal is HDR or that those colour characteristics are being sent correctly. If you do not need HDR, avoid adding it as another variable while you are first validating basic ingest.
Check HLS container, audio, GOP and segments
The HLS requirements are specific enough to use as a preflight checklist. YouTube requires audio and video muxed in M2TS. It accepts H.264 or HEVC video, up to 60 fps, and requires closed GOPs. Audio is AAC in a single track. An output that contains HEVC but uses the wrong container or audio arrangement is not made compliant by the video codec alone.
A GOP is a group of pictures. The closed-GOP requirement means that the group should not depend on frames outside that group for decoding. This is distinct from merely setting a keyframe interval. YouTube’s encoder settings recommend a two-second interval for the RTMP/RTMPS guidance, not exceeding four seconds; for HLS, use the HLS guide’s closed-GOP requirement and ensure your actual segment workflow is aligned with it. The two pages address related encoding details but should not be collapsed into one universal recipe.
HLS segments are described as lasting one to four seconds. The playlist refers to the media segments, and those items are sent over HTTPS through HTTP PUT or POST. A failure in playlist updates, segment duration or delivery can prevent a usable stream even if the encoded frames themselves look correct. Inspect the generated media and the delivery logs rather than relying on the command completing without an obvious error.
Audio merits its own check. The HLS guide specifies AAC single-track audio, whereas YouTube’s general encoder-settings page lists AAC or MP3 in its RTMP/RTMPS settings. Do not carry MP3 from an RTMP configuration into HLS on the strength of that general table. Verify that audio and video are muxed together in M2TS and that the HLS audio condition is met.
A useful preflight record includes the FFmpeg build and selected encoder, output codec, resolution, frame rate, bitrate, audio codec and track count, container, GOP configuration, segment duration and playlist delivery method. Keep a known-good copy of the settings. If you alter several elements at once, a failed test becomes harder to diagnose; change one relevant variable at a time and retest.
For a basic stream-key workflow, protect the credential while testing rather than pasting it into a command that may be recorded in shell history. The practical precautions in using a YouTube stream key in FFmpeg without exposing it in shell history are relevant whether you are trying a conventional RTMP output or arranging another ingest path.
Test the intended ingest workflow
Test the protocol you plan to use, with the exact FFmpeg binary and channel you intend to use for the live event. A local encode test can tell you whether the encoder runs and whether the file or segments are produced; it cannot establish that YouTube accepts the stream. A successful connection is also not enough on its own. Check that the preview plays, audio is present, the picture is stable, and Live Control Room reports healthy stream status over a meaningful test period.
For RTMP/RTMPS HEVC, make the uncertainty part of the test plan. Consult both official pages immediately before deployment, record which guidance you relied on, and test the specific resolution, frame rate, audio and encoder output. Do not infer that a successful short connection proves a long broadcast will remain stable. Keep an H.264 RTMP/RTMPS fallback ready if the protocol-comparison page’s clearer codec listing is relevant to your production needs.
For HLS, verify the full chain: HEVC video, M2TS muxing with AAC single-track audio, closed GOP, frame rate within the documented limit, playlists and segments in the described duration range, and HTTPS delivery using the documented method. Check that the player receives ongoing media and that the latency is acceptable for your format. Test both picture and sound, and use movement similar to the actual programme rather than only a static slate.
Measure the upload connection under the conditions in which the stream will run. YouTube recommends an upload speed test; compare capacity with the bitrate for your chosen resolution and frame rate, and avoid occupying all available upstream bandwidth. If other people or devices share the connection, test with their usual activity in place. Monitoring during a test tells you more than the nominal speed printed on a broadband plan.
When a test fails, narrow the cause in a deliberate order: confirm the encoder exists in the build, confirm the stream key and endpoint, inspect codec and container, then check audio, frame rate, bitrate and GOP or segment settings. Use YouTube’s current help pages and the FFmpeg documentation rather than copying a command whose assumptions may differ from your build. For a prerecorded always-on channel, it also helps to understand the wider stream-key setup for a 24/7 prerecorded broadcast, including the steps around preparing and starting the stream.
A test is evidence about that tested configuration, not a blanket endorsement of HEVC over a protocol. Recheck official documentation before a consequential event, especially while the RTMP/RTMPS pages remain inconsistent. If your workflow cannot tolerate uncertainty, use the codec-protocol combination YouTube states consistently, or choose the explicit HLS HEVC route only if its packaging and latency trade-offs suit your channel.
For an always-on channel that uses a prepared video rather than a live FFmpeg encode, the more important operational problem may be keeping the broadcast running when your computer is off. StreamNeo removes that specific need to leave your own computer running by turning an uploaded video into a YouTube live stream, though it does not change YouTube’s codec requirements or the protocol conflict discussed 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 YouTube support HEVC live streaming from FFmpeg?
YouTube’s encoder-settings page lists HEVC in its RTMP/RTMPS settings, while its protocol comparison lists only H.264 for those protocols. The documents do not resolve the discrepancy, so the listing is not a guarantee that a given FFmpeg HEVC RTMP stream will ingest. YouTube’s HLS guide explicitly supports HEVC, subject to its packaging requirements.
What bitrate should I use for HEVC?
Use the H.265/AV1 row in YouTube’s live encoder-settings table for your target resolution and frame rate, then ensure your upload can sustain it. For example, the table lists 4 Mbps minimum and 12 Mbps recommended for 1080p60; these figures are YouTube Help’s live-ingest guidance, not a quality guarantee. Test with representative motion and monitor stream health.
Can I use libx265 with any FFmpeg download?
No. The build needs to include the libx265 library and be configured to enable it; check the encoders available in your own binary. A documented hardware path such as hevc_nvenc also depends on compatible hardware and build support. Neither encoder choice resolves whether YouTube accepts HEVC over RTMP/RTMPS.
Is HLS a better choice than RTMP for HEVC?
HLS is the clearer documented HEVC path, but it requires M2TS with muxed audio and video, AAC single-track audio, closed GOPs, and playlist-and-segment delivery over HTTPS. YouTube says HLS is not suited to ultra-low latency. Choose it only if the packaging work and additional latency fit your stream, then test the complete workflow.