A Linux computer can send a local video file to YouTube Live with FFmpeg, but the file must be read at real-time speed and the outgoing audio, video and container must match YouTube’s accepted settings. You also need to create the live event in YouTube Studio, copy its ingest details, and verify the incoming preview before you start the broadcast.
The command below is a construction template, not a tested or guaranteed recipe. The cited documentation describes YouTube’s workflow and FFmpeg’s command-line behaviour in general; it does not test a particular Linux distribution, FFmpeg build, video file, encoder, or internet connection.
Create the YouTube live event first
Open YouTube Studio and go to the Live Control Room. Create or schedule the stream rather than beginning with FFmpeg. YouTube’s live streaming setup guidance describes the current workflow, but labels and available options can change, so check the page shown in your own account.
Choose the stream’s title, visibility and schedule before you send anything. If the event is scheduled, YouTube can receive the encoder feed and show you a preview before the public broadcast begins. That separation is useful: you can test the file and connection without immediately exposing a faulty picture or silent soundtrack.
Select the encoder or streaming workflow in Live Control Room. YouTube will provide the server URL and stream key for that event. Do not invent an endpoint from an old tutorial. The exact URL supplied in the control room is the one to use, particularly if YouTube offers an RTMPS endpoint.
Before the first overnight test, use a short representative section of the intended programme. A devotional loop should include its normal vocals and music, while a news or study channel should include the sort of motion, text and audio that viewers will receive. YouTube recommends testing before the live stream and monitoring the stream health messages.
A file that plays correctly in a desktop player is not automatically suitable for live ingestion. A player can tolerate a format or timing detail that an encoder workflow cannot. The event setup gives you a place to identify those issues before you depend on the stream.
Copy the ingest URL and protect the key
Copy the server URL and stream key from Live Control Room into a private note. The key is a credential that tells YouTube which event should accept the incoming feed. Treat it like a password, not like ordinary configuration text.
YouTube’s stream key instructions explain how keys are managed and reset. Keep the key out of public shell examples, screenshots, shared documents, support tickets and public repositories. Be careful with shell history as well, because a command containing the key may be saved for later inspection.
A safer approach is to keep the two values in shell variables during a private session:
YOUTUBE_URL='paste-the-server-url-from-live-control-room'
STREAM_KEY='paste-the-key-from-live-control-room'
Do not publish those values with the command. The quoted placeholders above are only labels, not endpoints that FFmpeg can use. If you believe the key has been disclosed, reset it in Live Control Room and update the value used by your encoder.
Prefer RTMPS when the endpoint supplied by YouTube and your FFmpeg build support it. RTMPS is RTMP transported through TLS/SSL. YouTube’s RTMPS guidance says to copy the secure URL from Live Control Room rather than assuming that the ordinary RTMP address displayed by default is the right secure endpoint.
If an RTMPS connection fails, do not immediately replace it with an endpoint remembered from another guide. First check that the copied URL begins with rtmps, that any required port is present, and that the installed FFmpeg build supports the protocol and its TLS requirements.
Check FFmpeg and the local video file
Start by checking which FFmpeg executable is being used and which build it reports:
ffmpeg -version
This confirms that FFmpeg is installed, but it does not prove that the build has every encoder or protocol support you need. Builds supplied by different Linux distributions, package repositories or manually compiled installations may differ. The research and official documentation used for this guide do not test any particular distribution or build.
Inspect the input before selecting codecs or stream maps:
ffprobe -hide_banner input.mp4
Look for the video codec, width and height, frame rate, pixel format, audio codec, channel layout and duration. You can also ask FFmpeg to show the input without producing an output:
ffmpeg -hide_banner -i input.mp4
Read the output carefully. A file may contain more than one video or audio stream, subtitles, attachments or no audio at all. That affects how you map streams and whether a simple command will behave as intended.
FFmpeg’s command-line documentation explains that -i identifies an input, -map selects streams, and codec options normally apply to the next input or output according to their position. The FFmpeg command-line documentation is the primary reference for those rules.
Check that the Linux user running the command can read the file and that the path is correct. Spaces in a filename need quoting, for example:
ffprobe -hide_banner '/home/name/Videos/morning loop.mp4'
If you are building a 24/7 channel from one file, remember that a single FFmpeg process normally reaches the end of that file and exits. A file-to-live command is therefore different from a looping channel design. For a wider comparison of approaches, see how to stream a pre-recorded video as a YouTube live stream.
Configure real-time input and compatible output
For a local file, -re is one of the important options. FFmpeg documents it as reading the input at its native frame rate, equivalent to a read rate of one. Without real-time input, FFmpeg may process a file faster than its intended playback rate and send packets to the live output too quickly.
Put -re before the relevant file input:
ffmpeg -re -i input.mp4 ...
Do not apply a low read rate blindly to a live capture device or another already-live input. The purpose here is to pace a file for live output. FFmpeg’s official documentation describes the option and its limitations.
YouTube currently lists H.264, H.265 or HEVC, and AV1 as accepted video codecs for encoder ingestion. It lists AAC or MP3 for audio, constant bitrate encoding, and frame rates up to 60 frames per second. The current YouTube encoder settings page should be checked for the complete settings relevant to your chosen codec.
For a first test, H.264 with AAC is often easier to reason about because you can identify the encoder and audio settings explicitly. That does not mean it is the best choice for every Linux machine. H.265 or AV1 may be supported by YouTube but unavailable in your FFmpeg build, or too demanding for the available CPU.
YouTube’s current H.264 figures include these examples:
| Target | YouTube-listed minimum | YouTube-listed recommended value |
|---|---|---|
| 720p at 30 fps | 3 Mbps | 8 Mbps |
| 720p at 60 fps | 3 Mbps | 8 Mbps |
| 1080p at 30 fps | 5 Mbps | 14 Mbps |
| 1080p at 60 fps | 6 Mbps | 17 Mbps |
These figures are current page contents checked on 3 October 2026, not universal guarantees. They are published by YouTube, and the appropriate value also depends on the codec, movement in the video and what your upload connection can sustain. YouTube publishes separate figures for H.265 and AV1, so do not transfer the table to another codec without checking the current page.
A template for an H.264/AAC output might look like this:
ffmpeg -re -i 'input.mp4' \\
-map 0:v:0 -map 0:a:0 \\
-c:v libx264 -b:v 8M -maxrate 8M -bufsize 16M \\
-pix_fmt yuv420p -g 60 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "$YOUTUBE_URL/$STREAM_KEY"
Treat this as an example of how options are assembled, not as a verified command. It assumes that the FFmpeg build includes libx264, that the file has a first video and first audio stream, that the selected endpoint accepts the resulting FLV output, and that the -g 60 keyframe setting is appropriate for the actual frame rate. Those assumptions must be checked on your machine.
The example uses 8 Mbps video as an illustration for a 720p-style target. It does not resize the input, force a frame rate or prove that the file is 720p. If the source has a different resolution or frame rate, adjust the output deliberately and use the matching YouTube guidance. A two-second keyframe interval is recommended by YouTube and should not exceed four seconds, but the correct GOP value depends on the output frame rate. At 30 fps, 60 frames represents two seconds; at another frame rate, it represents something else.
-map 0:v:0 selects the first video stream and -map 0:a:0 selects the first audio stream. If the file has no audio, that second map will fail. If it has multiple audio tracks, the first one may not be the track you want. Removing or changing stream mapping without inspecting the file can produce a silent broadcast or an unexpected language track.
Stream copying can reduce CPU use, but it gives you less control. A command using -c:v copy -c:a copy avoids re-encoding only when the existing streams are suitable for the selected output. FFmpeg documents copy as a way to avoid re-encoding; compatibility with YouTube’s current settings still has to be verified. Re-encoding takes processing time but gives you control over codec, bitrate, pixel format, audio and keyframe behaviour.
For a detailed look at bitrate decisions for long-running loops, the 24/7 YouTube loop bitrate guide covers the trade-off between image quality and a connection that must keep up continuously.
Send the feed to YouTube Live
Once the event exists, the endpoint variables are private, the file has been inspected and the output choices are deliberate, run the command from a terminal. Keep the terminal open during the test so you can read FFmpeg’s warnings, frame count, speed, bitrate and reconnect or protocol errors.
A healthy file-based live process should generally report a speed close to real time rather than racing far ahead. The exact display depends on the file, filters, encoder and machine, so treat it as a diagnostic clue rather than a guarantee. If the process is consistently slower than real time, the encoder may not be able to keep up with the selected output.
Avoid copying the command from the terminal into a public issue or chat. It may contain the stream key, and logs can also expose the endpoint. If another person needs to help, replace the key and private URL with placeholders before sharing the command and include only the relevant error text.
If you need to stop a test, use the terminal’s normal interrupt control and then check Live Control Room. Stopping FFmpeg stops the incoming feed, but the YouTube event may still need to be ended or managed in the control room. Follow the event status shown there rather than assuming that closing the terminal completes every part of the broadcast workflow.
For a broader comparison between keeping a Linux machine running and using another operating arrangement, read how to run a 24/7 YouTube stream using a cloud desktop. A desktop-based setup may suit you when you need an interactive environment, while a direct FFmpeg process suits a person who wants to control the encoder from the command line.
Verify the preview and stream health
Do not judge success from the FFmpeg terminal alone. Return to Live Control Room and wait for YouTube to receive the feed. Check the preview image, audio indication, stream health messages and any warnings before clicking Go live.
Watch for the first representative section of the programme. Confirm that the picture is moving as expected, text is readable, the audio is present and the aspect ratio has not changed unexpectedly. A static frame may reveal that the file is not being read as expected, while a moving section can reveal dropped frames or an encoder that cannot maintain its target rate.
YouTube’s encoder guidance recommends testing with representative sound and movement, monitoring stream health and reviewing messages. These checks matter more than whether the command returned without an immediate error. A process can remain open while the wrong stream is selected, audio is absent, or the upload connection is too weak for the chosen bitrate.
Compare the observed health with the quality you intended. If the connection cannot sustain the selected bitrate, lower the resolution or bitrate and test again. YouTube’s published minimum and recommended values guide the choice, but neither value guarantees a particular result on your connection.
If the stream is scheduled, wait for the preview before starting the public event. When you finish, stop sending content and end the stream in Live Control Room as appropriate. YouTube says streams under 12 hours are automatically archived, but you should still confirm the archive and event status in your account rather than relying on an assumption.
Troubleshoot the common failure points
YouTube receives nothing. Recheck the complete server URL and stream key character by character. Confirm that FFmpeg is actually running the command you intended, that the file is readable, and that the event is the one associated with the copied key. If the key may have been exposed, reset it and update the private variable.
RTMPS reports an SSL error or times out. Confirm that the URL copied from Live Control Room really uses rtmps, not rtmp. Check whether the endpoint includes the required port, whether the FFmpeg build supports RTMPS, and whether the local network blocks the connection. Use YouTube’s current secure-ingest instructions rather than constructing a replacement URL from memory.
The command reports an unknown encoder. The name in the command must exist in your FFmpeg build. List available encoders with ffmpeg -encoders, then choose a supported encoder and confirm that its output is suitable for YouTube. Installing a different package may change what is available, but this guide does not test any particular package or distribution.
The command fails on stream mapping. Run ffprobe again and inspect the actual stream indexes. A file without audio cannot satisfy -map 0:a:0; a file with several tracks may need a different map. You can also begin with a simpler command, then add explicit mapping once you understand the input.
The stream is silent or has the wrong audio. Check the selected audio stream, codec and sample rate. YouTube lists AAC and MP3 as accepted audio choices, and its current recommendations include 44.1 kHz stereo audio and 128 kbps stereo audio. Treat those as settings to consider, not as proof that every input should be forced into them without inspection.
The picture stutters or the health warning returns. Check both encoder speed and upload capacity. A CPU that cannot encode in real time and a connection that cannot sustain the selected bitrate can look similar from the viewer’s perspective. Test at a lower resolution or bitrate, include representative motion, and monitor the result again.
The process ends when the file ends. That is normal for a single local file unless you have designed a loop or playlist workflow. Repeating files introduces its own concerns, including transitions, timestamps and differing frame rates. If you are combining files, see how to stream a YouTube playlist with FFmpeg when videos have different frame rates.
If your aim is an unattended channel rather than a supervised Linux test, StreamNeo removes the need to leave your computer running by taking an uploaded video, the YouTube stream key and the live broadcast workflow into one managed process, with automatic monitoring and restarting when the feed drops.
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 FFmpeg stream any video file directly to YouTube Live?
No. The file must contain streams that your FFmpeg build can read, and the outgoing codecs, bitrate, frame rate, keyframes, audio and container must be suitable for the selected YouTube ingest workflow. Inspect the file first and re-encode when copying would not provide compatible output.
Should I use RTMP or RTMPS?
Prefer the RTMPS endpoint supplied by YouTube when your FFmpeg build and network support it. RTMPS adds TLS/SSL transport, but you should copy the exact URL from Live Control Room rather than changing an ordinary RTMP URL yourself.
Why is -re important for a local file?
A file can be decoded faster than real time, while a live service expects packets to arrive at a playback-like rate. FFmpeg documents -re for reading a file at its native frame rate, but it should not be applied blindly to already-live inputs.
Does this command create a 24/7 channel?
Not by itself. A single file normally ends and the FFmpeg process exits, so continuous broadcasting requires a deliberate looping or playlist arrangement and a machine or service that remains available. Test the exact workflow, file and connection before relying on it overnight.