You do not necessarily need to convert H.265 (HEVC) videos to H.264 before sending an FFmpeg playlist to YouTube Live. Choose the ingest protocol first, then check whether your files and FFmpeg output meet that protocol’s requirements.
An FFmpeg input playlist that plays files in sequence is not the same thing as YouTube’s HLS media playlist. For a straightforward live broadcast, RTMPS may be simpler; HLS has specific segment and playlist rules. Test the actual stream in YouTube Studio before leaving a VPS process to run unattended.
Identify the playlist and ingest protocol
First separate the job into two parts: how FFmpeg reads your source videos, and how it sends the resulting live stream to YouTube. The input might be a text file listing local clips for FFmpeg to play one after another. That is an input playlist. It does not instruct YouTube to accept HLS, create HLS segments, or satisfy YouTube’s HLS ingest rules.
The outgoing connection is a separate choice. With RTMP or RTMPS, FFmpeg sends a continuous stream to YouTube’s ingest endpoint. With HLS ingest, the sender must produce and deliver a media playlist and transport stream segments in the format and manner YouTube expects. YouTube documents the two paths separately in its live encoder settings and HLS ingestion guidance.
For many playlist streams, start by considering RTMPS. It is the secure version of RTMP, and YouTube recommends it for live streaming. HLS is appropriate when you have a reason to use that protocol and can implement its segment delivery requirements. Neither path makes every file combination automatically compatible.
Write down your intended path before changing codecs: source files, FFmpeg input method, output video and audio formats, resolution, frame rate, and YouTube ingest protocol. If you are moving an existing process to a VPS, this VPS migration walkthrough can help you think through what moves and what still needs testing. The playlist format and the ingest protocol must remain distinct in your configuration and troubleshooting.
Check codec support for that protocol
YouTube’s published live encoder guidance lists H.265/HEVC as a supported video codec for RTMP/RTMPS, alongside H.264 and AV1. Its HLS guidance also lists HEVC as supported. That means the codec name alone is not a reason to re-encode every source to H.264.
However, codec support is not a promise that every file can be passed through unchanged. A file also has a container, pixel format, frame rate, dimensions, audio tracks, and stream characteristics. The way your FFmpeg build reads and muxes those streams matters too. Inspect the actual inputs and validate the output path rather than inferring compatibility from a filename ending in .mp4 or a label saying HEVC.
For RTMP/RTMPS, YouTube lists AAC or MP3 audio. For HLS, it lists AAC, AC3, or EAC3. If you are sending 5.1 audio over RTMP/RTMPS, YouTube specifies AAC; do not assume an audio track that works in a local file will be acceptable in the live stream. Stereo guidance is 44.1 kHz and 128 kbps, while its 5.1 guidance is 48 kHz and 384 kbps. These are YouTube’s published settings, not requirements for every possible source file or a guarantee of successful ingest.
Also confirm the current official documentation before deployment, since YouTube can revise accepted settings. The encoder settings page is the place to check supported codecs, bitrate guidance, audio settings, and keyframe recommendations. Treat it as the reference for the selected protocol, not as a substitute for a real test with your FFmpeg output.
Decide whether conversion is necessary
Inspect representative files before writing a conversion command. FFmpeg’s ffprobe can show video and audio codecs, stream dimensions, frame rate, pixel format, and container. Compare more than one file if your playlist has been assembled over time: one clip may use a different frame rate, audio layout, or encoding profile from the others. A playlist with mixed properties may need a consistent output even when each file can be decoded individually.
If the video stream is HEVC and the chosen YouTube ingest path supports it, test whether FFmpeg can pass the video through while producing a suitable output stream. Passing through avoids a full video re-encode, which can reduce VPS processing demand and avoid an additional lossy encoding step. It does not remove the need to handle audio, muxing, keyframes, bitrate behaviour, or inconsistencies between clips. Watch for changes in resolution, frame rate, or audio when one file ends and the next starts.
Transcode when a specific compatibility or consistency problem calls for it: for example, when the selected muxing path does not accept the source stream as-is, when sources vary in ways your output cannot accommodate, or when you need a different output codec or frame rate. H.264 is a common target, but choosing it should solve an identified problem rather than follow a blanket rule that HEVC is unsupported. Re-encoding consumes CPU on the VPS and can reduce image quality if the settings are poorly chosen.
Do not begin with a long, unattended run. Test a short section containing movement and audio, then examine YouTube Studio’s stream health and the FFmpeg output. If you need to change one variable, change one variable at a time: video pass-through versus transcode, audio handling, or protocol. This makes the cause of a failure easier to identify.
The same source-inspection discipline matters when preparing a large batch of clips. A guide to compressing playlist videos is useful for thinking about file size and consistency, but compression and codec conversion are not interchangeable. Do not compress a source simply because it is HEVC; first establish what is wrong with the stream you intend to send.
Match output resolution, frame rate and bitrate
Choose output settings for the resolution and frame rate you will actually send. YouTube’s encoder table gives codec-specific bitrate recommendations. For H.265/AV1, it recommends 10 Mbps at 1080p30 and 12 Mbps at 1080p60; the listed minimum for those rows is 4 Mbps. For 720p30 and 720p60, the recommended value is 6 Mbps. These are YouTube’s published recommendations, not a promise that a particular VPS connection will sustain the stream.
| Intended output | YouTube recommended video bitrate for H.265/AV1 | Practical implication |
|---|---|---|
| 720p30 | 6 Mbps | A lower-resolution option when that matches the content and available connection |
| 720p60 | 6 Mbps | The same listed recommendation as 720p30; confirm that the source genuinely benefits from 60 fps |
| 1080p30 | 10 Mbps | Use the 30 fps row rather than borrowing the 60 fps setting |
| 1080p60 | 12 Mbps | Requires more sustained upload capacity than the 1080p30 recommendation |
Keep audio and network variation in mind when checking whether a VPS can sustain the output. The connection needs headroom beyond the video bitrate; a speed test at one moment does not demonstrate a stable all-night upload. Choose the quality that your sustained connection can handle, and observe the actual stream health rather than assuming the VPS plan’s headline network figure describes your route to YouTube.
For RTMP/RTMPS, YouTube recommends constant bitrate (CBR) and a two-second keyframe frequency, with a four-second maximum. These settings affect what you encode or pass through and should be checked against the stream YouTube actually receives. A source file’s keyframe spacing may not match the target interval; if so, video pass-through might not meet the intended output behaviour, and transcoding may be needed.
Frame rate should be intentional too. YouTube’s general settings allow up to 60 fps. Avoid converting a 30 fps source to 60 fps just to select a higher bitrate row: that does not create genuine motion detail. Match the output to the source and channel needs, then use the corresponding row in YouTube’s current table.
Audio is part of the output decision, not an afterthought. If clips have different sample rates, channel layouts, or codecs, decide whether to normalise them so the stream does not change unexpectedly between files. For a music stream, the audio bitrate guide offers relevant context; still check YouTube’s current guidance for the ingest protocol and channel layout you use.
Configure RTMPS or meet HLS requirements
If you choose RTMPS, configure FFmpeg to send a continuous output to the YouTube ingest URL and use the stream key provided in YouTube Studio. Follow YouTube’s current encoder settings for codec, rate control, keyframe interval, resolution, frame rate, and audio. Keep the key private: do not paste it into a public script, a shared issue, or a command history that other VPS users can read. Use a protected configuration method appropriate to your environment.
RTMPS encrypts the connection in transit, which is why YouTube recommends it over unencrypted RTMP. That does not make the stream key harmless: anyone who obtains it may be able to broadcast to your channel’s ingest. If you are unsure how a key is exposed in a backup or profile, review this stream-key safety guide before copying the configuration between machines.
HLS requires more than selecting an HLS-related FFmpeg option. YouTube’s documented HLS ingest uses MPEG-2 Transport Stream segments lasting 1–4 seconds, a rolling media playlist with no more than five outstanding segments, HTTPS POST/PUT delivery, and no byte ranges. The audio and video streams must also use codecs supported by YouTube’s HLS guidance. A local FFmpeg input playlist does none of this by itself.
If you choose HLS, compare the generated playlist and segment behaviour with YouTube’s current HLS setup page, including how your sender delivers the objects. Do not assume that a command which creates .ts files is a compliant YouTube HLS sender. If you cannot explain how the playlist rolls forward, how old segments are handled, and how segments reach YouTube over HTTPS, pause and test the protocol implementation before relying on it.
Whichever protocol you select, keep the stream key out of visible command output and logs where possible. FFmpeg supports different muxers and recovery approaches; consult the FFmpeg documentation for the exact options in your installed version. A recovery option can help with certain temporary network failures, but it is not a substitute for supervising the process and confirming that YouTube has resumed receiving a healthy stream.
Test the VPS stream in YouTube Studio
A command that exits without an error is not proof that YouTube is receiving the intended stream. Set up a private or unlisted test in YouTube Studio, start the FFmpeg process from the VPS, and check the incoming preview and stream health. YouTube advises testing before going live and using movement and audio similar to the real broadcast. A static test frame will not reveal every issue in a playlist of moving clips.
Test a transition between files, not only the first minute of the first file. Confirm that the playlist advances, the picture remains visible, and audio continues without silence, clipping, or a sudden channel-layout change. Check whether the displayed resolution and frame rate match your intended output. Observe bitrate and stream-health messages long enough to see whether the VPS connection is stable under the actual process, rather than relying solely on a speed test.
Also test what happens when the process or network is interrupted. If you are using a long-running service, decide how the process is supervised and how you will be alerted if it stops. FFmpeg documents a FIFO muxer example with recovery options for temporary network failures; evaluate those settings in your own setup instead of treating them as automatic, transparent recovery. YouTube Studio should be part of the test because reconnecting FFmpeg does not, on its own, prove that the live event is healthy.
Keep a short record of the test: protocol, source file, output codec, resolution, frame rate, audio settings, and the Studio messages you saw. If the next test changes several settings at once, it becomes harder to know which adjustment mattered. Once a test is stable, repeat it with the range of clips and transitions the channel will actually use before depending on it overnight.
Diagnose codec and playlist failures
When YouTube rejects or fails to display the stream, begin with the protocol rather than immediately converting everything. Check whether the FFmpeg output is RTMPS or an HLS delivery, then compare its codecs and audio against that protocol’s official settings. If you intended RTMPS but built HLS segments, or vice versa, changing HEVC to H.264 will not fix the protocol mismatch.
If Studio reports an unsupported format or no usable video, inspect the outgoing streams rather than just the source filename. Confirm that the output contains video and audio, that FFmpeg can decode every playlist entry, and that the output does not change in an unexpected way at a file boundary. Try one known-good clip using the same protocol and settings. If that works, compare it with a failing playlist entry to find differences in codec, pixel format, frame rate, dimensions, or audio.
If the image works but sound disappears between clips, inspect the audio streams and playlist transitions. Different source audio codecs or channel layouts can cause inconsistent output even while video continues. Normalising audio or selecting an output audio codec supported by the chosen protocol may be more relevant than touching the video codec. For RTMP/RTMPS, remember the AAC requirement for 5.1 audio; for HLS, check the separate supported audio list.
If the stream stutters or drops, inspect the outgoing bitrate, keyframe interval, network stability, and VPS process logs. A high-resolution output can exceed the sustained upload available on the route, while a process restart may leave the YouTube event in a different state than expected. Lower the target output only after identifying whether the limitation is network, encoding load, or a format mismatch. The guide to automatic FFmpeg restarts covers process recovery as a separate operational concern; restart logic cannot correct unsupported media settings.
If HLS fails, inspect the actual media playlist and segment delivery: duration, rolling window, segment count, transport stream format, HTTPS method, and byte-range behaviour. Do not diagnose an HLS failure merely by checking that a local playlist file exists. If RTMPS fails, verify the ingest URL and key in Studio, confirm secure RTMP output, and review Studio’s specific health messages before rebuilding the encode pipeline.
Once the channel, files, and test are ready, choose the operating arrangement that you can monitor and maintain.
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
Do all H.265 files need to be converted to H.264 for YouTube Live?
No. YouTube lists HEVC as supported for RTMP/RTMPS and HLS live ingest. Check the complete file and output path, then convert only when compatibility, consistency, or a specific output requirement calls for it.
Is an FFmpeg input playlist the same as YouTube HLS?
No. An FFmpeg input playlist tells FFmpeg which files to read; YouTube HLS ingest expects a rolling media playlist and compliant segments delivered according to its protocol guidance. Creating an input list does not create valid HLS ingest.
Should I choose RTMPS or HLS for a VPS playlist stream?
Choose based on the output you can configure and test. RTMPS is the simpler starting point for many continuous streams, and YouTube recommends RTMPS for secure transport; HLS has more specific playlist and segment delivery requirements.
How do I know the stream is ready to run overnight?
Test the real VPS output in YouTube Studio with representative video, audio, and file transitions. Review stream health and interruption behaviour, and arrange process monitoring so you can tell if the stream stops or becomes unhealthy.