You can send an H.265 (HEVC) video to YouTube Live from a remote server, but the documented route depends on the ingest protocol. YouTube’s HLS guide explicitly supports HEVC; its current guidance for RTMP(S) is inconsistent, so verify compatibility in Live Control Room before relying on it.
For a conservative HEVC setup, use HLS if you can accept its usually greater latency. If you need RTMP(S), check the protocol and encoder support for the specific stream key you will use, then test the complete path before the event.
What YouTube’s codec pages currently say
YouTube’s live encoder settings page lists H.265 as an accepted video codec and provides HEVC-specific bitrate recommendations. Its separate protocol comparison page, marked as updated on 1 June 2026, associates H.264 with RTMP and RTMPS, and HEVC with HLS. Those statements do not give you a single unambiguous answer about HEVC over RTMP(S).
The distinction matters when you are preparing a remote server. A codec being listed as accepted in a general settings page does not, on its own, settle which codec is supported by every ingest protocol or by the stream configuration you have created. Avoid building a long-running channel around an assumption that the protocol comparison does not confirm.
Check the YouTube live encoder settings and the YouTube Live ingest protocol comparison directly before configuring production. Documentation can change, and the current stream’s available ingest details are more useful than a remembered setup or an old forum answer. The protocol comparison page carries the update date noted above; do not assume it has been reconciled with the encoder settings page.
This article focuses on delivering an existing HEVC file or feed. The codec is only one part of a working broadcast: the container, audio codec, keyframe pattern, bitrate, network path and stream key all need to fit the chosen ingest route. A file that plays correctly on your server may still fail to arrive as a usable YouTube live stream.
Why HEVC guidance conflicts by protocol
The pages describe the subject at different levels. The encoder settings page presents accepted codecs and general live-encoder recommendations. The protocol comparison divides the supported options by transport, listing H.264 for RTMP and RTMPS and HEVC for HLS. Taken together, they leave a practical question: whether your particular RTMP(S) stream key and encoder can carry HEVC to YouTube.
Do not resolve the discrepancy by choosing whichever sentence sounds more convenient. The settings page is not proof that every RTMP(S) configuration will accept HEVC, and the comparison table is not evidence that YouTube has withdrawn the settings page’s codec listing. The honest conclusion is that the official material currently disagrees about RTMP(S), and you should check the actual stream configuration before depending on it.
The two transports also involve different setup requirements. HLS delivers a playlist and media segments over HTTPS. RTMPS carries a continuous media stream over TLS to a YouTube ingest endpoint. Using HLS does not mean you can simply paste an RTMPS URL into an HLS-capable encoder; the encoder must produce the right format and send it through the right workflow.
If you already use a remote FFmpeg process, keep protocol selection separate from video encoding decisions. First establish whether the stream key is configured for HLS or RTMPS and what the encoder can output. Then choose whether to pass through the HEVC video, remux it into the required container, or transcode it. This is safer than changing several variables at once when a test fails.
For a broader view of keeping a remote process running, the practical considerations in running a pre-recorded YouTube stream from a Raspberry Pi also apply to unattended source playback. The hardware and protocol may differ, but the need to verify that the source, audio and outgoing feed remain active is the same.
Use HLS when documented HEVC support is the priority
YouTube’s HLS ingest guide explicitly lists HEVC. For that route, the guide calls for muxed M2TS media with AAC audio, a closed GOP, and a frame rate no higher than 60 fps. It also describes sending media playlists and segments over HTTPS using HTTP PUT or POST. These are format and transport requirements, not optional tuning suggestions.
A media playlist describes the sequence of media segments to send. YouTube’s guide distinguishes it from a master playlist, so do not assume a general-purpose HLS output can be sent unchanged. The HLS encoder or publishing workflow needs to generate the media playlist and segments in the form YouTube expects. The guide describes segments that last one to four seconds and says this ingest route supports one audio track.
The creator interface may expose an HLS ingestion address, and YouTube also describes obtaining the address through its Live API. The interface route is identified as beta in the guide and may change. Confirm the current endpoint and instructions in the account and documentation you are using rather than copying an endpoint from a different stream or an older tutorial.
For an existing H.265 file, inspect its container and audio before you try to send it. If the video is suitable but the file’s container or audio is not, remuxing may be enough; if the video’s GOP or other encoding properties do not meet the requirements, you may need to re-encode. Do not assume that retaining the video bitstream is always possible just because its codec is HEVC.
HLS is a good fit when your priority is a clear, documented HEVC path, particularly when higher resolution or HDR is important and a delay behind the source is acceptable. It is not automatically the best choice for an interactive broadcast or a programme where you need the lowest possible delay. Decide on that trade-off before adapting your encoder.
Check latency trade-offs before choosing HLS
HLS is segment-based: the encoder creates media segments, and the receiving workflow processes them as they arrive. YouTube describes this kind of ingest as usually having higher latency than RTMP or WebRTC. That makes HLS a reasonable choice for an ambient music station, a devotional loop or a study channel where viewers do not need to see a moment at the same instant it happens.
The delay may matter more for live local news, a small-business event with audience interaction, or a programme where the host responds to comments in real time. A remote operator may also find it harder to judge a change on the watch page when the displayed picture trails the server’s output. The practical question is not whether a delay is inherently acceptable, but whether it fits the way you intend viewers to use the channel.
Shorter HLS segments do not automatically make the overall path equivalent to a low-latency RTMPS stream. The segment duration is only one part of delivery, alongside playlist updates, network conditions and YouTube’s processing. Avoid promising viewers a particular delay unless you have measured it in your own tested configuration and know what it means for the event.
| Consideration | HLS | RTMPS |
|---|---|---|
| HEVC documentation | YouTube’s HLS guide explicitly lists HEVC. | The encoder settings page lists H.265, while the protocol comparison page lists H.264 for RTMPS. Verify the stream configuration. |
| Media format and transport | Muxed M2TS, AAC audio, media playlists and segments sent over HTTPS. | RTMP carried over TLS to the correct YouTube ingest address and application path. |
| Timing | Segment-based and usually higher latency than RTMP or WebRTC, according to YouTube. | Can be preferable when lower latency matters, but that does not settle HEVC support. |
| HDR use | The HLS documentation specifies HEVC and 10-bit colour requirements for HDR. | YouTube’s HDR guidance describes H.265 over RTMP(S), but the protocol documentation conflict remains. |
For a non-interactive 24/7 channel, choosing the clearly documented HEVC route can be more valuable than reducing latency you do not use. If you are scheduling a news loop or a live presentation, first decide how much delay viewers and presenters can tolerate, then test that delay from the watch page. A local preview of the encoder output cannot tell you how long YouTube’s complete path takes.
If your programming uses repeated clips or a playlist rather than one continuous file, it is worth checking that source scheduling remains aligned as well as testing ingest. The advice on fixing an FFmpeg playlist schedule that drifts out of sync is relevant once your output is reaching YouTube consistently.
Verify RTMP(S) protocol and encoder compatibility
If low latency makes RTMP(S) the better fit, treat HEVC as unconfirmed until you have checked the particular stream configuration. In Live Control Room, inspect the ingest protocol and endpoint offered for the stream key. Confirm that your encoder supports the chosen protocol and HEVC combination, rather than assuming support from a generic codec menu.
For RTMPS, YouTube’s RTMPS ingest guidance calls for the correct RTMPS ingest address and application path, a TLS connection on port 443, and SNI set to the server hostname. Use the exact endpoint YouTube provides. A copied URL with the wrong hostname or path can fail before the video codec is even relevant.
Keep the stream key private. Store it in a protected configuration or secret store on the remote host rather than in a public script, screenshot, support post or shared command history. If it has been exposed, replace it in YouTube’s controls and update the remote job before restarting the broadcast.
Errors can help narrow down the problem, but they are not a substitute for checking configuration. YouTube notes that an SSL error can indicate an incorrect endpoint or port, while a timeout can indicate that plain RTMP was attempted instead of RTMPS. Make one change at a time, then test again; changing the key, protocol, endpoint and encoder output together makes it much harder to identify the cause.
For an unattended channel, a server-side restart policy may help recover from a stopped encoder process, but it cannot correct an unsupported codec or an invalid endpoint. Make sure the process reports a clear failure and that you can see whether YouTube is receiving the feed. If you are using HEVC with RTMPS, the decision to continue should be based on a successful test in the same configuration you intend to run, not a claim that HEVC over RTMP(S) is universally supported.
Configure and test the remote encoder
Start by inspecting the source: video codec and profile, pixel format, frame rate, keyframe interval, container and audio codec. For an HLS output, compare these properties with the HLS requirements before deciding to pass the video through. A file can contain HEVC video but still need a new container, AAC audio or a different GOP structure. The official requirements do not validate your particular file or prescribe a single FFmpeg command for every source.
Choose a video bitrate using YouTube’s current encoder settings for the HEVC resolution and frame rate you intend to send. For example, the settings page recommends 10 Mbps for 1080p30 HEVC and 12 Mbps for 1080p60 HEVC; it recommends 30 Mbps for 4K30 and 35 Mbps for 4K60. These are YouTube recommendations, not guarantees of image quality or a promise that your network can sustain the feed. Check the current page before choosing, because recommendations may change.
YouTube recommends constant bitrate (CBR), a two-second keyframe interval and no more than four seconds between keyframes. Its settings also recommend up to 60 fps. Apply those recommendations to the selected codec and protocol, rather than borrowing H.264 bitrate values for HEVC. If the source has a different frame rate or keyframe pattern, determine whether the encoder can adapt it reliably before relying on passthrough.
The remote host needs stable outbound capacity above the selected stream bitrate so that protocol overhead and normal network variation do not leave the feed short of bandwidth. This is practical operating guidance, not a bandwidth figure prescribed by YouTube. If the server shares an uplink with backups or other media jobs, test during the hours those jobs normally run; an idle midday check may not represent a busy overnight period.
Test using the same source, protocol, endpoint, audio path, bitrate and remote server intended for the actual channel. Include movement and sound similar to the real programme, not only a static logo or silent slate. YouTube specifically advises testing before going live and monitoring stream health and warnings during the event. A short successful connection is useful, but it does not show how the process behaves over the full intended runtime.
For a recurring devotional channel, for instance, use the same bhajan file or representative section, verify the AAC audio is present, and check that the loop restarts as expected. The guidance for a pre-recorded bhajan live-streaming setup can help you plan the programme around the encoding work. Keep content rights and channel settings separate from codec testing; successful ingest does not establish that you have permission to broadcast the material.
Confirm the stream in Live Control Room
Once the remote encoder is sending, check Live Control Room rather than treating a successful server process as proof of delivery. Confirm that YouTube receives both video and audio, inspect stream health and warnings, and check the preview or watch page. An encoder can remain running while its network path is stalled or its media is being rejected.
Check that the received resolution and frame rate are what you intended, and that the expected quality options become available on playback. If the picture appears but audio does not, investigate the audio format and muxing separately from HEVC. If audio arrives but the picture is absent, revisit the video codec, profile, pixel format and protocol support. Separate checks make troubleshooting more direct.
For an HLS test, also verify that the sender is publishing the expected media playlist and segments to the endpoint, rather than only generating files locally. For RTMPS, confirm that the endpoint, port and TLS/SNI settings match YouTube’s instructions. Do not infer that a stream is healthy for viewers merely because the remote command has not exited.
After the test, note the protocol, encoder version, source file, bitrate, keyframe interval and any warnings. Keep the record private where it contains the stream key or endpoint credentials. If YouTube changes the available protocol choices, or you replace the encoder or source, repeat the test rather than assuming yesterday’s result applies.
If keeping a computer switched on just to host a repeated file is the part that makes an always-on channel awkward, StreamNeo can remove that specific burden by turning an uploaded video into a YouTube live stream without your computer running. It does not change YouTube’s protocol requirements: confirm the format and stream configuration that your channel needs before you commit to a workflow.
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 YouTube Live accept H.265 over RTMP?
YouTube’s encoder settings page lists H.265, but its protocol comparison page lists H.264 for RTMP and RTMPS. The official material therefore does not provide a consistent, universal answer. Check the current ingest protocol and encoder compatibility in Live Control Room, then test before relying on HEVC over RTMP(S).
What is the clearest documented way to send HEVC?
YouTube’s HLS ingest guide explicitly lists HEVC. It requires muxed M2TS, AAC audio, a closed GOP and no more than 60 fps, with media playlists and segments sent over HTTPS. Confirm the current endpoint and guide before configuring your encoder.
Will HLS have the same latency as RTMPS?
No such equivalence should be assumed. YouTube describes HLS as segment-based and usually higher in latency than RTMP or WebRTC. Test the delay on the viewer-facing watch page and decide whether it suits the programme.
Does a successful test guarantee a successful overnight stream?
No. A test can show that the chosen source, protocol and settings work at that time, but it cannot guarantee future network conditions or uninterrupted operation. Monitor stream health and warnings, and repeat the test after material changes to the source, encoder or ingest setup.