To stream a prerecorded video to YouTube Live from Ubuntu, enable live streaming for your channel, create or schedule an event, then send a compatible video feed from FFmpeg to the event’s ingest address. YouTube’s Live Control Room provides the RTMPS address and stream key; for a scheduled event, you still need to check the preview and start the event there.
You can test the workflow with a short local file before relying on it for a long broadcast. The settings and command below are starting points, not a guarantee: check YouTube’s current encoder guidance, your installed FFmpeg capabilities, and the actual file and connection you intend to use.
Check that your channel can go live
Open YouTube Studio and check that live streaming is available for your channel. YouTube’s eligibility guidance says the channel must be verified and must not have had live-streaming restrictions in the previous 90 days. If the feature has only just been enabled, allow for YouTube’s activation process rather than assuming that a working FFmpeg installation can bypass account eligibility. See YouTube’s live streaming requirements for the current conditions.
Check the account you intend to use, not just another channel under the same Google login. A restriction on one channel does not tell you the status of another. Resolve any verification or access issue in YouTube Studio before spending time diagnosing a connection that cannot yet be accepted.
Also decide whether you need a public event, an unlisted test, or a scheduled broadcast. An unlisted event can help you check the viewing experience without announcing it broadly, but anyone with its link may be able to watch. A scheduled event gives you a preview stage and a place to start the broadcast manually; it does not mean that sending data automatically makes the event public and live.
Create the event and copy its encoder details
In YouTube Studio, open Live Control Room and create a stream or schedule one. Follow the current on-screen choices for the event’s title, privacy and timing. The exact layout can change, so use the controls shown in your account rather than relying on a screenshot from an older guide.
For an encoder-based stream, YouTube supplies a stream URL and a stream key. Copy the RTMPS address where the interface offers it, and make sure the key belongs to this event or the selected reusable stream configuration. The URL tells FFmpeg where to send the feed; the key identifies the stream. A key is a credential, not a public identifier.
Treat it as you would a password. Do not put the real key in a published tutorial, a shared script, a screenshot, a support post or a public log. Shell commands may be saved in shell history, so pasting a secret directly into a command is not automatically private. Use a protected approach appropriate to your environment, and avoid sharing output that might include the complete destination. If you believe a key has been exposed, reset it using YouTube’s controls and update the encoder configuration.
If you are new to the event workflow, this guide to checking YouTube Live Control Room when an Indian VPS shows no data covers the distinction between sending an encoder feed and seeing that feed accepted. The same basic checks apply from Ubuntu on a local connection.
Install and verify FFmpeg on Ubuntu
Ubuntu package availability and build options can vary by release and repository. Install FFmpeg using the package source you normally trust, then check what is actually present rather than assuming every build includes the same codecs or network protocols. A package installation may be enough for a straightforward test, but the installed version and enabled features matter.
Run these checks in a terminal:
ffmpeg -version
ffmpeg -protocols
ffmpeg -encoders
ffmpeg -muxers
Look for the ability to use the RTMPS protocol, an FLV muxer, and the video and audio encoders you plan to select. For the H.264 example later in this article, check whether libx264 appears in the available encoders. If it does not, do not copy the command unchanged: choose an encoder supported by your build and confirm that its output suits YouTube’s current guidance, or install a suitable FFmpeg build from a source you trust.
The command-line tool can also inspect an input without transmitting it. ffmpeg -i input.mp4 prints the detected streams and file properties, then may exit with a non-zero status because no output was requested. That is useful for inspection; it does not by itself mean that the file is corrupt. For more on choosing a local process or a different way to keep a channel running, see OBS versus FFmpeg for the cost and workload of a 24/7 stream.
Prepare and inspect the prerecorded video
Start with a copy of the file you intend to broadcast. Check its duration, resolution, frame rate, video codec, audio codec, and whether it contains one or more audio tracks. In particular, confirm that the chosen audio track is the one you want viewers to hear. A file that plays correctly in a desktop player can still have an unexpected frame rate, no audio stream, or a codec your FFmpeg build cannot decode.
For a quick inspection, run:
ffmpeg -i input.mp4
Read the input information printed by FFmpeg. Do not infer a frame rate or audio layout from a filename. If the file has multiple tracks, use explicit stream mapping in the final command so the intended audio and video are sent. If it has subtitles, multiple language tracks or unusual timing, decide whether those should be included or left out before the live test.
Make a short test copy or choose a representative section that includes the same sort of motion and sound as the planned broadcast. A static title card is a poor test for a music video with moving backgrounds; a silent opening is a poor test for a programme whose narration starts later. YouTube advises testing representative audio and movement and checking that your upload connection can sustain the feed. See its live encoder settings and bitrate guidance before settling on output settings.
If your source already has suitable codecs, FFmpeg may be able to pass them through without re-encoding. That can reduce local processing, but it leaves less room to correct an incompatible frame rate, resolution or audio format. Re-encoding gives you control, at the cost of computer workload and the possibility of a conversion problem. Test the actual path you plan to use, rather than assuming that either approach is best for every file.
Choose RTMPS and encoder settings
Use the RTMPS URL shown in your Live Control Room, not a hostname copied from an example. YouTube describes RTMPS as its recommended encrypted ingest route. Its RTMPS instructions explain how to expose and copy the secure address. RTMPS is RTMP over TLS/SSL; the URL’s scheme and server both matter, and FFmpeg must support the protocol.
YouTube’s current encoder guidance lists H.264, H.265/HEVC and AV1 video, AAC or MP3 audio for RTMP/RTMPS, constant bitrate rate control, and a recommended keyframe interval of two seconds, with no interval longer than four seconds. It lists frame rates up to 60 fps and Rec. 709 for SDR colour. For stereo audio it recommends a 44.1 kHz sample rate and 128 Kbps; 5.1 audio is supported over RTMP/RTMPS only with AAC, and YouTube lists 48 kHz and 384 Kbps for that configuration. These are ingest recommendations, not a promise that a particular input or encoder will behave as intended.
Bitrate depends on output resolution, frame rate and codec. For H.264, YouTube lists a recommended range of 5–14 Mbps for 1080p at 30 fps and 6–17 Mbps for 1080p at 60 fps; its guidance also lists 3–8 Mbps for 720p at either 30 or 60 fps. Check the current YouTube table for the precise minimum and recommended settings for your chosen combination before encoding. A connection that cannot sustain the selected output can result in an unstable feed, so test upload capacity and use a resolution and bitrate that your connection can support.
The following is an illustrative command structure for a 30 fps H.264 input and stereo audio. It is not a tested command for every Ubuntu build or source file. Replace the placeholders, choose a bitrate within the applicable current YouTube guidance, and adjust stream mapping, frame-rate handling and audio options for your input. The sample uses a 60-frame keyframe interval, which is two seconds at 30 fps; for a different output frame rate, change it to preserve that interval. Omit -stream_loop -1 if you want one-pass playback.
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast -b:v 6000k -maxrate 6000k -bufsize 12000k \
-g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 44100 \
-f flv 'rtmps://CURRENT_INGEST_URL/STREAM_KEY'
Every value in that command needs to match your actual case. In particular, 6000k is an example value, not a universal YouTube setting; confirm that the selected rate is appropriate for the output you have chosen. -re reads the local file at its intended playback rate instead of sending it as fast as the computer can process it. -f flv selects the container expected by this common RTMP/RTMPS workflow. The URL shown is a placeholder, not a real endpoint, and the key must not be exposed in an example or shared command.
Where possible, keep secrets out of shell history and logs by using a protected method suitable for your setup. Do not assume that moving a command into a script makes it secure: check its file permissions, who can read it, and whether diagnostic output might reveal the key. For a managed long-running process, also consider how credentials are stored and who has access before you leave it unattended.
Start the feed and verify it in Live Control Room
Before an important broadcast, start with a test event and allow time to inspect both the encoder output and YouTube’s preview. YouTube recommends setting up encoders well ahead of an event and starting the encoder at least 15 minutes before the scheduled time. Treat that as operational preparation, not a guarantee against an internet or encoding failure.
Run FFmpeg and watch its output for connection errors, encoding errors and progress. Then look at the correct event in Live Control Room. For a scheduled stream, wait until YouTube displays the incoming preview and inspect its stream-health messages. When you are satisfied, click Go live in the control room. Starting FFmpeg alone does not necessarily make a scheduled event public or live.
Check the picture and sound from the viewer’s perspective too. Confirm that the video is not frozen or stretched, that the intended audio is present and at a sensible level, and that the watch page is accessible in the way you intended. YouTube recommends monitoring quality during the broadcast; keep the control room visible or arrange for someone to check it rather than treating a running process as proof of a healthy stream.
When the broadcast is finished, end the event in Live Control Room where applicable and stop FFmpeg. YouTube says streams under 12 hours are automatically archived; do not assume the same archive outcome for a longer session. If you need a recording, retain your source file and verify the event’s archive rather than relying on an assumption about its availability.
A local Ubuntu process depends on that computer, its power, network and the FFmpeg process remaining available. For a one-off event or a test, that may be exactly the control you want. For a channel that must continue overnight with your own computer switched off, StreamNeo can remove the need to keep this local encoder running: you upload the video and provide the YouTube stream key, then the broadcast runs from the cloud and is monitored and restarted if it drops. It is YouTube-only, so keep the local FFmpeg path if you want to manage the encoder yourself or need another workflow.
Looping and common checks
To repeat a file continuously, -stream_loop -1 tells FFmpeg to loop the input indefinitely. Use that only when repeating the same programme is intended. Check the transition from the end back to the beginning in a test: a hard cut, silence, repeated title card or abrupt audio change may be acceptable for a simple ambience station but distracting for a narrated programme. If the video and audio have different lengths or unusual timestamps, inspect the loop before scheduling a long event.
For one-pass playback, omit the loop option. Plan what should happen when the file ends and stop or transition the event accordingly. A scheduled event and a repeated encoder input solve different problems: scheduling controls the YouTube event, while looping controls what FFmpeg reads from the local file.
If Live Control Room reports no data or shows no preview, check the fundamentals in this order:
- Confirm FFmpeg is still running and producing output, and that you selected the intended event.
- Check that the RTMPS address and key belong to that event. Do not paste the key into a message while asking for help.
- Verify that the URL uses RTMPS, not RTMP, and that the installed build includes RTMPS support. If the address appears correct but a TLS connection fails, recheck the secure URL and consult YouTube’s current instructions; its guidance mentions port 443 as a possible route to try where needed.
- Inspect the control room’s stream-health messages alongside FFmpeg’s output. A process can run while failing to deliver a usable feed.
If the stream connects but buffers or drops, check the available upload capacity and compare it with the output bitrate. Try a lower supported resolution or bitrate, then repeat the representative test. Do not fix a connection problem by increasing bitrate without checking the available capacity. A change can also affect picture quality, so verify the result in the preview and on the watch page.
If video arrives without audio, inspect the input stream list and the command’s mapping and audio options. Confirm that the file contains the intended track, that FFmpeg can decode it, and that the output codec and sample rate match YouTube’s current guidance. For audio that arrives but sounds distorted or too quiet, listen to a test from the viewer side and adjust the source or conversion before the public event.
For a continuous channel, the choice is not only about codec settings. A local FFmpeg job gives you direct control but requires an available, powered computer and a way to notice failures. A cloud service removes that local-computer requirement but adds a different service and account workflow. Standalone encoding hardware is another possible deployment, but it is not required for this software procedure. The Docker and FFmpeg always-on guide is useful if you want to explore a self-managed persistent process; it does not remove the need to monitor the event and protect the key.
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 I send a prerecorded file to YouTube Live with FFmpeg?
Yes. FFmpeg can read a local file in real time and send its encoded feed to the stream URL and key supplied by YouTube. You still need an eligible channel, a compatible FFmpeg build and a Live Control Room check; for a scheduled stream, start the event there after reviewing the preview.
How do I loop a video continuously?
Use FFmpeg’s -stream_loop -1 input option when repeating the same file is intended. Test the transition at the end of the file, including the audio, and omit the option when the file should play only once.
Why is there no preview in Live Control Room?
Check that FFmpeg is active, that the stream URL and key correspond to the selected event, and that your build supports RTMPS. Read both FFmpeg’s output and YouTube’s stream-health messages; do not share the key when seeking help.
Does FFmpeg need to keep running for the broadcast?
Yes, for this local workflow FFmpeg must continue sending the feed, and the Ubuntu computer and its network must remain available. If you need the channel to keep running with your computer off, consider a cloud-based operating workflow instead, and verify how it handles monitoring and recovery.