Create a YouTube Live event, copy its server URL and stream key, then send a real-time FFmpeg output to that destination. For a straightforward starting point, use H.264 video, AAC audio and FLV output over RTMPS.
That command is a starting profile, not a guarantee that every file or connection will work. You need to match the output to your source, available upload capacity and YouTube's current recommendations, then test the complete path before the real broadcast.
Before you begin
You need four things: a local video file, an FFmpeg installation that includes the encoders and protocols you plan to use, a YouTube channel eligible for live streaming, and a stable upload connection. Keep the original file unchanged so that you can return to it if you need to adjust the output.
YouTube's live-stream eligibility guidance says that a channel must be verified, must not have had live-streaming restrictions during the previous 90 days, and that the person live streaming must be at least 16. These are YouTube requirements, not FFmpeg requirements. Check YouTube's current live-streaming eligibility guidance before troubleshooting a command. The page was checked in October 2026.
You should also know what the file contains. A file intended for a devotional loop may have one video stream and one audio stream. A screen recording may contain unusual frame-rate behaviour or no audio at all. A local-news loop may have several audio tracks. FFmpeg can handle many combinations, but you should not assume that the first video and audio stream are the right ones.
If your goal is an unattended channel rather than a one-off broadcast, decide where the computer will run for the full duration. A desktop that sleeps, loses its network connection or is used for other demanding work is a different operating choice from a managed cloud workflow. The practical difference is covered in how to stream pre-recorded video to YouTube Live from a cloud server, while this guide concentrates on the local FFmpeg path.
Prepare the local file and FFmpeg
Start by inspecting the input rather than guessing its properties. One common way is to run ffprobe, which is included with many FFmpeg distributions:
ffprobe "input.mp4"
Look for the video codec, resolution, frame rate, duration and pixel format. For audio, check whether a track exists, its channel layout and its sample rate. You do not need to understand every line of the output. The important question is whether the source can be passed through as-is or needs to be converted into a YouTube-compatible output.
A file can be perfectly suitable for local playback and still be a poor live input. Variable frame rate, unusual audio layouts, missing audio, very high resolution or a codec not enabled in your FFmpeg build can all change the command you need. If the file has no audio and silence is acceptable, you may need to add a silent audio source rather than asking FFmpeg to map an audio stream that does not exist.
Confirm that FFmpeg can encode H.264 and AAC on the machine where you will run it:
ffmpeg -encoders | grep -E 'libx264|aac'
The exact command for filtering output differs between operating systems. On Windows, you can inspect the full encoder list without grep, or use the equivalent search in your terminal. If libx264 is absent, another H.264 encoder may be available, but its options and performance can differ. Do not copy a command built for one encoder into a different FFmpeg build without checking the supported options.
The -re option matters for a file-to-live workflow. It tells FFmpeg to read the input at approximately its normal playback rate rather than processing the file as quickly as the computer can manage. Without real-time pacing, a short file can be pushed towards YouTube too quickly, which is not the same as sending a live programme.
For a single file, decide what should happen at the end. FFmpeg normally exits when the input ends. That may be correct for a scheduled event, but it does not create an endless channel. Repeating a file requires a loop strategy and a plan for continuity at the join. A devotional or ambience stream may need a carefully prepared longer programme instead, because a visible jump or repeated audio tail can be distracting.
Create a YouTube Live event
Open YouTube Studio and use the live-stream workflow to create or select the event. Set the visibility and schedule according to the test or broadcast you are preparing. For the first attempt, use a private or unlisted event where that fits your needs, so you can inspect the result without treating an untested command as a public launch.
YouTube's encoder instructions describe entering the YouTube Live server URL and stream key into the encoder. The event is therefore not addressed by a generic URL you find in an old tutorial. The destination belongs to the event and may be presented in a form that depends on YouTube's current interface.
If the channel has not used live streaming recently, do not leave eligibility checks until the moment you are ready to start. YouTube may require verification or impose a waiting period in some circumstances. The current official help page is the right place to check this, because eligibility and interface details can change independently of FFmpeg.
For a channel that will run a repeated file, think about the event's title, description and visibility before sending the feed. The technical command can be correct while the wrong event is selected in Studio. Keep a short written record of which local file belongs to which event, but never include the actual stream key in that record.
Copy the server URL and stream key
In the event's encoder settings, copy the server URL and stream key exactly as shown. You may see an ingestion address and a separate stream name or key. FFmpeg's final destination commonly combines the endpoint and key, but the exact joining format depends on the values YouTube provides and the interface you are using.
The YouTube Live API documentation describes separate ingestion-address and stream-name fields. That is useful background, but the event's own displayed values are authoritative for your setup. If YouTube gives you a complete RTMPS address, use that address as supplied. If it gives a host, application path and stream key separately, assemble them only in the format expected by the encoder.
YouTube describes stream keys as being like the stream's password and address. Treat one as a credential. Do not paste a real key into a public tutorial, a forum question, a screenshot, a shared shell history file or an unredacted log. The key may be visible to other local users or tools when supplied as a command-line argument, so avoid running it in a shared session.
If a key is exposed, reset it in YouTube Studio and update the encoder with the replacement. Do not spend time testing a key that has already been published. You can read YouTube's guidance on managing live-stream settings for the current key-handling controls.
A safe working habit is to keep the command in a private local note with a placeholder such as <STREAM_KEY>, and insert the real value only when you run the test. Before sharing any diagnostic output, replace the host, path and key with redacted values.
Choose output settings for the source and connection
The familiar H.264, AAC and FLV combination is useful because it creates a broadly understood RTMP-style output. H.264 is a common video choice for YouTube ingestion, AAC is a common audio choice, and FLV is the output container typically used with RTMP or RTMPS. This combination is not a rule that every source must follow, nor does it remove the need to select a suitable bitrate.
YouTube's current encoder guidance lists H.264, H.265 and AV1 video, and AAC or MP3 audio, among its supported choices. For a simple FFmpeg workflow, H.264 and AAC are often easier to adapt because the required encoders and examples are widely available. If your machine has a verified alternative and a reason to use it, consult YouTube's current table rather than treating H.264 as mandatory.
YouTube recommends constant bitrate and a keyframe interval of two seconds, not exceeding four seconds. The interval is expressed through the GOP size in FFmpeg. A value of -g 60 represents two seconds only when the output is 30 frames per second. At 25 fps, a value close to 50 represents two seconds; at 60 fps, a value close to 120 does. The correct value depends on the frame rate you actually output.
YouTube also recommends progressive scanning, square pixels, 44.1 kHz stereo audio, 128 kbps stereo audio and Rec. 709 for SDR in its advanced guidance. These are useful targets when you are converting a source rather than passing through a compatible stream. They do not mean that every source should be forced into the same resolution or frame rate.
Choose a bitrate from YouTube's row for the output codec, resolution and frame rate. As listed on YouTube's encoder settings page checked in October 2026, its H.264 guidance gives 3 Mbps as a minimum and 8 Mbps as a recommended figure for 720p30, and 5 Mbps as a minimum and 14 Mbps as a recommended figure for 1080p30. These are ingestion recommendations, not a promise that your connection will sustain them or that a higher setting will improve a lower-quality source.
| Output profile | YouTube H.264 guidance checked October 2026 | Practical decision |
|---|---|---|
| 720p at 30 fps | 3 Mbps minimum, 8 Mbps recommended | Suitable when the source is 720p or when connection headroom is limited |
| 1080p at 30 fps | 5 Mbps minimum, 14 Mbps recommended | Use only when the source and sustained upload capacity justify it |
| Other resolution or frame rate | Consult YouTube's current table | Do not borrow a bitrate from a different row |
Your upload connection needs headroom above the encoded video bitrate because network conditions fluctuate and audio, protocol overhead and other traffic also consume capacity. A speed test taken once does not prove that the connection will remain stable overnight. If the source is 1080p but the connection is inconsistent, reducing the output profile may produce a more usable broadcast than repeatedly attempting the larger one.
Send the real-time FFmpeg output
Here is an editorial starting example for a 30 fps H.264/AAC output:
ffmpeg -re -i "input.mp4" \
-c:v libx264 -preset veryfast \
-b:v 5000k -maxrate 5000k -bufsize 10000k \
-pix_fmt yuv420p -g 60 \
-c:a aac -b:a 128k \
-f flv "rtmps://<YouTube-ingestion-host>/<app>/<STREAM_KEY>"
Replace the file path, host, application path and key with the values for your file and YouTube event. The 5000k video value is only an example of a constant target and should be replaced with the row that fits your chosen profile and connection. The -g 60 value is appropriate for a two-second interval only at 30 fps. If the input is 25 or 60 fps, adapt the output frame rate and GOP instead of copying this value unchanged.
The -preset veryfast option is a compromise between encoding complexity and compression efficiency. A slower preset may use more processing time to achieve similar quality at a given bitrate, while a faster preset may reduce local CPU load with a different quality trade-off. If the computer struggles to encode in real time, a simpler output profile or faster preset may be more useful than increasing the bitrate.
The -maxrate and -bufsize values in the example support a constrained, steady output around the selected video bitrate. They are not a universal recipe. The command also scales neither the input nor explicitly sets the output frame rate, so it is not appropriate to assume that it will turn every source into a 30 fps 1080p stream. Add deliberate scaling and frame-rate options when your source and chosen YouTube profile require them.
For example, if the source is larger than the selected output and you have decided on a 720p profile, you could add a video filter such as -vf "scale=-2:720". Test the result rather than assuming that scaling preserves the source's intended appearance. A vertical source, a square source and a widescreen source each need a presentation decision as well as a technical one.
FFmpeg's documentation covers real-time input and streaming output in its official command-line documentation. YouTube recommends RTMPS where available, so use the secure endpoint supplied by YouTube rather than changing the protocol because an older tutorial used a different address.
Watch the terminal while the command runs. Repeated encoding errors, stalled timestamps, dropped packets or an unexpectedly high speed value can point to a problem before YouTube's preview is useful. Keep the terminal open during the test and note the file, output profile and event used. The sample command has to be adapted and tested on your system; it is not evidence that the input, FFmpeg build or connection is compatible.
Check the preview and stream health before launch
Once FFmpeg is sending data, return to YouTube Studio and wait for the preview and stream-health indicators. Check the picture, movement, cropping, audio presence, audio level and any warnings. Use representative content: if the real programme has speech, music, rapid movement or long quiet sections, include those characteristics in the test.
Do not judge only the first few seconds. Let the test run long enough to reveal whether the connection remains stable and whether audio slowly drifts from the picture. YouTube recommends checking the preview and monitoring stream health and quality during the broadcast. Its guidance should be treated as a test requirement, not as a final step to skip when the local FFmpeg process appears busy.
Listen on a separate device if possible. A local file can sound correct through the computer's player while the encoded stream has no audio, an incorrect track or an unsuitable channel layout. Check that the YouTube preview is showing the intended event, not another scheduled broadcast in the same channel.
If the preview is missing, work through a short order: confirm the channel is eligible, confirm the event is active, recheck the server URL and key, confirm that the protocol and endpoint match, verify that your FFmpeg build supports the selected encoder and protocol, inspect stream mapping and audio presence, then check sustained outgoing bandwidth. This is a practical diagnostic order rather than a YouTube guarantee.
If the preview appears but is unstable, first reduce the output ambition. Lower the resolution, frame rate or bitrate to match the source and connection, then run the test again. If the picture is stable but the audio is absent, inspect the input streams and mapping rather than immediately changing the video settings.
When the event is complete, stop FFmpeg and confirm the event's state in YouTube Studio. Do not assume that the local file ending will perform every closing action for the YouTube event. For an unattended loop, test the transition from one file to the next and the behaviour after a network interruption before relying on it overnight.
If you need a machine that remains available without leaving your personal computer on, StreamNeo removes the local run-and-restart task by taking an uploaded video, your YouTube stream key and the continuous broadcast workflow out of the desktop session. You still need to choose suitable content, check YouTube's rules and test the resulting channel.
For longer-running channels, also consider the non-technical risks. A file can be technically valid and still contain music, images or footage you do not have permission to broadcast. Read the guide to copyright strikes on a 24/7 loop before treating a successful test as permission to publish. If you are comparing a local computer with a VPS, the VPS setup guide for 24/7 YouTube streaming with FFmpeg covers a different operating model, with its own maintenance and reliability trade-offs.
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 stream an MP4 file to YouTube Live with FFmpeg?
Yes, if FFmpeg can read the file and produce an output that YouTube accepts. The MP4 extension alone does not tell you the video codec, frame rate, audio tracks or pixel format, so inspect the file and adapt the command rather than assuming every MP4 has the same structure.
Why use -re with a local file?
A local file can otherwise be processed faster than real time. -re paces the input so that FFmpeg sends it approximately at playback speed, which is necessary when a file is being used as the source for a live feed.
Is the example bitrate suitable for every connection?
No. The example is a starting value for a particular output profile, not a universal setting. Use YouTube's current recommendation for your codec, resolution and frame rate, leave upload headroom, and test for sustained stability.
What should I do if I lose my stream key?
Do not publish or reuse a key that has been exposed. Reset it in YouTube Studio, copy the replacement into your private encoder setup, and run another test before the event.