You can stream a prerecorded video from a Linux server to YouTube without OBS by using FFmpeg as the command-line encoder. FFmpeg reads the file in real time and sends the encoded output to the stream URL and key supplied by YouTube Live Control Room.
The exact command depends on your media file, installed FFmpeg build, available upload capacity and YouTube’s current encoder guidance. The command in this guide is a template, not a tested universal command, so verify each part on your own server before relying on it overnight.
What you need besides OBS
You need a Linux machine that can read the video file, run an FFmpeg build with the required input, output and codec support, and maintain an upload connection for the duration of the broadcast. A local server, rented machine or other Linux host can work, but the practical limits are different for each one.
You also need:
- A YouTube channel that is able to use live streaming.
- A prerecorded video with a known file path.
- Access to YouTube Studio and Live Control Room.
- FFmpeg installed on the Linux host.
- Enough upload capacity for the selected video bitrate, with room for connection variation.
- Permission to broadcast the video and its audio.
OBS is not required because it is only one way to prepare and publish live video. FFmpeg can perform the file-to-network part directly. The important distinction is that YouTube still receives a live encoder connection even though the source is a finished file.
A Linux server does not automatically make a stream reliable. The host can run out of disk space, lose its network connection, lack a suitable encoder, or stop when the process exits. Process supervision, looping and recovery are separate implementation choices. They are not established merely because FFmpeg can send one file to an RTMP endpoint.
If your aim is to switch off your personal computer rather than operate a server yourself, read how to keep a YouTube stream live after switching off the PC. That is a different operating model from running FFmpeg on a machine you maintain.
Create the YouTube stream and retrieve its ingest details
Open YouTube Studio, enter Live Control Room and create or select the broadcast. Choose the encoder workflow rather than treating the video as a normal upload. YouTube will show the stream URL and stream key associated with that stream.
Copy both values from the current Live Control Room page. Do not assume that an endpoint or key found in an old tutorial applies to your channel. The URL and key are stream-specific details provided by YouTube, and the key should be treated as a credential.
You can use a scheduled broadcast or start a stream according to the options shown in your account. For a scheduled broadcast, YouTube’s encoder setup instructions explain that you start sending the encoder output, wait for the preview, and then confirm the broadcast in Live Control Room. The exact buttons can change, so follow the current page rather than an old screenshot.
Keep the Live Control Room tab open while testing. It is where you can see whether YouTube has received the signal, whether the preview is visible and whether the stream health indicators show a problem. A successful local FFmpeg process does not by itself prove that viewers are receiving a healthy broadcast.
YouTube can archive streams under 12 hours automatically, according to its current help guidance. That is a lifecycle rule, not a promise that a file will play continuously for that period. If the encoder stops sending content, the stream can end or require action in Live Control Room.
The stream key deserves particular care. Never paste a real key into an article, public issue, shared screenshot, source repository or command that will be copied into a public shell history. If you believe it has been exposed, use YouTube’s controls to rotate or reset it before starting another broadcast.
Prepare the prerecorded video on Linux
First identify the actual file path and inspect the file rather than guessing its properties. You need to know whether it contains video, audio, or both, and whether the installed FFmpeg build can decode the formats used by the file.
A common inspection command is:
ffprobe /path/to/your-video.mp4
This only inspects the file. It does not test YouTube ingestion and does not tell you whether your server has enough upload capacity. Look for the video codec, audio codec, frame rate, dimensions, duration and stream count.
A file that plays in a desktop media player may still need conversion for a predictable live encoder workflow. For example, a file may have an unusual frame rate, no audio stream, variable timing or a codec that your FFmpeg build can decode but not encode. YouTube’s encoder guidance currently supports H.264, H.265 and AV1 video for RTMP and RTMPS, but support on the platform does not mean your particular FFmpeg installation can produce that codec.
Check the available encoders before writing a command:
ffmpeg -encoders
You can filter the output if you already know which encoder you want to investigate:
ffmpeg -encoders | grep -E '264|265|av1|aac|mp3'
The names and capabilities can differ between Linux distributions and builds. A software H.264 encoder may be available when a hardware encoder is not, or the reverse. Do not copy an encoder name from another server without checking locally.
The source file also needs to fit the intended broadcast. If you are sending a 1080p file at 30 frames per second, YouTube’s current guidance lists 5 Mbps as the recommended H.264 video bitrate for that mode. For 1080p at 60 frames per second, the listed recommendation is 6 Mbps. Other resolutions, frame rates and codecs have different guidance, so use YouTube’s current encoder settings and bitrate table rather than extrapolating from those two examples.
YouTube recommends constant bitrate encoding, a keyframe frequency of two seconds and no more than four seconds. It also lists AAC or MP3 audio, with stereo audio guidance of 44.1 kHz and 128 kbps. Treat these as platform settings to match where your file and FFmpeg build allow it, not as proof that one command is suitable for every source.
Check your upload connection from the same host that will run FFmpeg. YouTube’s guidance says, “We recommend running a speed test to test your upload bitrate.” Select a video bitrate that leaves practical headroom instead of using the entire measured upload rate.
Configure FFmpeg for real-time file playout
The key FFmpeg option for a prerecorded live stream is -re. It tells FFmpeg to read the input at approximately its native playback rate instead of processing the file as quickly as the machine can manage. Without real-time pacing, a short file can be pushed towards YouTube much faster than it should be for live playout.
FFmpeg’s protocol documentation shows the general pattern:
ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream
That is a generic protocol example from FFmpeg, not a tested YouTube command and not a complete encoder configuration. YouTube’s ingest URL, key, codecs, bitrate, frame rate and audio settings must be supplied separately.
A more explicit template might look like this:
ffmpeg -re -i "/path/to/your-video.mp4" \
-c:v libx264 -b:v 5000k -maxrate 5000k -bufsize 10000k \
-r 30 -g 60 \
-c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv "REPLACE_WITH_YOUR_YOUTUBE_RTMPS_URL_AND_KEY"
Do not run this by replacing only the final placeholder and assuming it is correct. The template uses libx264, but that encoder may not be installed. It also assumes that 1080p at 30 frames per second is the intended output, that the input can be converted to those settings, and that the URL and key format supplied by Live Control Room can be used in the final argument.
The -b:v, -maxrate and -bufsize values are implementation choices intended to illustrate a constant-rate configuration. The -g 60 value corresponds to a two-second keyframe interval at 30 frames per second, but the relationship changes if you select another frame rate. Confirm the resulting output rather than treating the line as a guarantee.
If the source has no usable audio, the audio options will need a different approach. If it has several audio or video streams, you may need explicit mapping. If the video is portrait, you may need to scale or pad it rather than allowing an unsuitable output shape. If the source already matches your target settings, re-encoding may still be unnecessary, but that decision depends on the file and the encoder’s ability to pass it through in a form YouTube accepts.
For a more specialised comparison of high-resolution command-line settings, see how to use FFmpeg to stream 4K 60fps to YouTube Live. Do not apply its settings to a smaller or slower source without checking the upload and encoding cost.
Connect to YouTube with RTMPS
RTMPS is the encrypted extension of RTMP and is the preferred secure ingestion option where YouTube provides it. YouTube’s RTMPS guidance says to retrieve the stream URL from Live Control Room rather than relying on a fixed address.
Google’s developer documentation describes the connection as using the rtmps protocol, a valid server and path, and port 443. That means the URL shown by YouTube matters. Do not manually change a working rtmps URL to an old rtmp form just because a command from another guide uses it.
The final FFmpeg output argument normally combines the endpoint and the stream key in the form YouTube expects. Since the exact value is channel-specific, show it only as a placeholder in scripts and notes:
"rtmps://YOUR_YOUTUBE_SERVER_PATH/YOUR_PRIVATE_STREAM_KEY"
This is a shape for illustrating where the value goes, not a universal endpoint. Copy the complete value or the separate URL and key exactly as displayed in your own Live Control Room, following that page’s instructions for combining them.
A TLS or connection error can have several causes. Check that you copied the current URL, that the protocol is rtmps, that the host permits outbound connections on port 443, and that the FFmpeg build includes the required protocol and TLS support. You can inspect FFmpeg’s protocol list with:
ffmpeg -protocols
The presence of a protocol name does not prove that the entire YouTube workflow will work on your machine. It only helps you identify whether the installed build advertises the relevant support.
If a firewall, hosting provider or network policy blocks outbound traffic, changing video settings will not solve the problem. Test connectivity from the actual Linux host, not from your home computer on a different network.
Protect the stream key and start the encoder
The safest practical rule is to keep the stream key out of the command line where possible, because command-line arguments can be visible to other users through process inspection and may remain in shell history. The exact method depends on your FFmpeg build and the script or service manager you use.
At minimum, restrict access to any script containing the key, avoid committing it to version control and disable shell history for the session in which you handle it. A private environment file with suitable permissions can be preferable to a world-readable script, but do not assume that every environment or log system will keep secrets out of its output.
Use a placeholder while building the command:
YOUTUBE_INGEST='REPLACE_WITH_THE_VALUE_FROM_LIVE_CONTROL_ROOM'
ffmpeg -re -i "/path/to/your-video.mp4" \
-c:v libx264 -b:v 5000k -maxrate 5000k -bufsize 10000k \
-r 30 -g 60 -c:a aac -b:a 128k -ar 44100 -ac 2 \
-f flv "$YOUTUBE_INGEST"
This remains an illustrative template. It has not been validated against your Linux distribution, FFmpeg build, file or YouTube account. Replace the encoder and settings only after checking local support and the current YouTube table.
Watch the terminal output as FFmpeg starts. It should identify the input streams, selected encoders, output format and progress. An immediate exit usually points to a local problem such as a missing file, unsupported encoder, invalid option or inability to open the output. A process that continues running can still have an unhealthy or rejected connection, so use Live Control Room as the second check.
For an always-on channel, decide what should happen when the file reaches its end. A single-file command normally reaches end of input and exits. Looping, concatenating several files, supervising the process and reconnecting after a network failure require additional design and testing. They can also introduce a visible pause, timestamp discontinuity or audio problem, so do not promise seamless continuous playback without testing the exact media set.
If managing a server is the part that causes the most operational trouble, StreamNeo removes the need to leave your own machine running by taking an uploaded video, your YouTube stream details and the ongoing broadcast process into one managed workflow. You still need to check your content rights and YouTube’s current requirements, but you do not have to maintain an FFmpeg process on your personal computer.
Verify the preview and troubleshoot failures
Start with a short, representative test rather than the quietest or simplest section of the file. Include the sort of motion, speech, music and transitions that viewers will actually receive. YouTube recommends testing with representative video and audio and monitoring stream health.
In Live Control Room, check for a visible preview and inspect the stream health messages. Also watch the FFmpeg terminal for repeated warnings, dropped output, encoder errors or a progress rate that does not correspond to normal playback. The two views answer different questions: FFmpeg shows what the local process is doing, while YouTube shows what the platform is receiving.
| Symptom | What to check first | Likely direction |
|---|---|---|
| FFmpeg exits immediately | File path, permissions, input format and option spelling | Fix the local input or command before changing YouTube settings |
| Encoder not found | Output of ffmpeg -encoders |
Select an encoder present in this build or install a suitable build |
| YouTube shows no preview | URL, key, RTMPS support and outbound port 443 | Re-copy the current ingest details and check the host network |
| Video arrives but audio is missing | Input audio stream, mapping and AAC or MP3 support | Inspect the file with ffprobe and review the audio options |
| Stream health fluctuates | Upload capacity, bitrate and host network | Reduce the selected quality or improve the connection after testing |
| The stream ends when the file ends | Normal end-of-input behaviour | Add a separately tested playlist or loop design if appropriate |
| Picture stutters or timing looks wrong | Frame rate, keyframe interval and source timing | Re-encode to a stable target and compare with YouTube guidance |
If YouTube reports an invalid key, retrieve the value again rather than editing it character by character. If you have exposed the key while troubleshooting, reset it before continuing. A key that worked yesterday may no longer be the active key for the selected broadcast.
If the preview works but the stream health is poor, do not start by increasing the bitrate. Compare the chosen bitrate with the host’s measured upload capacity, check whether another process is using the connection and confirm that the server is not throttling the encoder. YouTube automatically creates viewer outputs from the live input, but that does not remove the need to send a stable source.
For streams that skip from one recording to the next, inspect timestamps, file compatibility and the hand-off method rather than assuming the network is at fault. The guide on fixing a YouTube live stream that skips podcast episodes covers that class of problem separately.
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 a video file to YouTube without OBS?
Yes. FFmpeg can read a local file in real time with -re and send the encoded output to an RTMP or RTMPS endpoint. You still need the stream URL and key from YouTube Live Control Room, plus an FFmpeg build that supports the chosen input, codecs and protocol.
Is the stream key the same for every YouTube broadcast?
Do not assume that it is. Retrieve the current value from the stream selected in Live Control Room and keep it private, because anyone who obtains it may be able to send content to that ingest configuration.
Why does the example command not work unchanged?
It is a template, not a tested command for every Linux distribution or media file. Encoder names, codec support, input streams, frame rates, output settings and the exact YouTube ingest value all vary, so inspect your file and FFmpeg build before running it.
Will one FFmpeg command keep a channel live indefinitely?
No. A single file normally ends when FFmpeg reaches its end, and a network or process failure can also stop the broadcast. Looping, playlist handling, supervision and recovery need separate implementation and testing, and none guarantees continuous playback.