For an existing 1080p/30 lecture with audio, this FFmpeg command is a practical starting template for sending a repeating file to YouTube Live. It uses real-time pacing and an indefinite input loop, but you must check the event-specific stream URL and key in YouTube Live Control Room before you connect.
The template is not universally best or guaranteed to work: the right output depends on the recording, your computer, your connection and YouTube’s current ingest guidance. Treat the stream key like a password, test the actual feed, and do not assume that a running FFmpeg process means viewers are receiving a healthy stream.
When this FFmpeg template fits
This command is intended for one existing 1080p, 30-frame-per-second lecture recording with audio. It transcodes the video to H.264 and the audio to AAC, then sends the output as an FLV stream. It is useful when you want a lecture to play at its normal pace and repeat continuously as a live broadcast.
It is a starting point rather than a file-specific prescription. The source could have a different resolution, frame rate, audio layout or encoding, and your machine may not be able to transcode it in real time. A lecture with static slides may be less demanding than one with frequent movement, but you should judge by testing the actual file rather than assuming its content makes encoding effortless.
This method also does not turn a recording into an interactive event. Viewers see a live feed of the file; questions, corrections and timing do not automatically adapt to the audience. If the lecture contains a live introduction or announcements, plan separately how those should fit around the recording.
The command runs on the computer where FFmpeg is installed. That computer and its internet connection must remain available for the duration of the stream. If your aim is a channel that continues after your own computer is switched off, a command running locally is not that arrangement. For a broader overview of the format and the moving parts, see how video streaming works.
Prepare the lecture file and YouTube event
Before running a command, make sure you know which file it will use and which live event it should feed. Put the lecture in a location you can identify reliably, and note whether it has the audio you expect. A path such as lecture.mp4 only works if that file is in FFmpeg’s current working directory; otherwise use its full path.
In YouTube Studio, create or select the intended live stream and open its Live Control Room. Find the stream URL and stream key for that event. YouTube’s live stream settings guidance explains where those details are managed. The destination in the example below is illustrative: use the actual URL shown for your event, not the sample endpoint simply because it appears in a command.
The key is credential-like. Anyone who obtains it may be able to send a feed to the associated event, so do not paste a real key into a public script repository, screenshot, article, chat or support post. If you need to save a command, keep the key out of files that others can read, and avoid sharing terminal output that includes the full destination.
Check the event’s visibility and schedule in Studio as well. An encoder can be sending data while the event is private, unlisted or scheduled in a way that does not match your intention. Confirm the intended audience and event status in YouTube before you treat the broadcast as ready.
The looping command
For an existing 1080p/30 lecture with audio, use this as a starting template, replacing the quoted input file and the destination with values for your own setup:
ffmpeg -re -stream_loop -1 -i "lecture.mp4" \\
-map 0:v:0 -map 0:a:0? \\
-c:v libx264 -preset veryfast \\
-b:v 5M -maxrate 5M -bufsize 10M \\
-pix_fmt yuv420p -g 60 -keyint_min 60 -sc_threshold 0 \\
-c:a aac -b:a 128k -ar 44100 \\
-f flv "rtmps://a.rtmps.youtube.com/live2/STREAM_KEY"
The final destination is not a real key and is not a substitute for the event URL from Live Control Room. Replace the entire quoted destination with the actual URL and key provided for the selected event, preserving its required format. If your event shows a different endpoint, follow that event’s details rather than copying the sample literally.
The line breaks and backslashes are shell continuations for a typical Unix-like terminal. In a Windows command prompt, line continuation syntax differs; you can place the command on one line, or adapt it to the shell you use. FFmpeg options are read in order, so the placement of input options before -i matters. The FFmpeg protocol documentation shows real-time file input being sent to an RTMP destination and describes RTMPS as RTMP over a secure connection.
What the video and audio options do
-re tells FFmpeg to read the file at its native rate, pacing file input for live output instead of sending it as fast as the computer can process it. -stream_loop -1 requests an indefinite repeat of the input. It is an input option and belongs before -i; -1 means no fixed loop count. FFmpeg’s option documentation and project notes are useful references when adapting commands, but verify your installed build and test the complete setup.
-i "lecture.mp4" identifies the source file. -map 0:v:0 selects the first video stream from that input. -map 0:a:0? selects the first audio stream if present; the question mark makes that mapping optional so the command does not fail solely because the source has no audio stream. Optional mapping is not a recommendation to broadcast a lecture silently: confirm that the resulting event has the audio behaviour you intend.
-c:v libx264 selects the software H.264 encoder. -preset veryfast trades some compression efficiency for a lighter encoding workload compared with slower presets. It does not promise that a particular computer can keep up. If FFmpeg falls behind, test a faster supported preset or compatible hardware encoding, then inspect the output in YouTube’s preview.
The -b:v, -maxrate and -bufsize settings shape the video bitrate behaviour. In this example the target and maximum are set to 5 Mbps, with a 10 Mbps buffer size. YouTube’s current live encoder settings and bitrate table lists 5 Mbps minimum and 14 Mbps recommended for H.264 at 1080p/30. Those are current guidance figures, not a publication-year claim; the 5 Mbps example is the listed minimum, not a universal ideal. Leave upload headroom and choose settings for the actual resolution and frame rate.
-pix_fmt yuv420p sets a common pixel format for compatibility. -g 60 and -keyint_min 60 set the keyframe interval in frames, while -sc_threshold 0 disables scene-change-driven keyframe decisions. At 30 frames per second, 60 frames correspond to two seconds. YouTube recommends a two-second keyframe interval and says not to exceed four seconds in its encoder guidance, so if you change frame rate, revisit the GOP value rather than retaining 60 automatically.
The audio options select AAC (-c:a aac), set the audio bitrate to 128 kbps (-b:a 128k) and use a 44.1 kHz sample rate (-ar 44100). YouTube lists 128 kbps and 44.1 kHz for stereo in its recommended advanced settings. These values describe the template; listen to the result and make sure the source audio is present, intelligible and in sync.
Finally, -f flv selects the output container expected by this style of RTMP ingest. The rtmps:// scheme requests the secure variant when supported by your FFmpeg build and accepted by the event endpoint. YouTube recommends RTMPS, but the event’s displayed URL and your installed FFmpeg capabilities still matter.
Replace the file, URL, and stream key safely
There are three substitutions to make before a real run. First, replace lecture.mp4 with the actual path, including quotation marks if the path contains spaces. Second, copy the event’s stream URL from Live Control Room. Third, use that event’s stream key only in the destination required by the URL format YouTube presents.
Do not strip the stream key out of its context or assume every event uses an identical endpoint. The example destination is provided to show the shape of a target, not to certify that it matches your event. If YouTube Studio supplies distinct server and key fields, follow the instructions displayed there for combining or entering them in your encoder.
A command typed directly into a terminal may be recorded in shell history or visible in a process list, depending on the operating system and setup. For a one-off test, limit who can access the computer and terminal session. For a recurring broadcast, use a credential-handling approach appropriate to your environment rather than putting a live key in a document that is routinely shared.
If you think the key has been exposed, return to Studio and manage the stream settings there; do not continue broadcasting on the assumption that the old credential is private. For a channel expected to resume after a power interruption, the command itself may need a process supervisor and careful recovery testing. The practical considerations are covered in automatic restart after a power cut.
Test the feed before relying on it
Start with a private or unlisted test event if that suits your workflow, and check its visibility before you begin. Run the command and look for FFmpeg errors, but do not use the terminal alone as evidence that the feed is healthy. Open Live Control Room and inspect the preview and stream-health messages. YouTube’s testing guidance recommends testing representative audio and video movement and monitoring stream health.
A useful test includes the parts that are easy to miss in a short check: a section with speech, a transition or slide change, and the point where the source reaches its end and begins again. Listen for audio at normal volume and watch for a black frame, a pause, unexpected silence or a restart that does not happen as expected. The loop option is documented, but a particular lecture file and setup have not been tested here.
Check that the event is accessible as intended, including its visibility and schedule, and review the public or unlisted viewer experience if applicable. A process that remains open can still be sending an incompatible feed, sending to the wrong event, or failing to deliver a sound viewers can hear. Keep the Live Control Room visible during an initial run so that you can spot a warning rather than discovering it after viewers report a problem.
If the lecture has known sync issues, diagnose those in the source before broadcasting rather than assuming the live encoder will correct them. The separate guide on fixing audio sync for a recorded YouTube Live video can help you distinguish a source-file problem from a connection or encoding issue.
For a channel intended to continue beyond your computer’s working hours, consider whether a local FFmpeg process is the right operating model. A hosted workflow can remove the need to leave your own computer running; StreamNeo addresses that specific burden by taking an uploaded video and running it as a YouTube live stream while your computer is off. It remains YouTube-only, and you still need to prepare the file, event and credentials responsibly.
Common encoding and connection checks
If the feed will not connect, first compare the destination with the event details in Live Control Room, including whether the endpoint shown is RTMPS. Check that the installed FFmpeg build supports the protocol and encoder you selected. A copied command can be syntactically sound yet fail because a build lacks a required component or because the event URL was copied incorrectly.
If the preview is choppy or stream health reports trouble, consider the full path: the computer must encode the file at real time, and the upload connection must sustain the output with headroom. The example bitrate is at YouTube’s listed minimum for H.264 at 1080p/30, not a cushion for every network. YouTube’s bitrate table gives different guidance for other formats; for example, its current H.264 guidance lists 6 Mbps minimum and 17 Mbps recommended at 1080p/60. Match settings to your chosen output rather than applying the 30 fps template unchanged.
If the computer’s CPU is the constraint, a faster x264 preset or supported hardware encoder may help, but hardware availability and output compatibility vary. Conversely, if the source already matches YouTube’s accepted ingest parameters, stream copy (-c:v copy -c:a copy) may reduce local encoding work. Do not assume a lecture qualifies: copying preserves the source’s codec and parameters, so inspect the file and verify that bitrate, keyframes, video and audio formats meet the event’s requirements before relying on it.
If audio is missing, confirm the recording actually contains an audio stream and that the optional map selects the intended one. If sound exists but is out of sync, inspect the file and its timing rather than changing multiple encoder settings at once. Keep a record of the tested command with the credential removed so you can compare changes without exposing the key.
The best troubleshooting order is modest: establish the correct event destination, confirm that FFmpeg can open the source, confirm the selected streams and encoding, then watch the preview and health indicators while the file plays and loops. Change one setting at a time where possible. That makes it easier to tell whether a correction addressed the cause or merely coincided with a better connection.
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
What is the best FFmpeg command to loop a lecture to YouTube Live?
There is no single command that is best for every recording and computer. The template above is a practical starting point for an existing 1080p/30 lecture with audio; use the event’s actual URL and key, then test its preview and stream health.
How does FFmpeg loop a video indefinitely?
Use -stream_loop -1 before the input option -i. The -1 value requests an indefinite loop, while -re paces the file at its native rate for live output.
Can I use the sample RTMPS endpoint as written?
No. It illustrates the destination format and contains a placeholder, not a real stream key or a guarantee that it matches your event. Copy the stream URL and key shown for the selected event in YouTube Live Control Room, and protect the key as a credential.
Does the command prove that YouTube is receiving a good stream?
No. FFmpeg can remain running while the event has a wrong destination, unhealthy feed, missing audio or an unintended visibility setting. Check Live Control Room’s preview and health messages, and watch the source reach its loop point during a test.