A Linux machine can send a recorded property tour to YouTube Live repeatedly by asking FFmpeg to loop the input file and encode it for YouTube’s ingest endpoint. The loop flag handles repeat playback; it does not connect to YouTube by itself or guarantee that the broadcast stays uninterrupted.
This guide covers the file, the FFmpeg command, the Live Control Room URL and key, and a cautious test before you go live. You will still need to monitor the connection and YouTube’s stream health while the channel is running.
Prepare the property-tour file on Linux
Start with a tour file you are entitled to rebroadcast, and check that it does not expose details you should not make public: residents, access codes, documents, vehicle registration plates, or private possessions. If it is a client’s property, confirm the client has approved both the footage and continuous publication. The technical setup cannot answer questions about your rights or local privacy obligations.
Keep the file somewhere stable and use a simple path. For example, tour.mp4 in your current working directory is easier to refer to than a filename with ambiguous punctuation or a file on a removable disk that might be disconnected. If you use another path, quote it in the command, as in "/home/stream/tours/flat-tour.mp4".
Before streaming, inspect the file’s streams and playback. FFmpeg’s -i option can show information about the input, including whether it contains video and audio. You can also play the file locally to check that the tour is complete, that the opening and ending are suitable for repetition, and that the sound is present and at a reasonable level. A silent tour may be intentional; do not assume it has an audio track just because the file has video.
A loop makes the end lead back to the start. Consider what viewers will see at that join: a title card or a short neutral transition can make the restart less abrupt, while a property tour that begins with a long slate may repeatedly show that slate. If you need help diagnosing a file that has video but no sound in the live output, the FFmpeg loop audio troubleshooting guide is a relevant next step.
Put the loop option before the input
FFmpeg options are interpreted in relation to the input or output they precede. For an infinitely repeating file input, put -stream_loop -1 before that file’s -i. The FFmpeg documentation describes -1 as an infinite loop; 0 means no loop. See the FFmpeg project documentation for the option’s scope and other command-line details.
A typical command shape for a single MP4 file is:
ffmpeg -re -stream_loop -1 -i "tour.mp4" \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-b:v 5M -maxrate 5M -bufsize 10M -g 60 \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://INGESTION_URL/STREAM_KEY"
This is an illustrative configuration, not a tested command for your particular Linux host or file. Replace the example filename and endpoint with your own. The loop option applies to the input that follows it; placing it after -i does not express the same input-loop instruction. -re asks FFmpeg to read the file at a real-time pace, which is appropriate for file playout rather than sending the whole file as fast as it can be read.
The command has separate jobs. -stream_loop -1 repeats the input; -re paces reading; the -c:v and -c:a options select video and audio encoders; -f flv selects the output container used in this RTMP-family workflow; and the final quoted value is the destination. A working loop does not establish a connection to YouTube, and successful encoding does not prove that the network can sustain the feed.
If your file has no audio, FFmpeg may report an output mapping problem or produce a video-only stream. Inspect the input’s streams first; do not blindly add audio settings to a nonexistent track. When a file has multiple tracks, choose or map the intended audio deliberately. You can also adapt the command to omit audio encoding when the tour is intentionally silent, but verify the resulting stream in YouTube’s preview.
Choose an encode that fits the tour and connection
YouTube’s current live encoder guidance supports H.264, H.265/HEVC and AV1 video, up to 60 fps, with AAC or MP3 audio. For a straightforward Linux FFmpeg setup, H.264 with AAC is a familiar starting point if your FFmpeg build includes the encoder. YouTube recommends constant bitrate (CBR), a two-second keyframe interval, and no more than four seconds between keyframes. Its encoder settings and bitrate recommendations should be checked again when you configure a channel, since platform guidance can change.
The example command uses H.264 at 1080p30 as a reference point: YouTube Help’s recommended video bitrate for that combination is 5 Mbps, according to its current guidance verified in 2026. That is a platform recommendation, not a universal requirement or a promise that your connection can carry it. YouTube lists different recommendations by codec, resolution and frame rate, so do not copy the example bitrate for a different encode without checking the table.
| Example target | YouTube recommended video bitrate | What to consider |
|---|---|---|
| H.264, 1080p30 | 5 Mbps | The example command’s video bitrate; allow for audio and network overhead as well. |
| H.264, 1080p60 | 14 Mbps | A higher frame rate needs substantially more upload capacity than the 1080p30 example. |
| H.265 or AV1, 1080p30 | 10 Mbps | Use only if your encoder and chosen YouTube ingest path support your selected codec. |
| H.265 or AV1, 1080p60 | 12 Mbps | Check codec support and capacity rather than assuming this is interchangeable with H.264. |
These figures are YouTube recommendations, not measurements of what your file or connection will achieve. Pick a resolution and frame rate suited to the original tour: encoding a modest source at a higher resolution does not restore detail, and 60 fps may be unnecessary for a slow interior walkthrough. Then choose a bitrate the upload connection can sustain with room for variation. YouTube recommends running a speed test; test from the location and connection that will actually carry the stream.
In the example, -b:v sets the target video bitrate, while -maxrate and -bufsize are included to shape the encode. The -g 60 value corresponds to a two-second keyframe interval when the output is 30 frames per second; if you change the frame rate, revisit the GOP/keyframe setting rather than leaving it unexplained. -pix_fmt yuv420p is a commonly used compatibility choice, but codec availability and options depend on the FFmpeg build. The command combines settings from separate pieces of guidance; it is not a vendor-certified recipe for every input and endpoint.
Get the RTMPS URL and stream key
In YouTube Studio, open Live Control Room and create or select the live stream. Use the stream URL and key displayed there; do not copy an endpoint from an old tutorial or guess the URL format. YouTube recommends RTMPS, and its RTMPS setup instructions explain where to retrieve the details. Google’s RTMPS ingestion guide specifies the secure connection requirements, including port 443.
Treat the key as a password. Put it only in the FFmpeg destination where it is required, and do not publish it in a screenshot, shell history shared with others, support post, or public script. If you think the key has been exposed, reset it in YouTube Studio and update the command. Be sure to preserve the exact URL and key format shown by Live Control Room; the placeholder rtmps://INGESTION_URL/STREAM_KEY in the example is not a literal destination.
A scheduled stream and an active stream are not always the same state. Follow the controls in Live Control Room for the selected event and make sure your channel is available to go live. Account availability and any channel-specific restrictions are not settled by an FFmpeg command, so check the current official interface rather than assuming the encoder can override them.
If you are comparing this approach with a general file-to-live recipe, the Linux FFmpeg file streaming guide may help separate basic sending from the extra loop behaviour covered here. For broader platform questions, review whether YouTube allows continuous prerecorded live streams; permission to use a tool technically is not the same as a determination about your footage or channel.
Test the stream and confirm the preview
Test before announcing or relying on the broadcast. Start with the same file, encode settings, network, and intended audio that you expect to use for the live run. YouTube’s encoder guidance advises testing first, using movement and audio like the planned stream, and watching stream health messages. A static desktop speed test is useful, but it cannot substitute for observing the actual feed under its intended conditions.
Run the command in a terminal where you can see FFmpeg’s output. Check that the input opens, the expected streams are selected, and the process continues rather than exiting with an error. Then look at Live Control Room: wait for the incoming preview, check the picture and sound, and read any warnings about bitrate or connection health. Confirm that the tour is not cropped unexpectedly, the audio is not missing or distorted, and the image remains legible during movement.
Do not treat a preview arriving once as a night-long reliability test. Let the test run long enough to see the loop return to the opening, if practical, and note whether playback and audio resume as intended. A file can have a damaged ending, a discontinuity, or a scene that looks jarring when repeated even when FFmpeg has not failed. If you change resolution, bitrate, audio mapping or the file itself, repeat the preview check.
The public-facing status also matters. Confirm that the intended stream is selected and that its visibility and start controls match your plan. A successful encoder connection does not automatically mean viewers can find or watch the event in the way you expect. Do not share a test key or leave an unintended test broadcast running while you prepare the final event.
Monitor the feed after launch
Once live, keep an eye on both sides of the connection: FFmpeg’s terminal output and YouTube’s stream health indicators or messages. FFmpeg can continue running while the picture is stalled or YouTube reports a problem, and a YouTube preview can appear briefly even though the local process later exits. Leave yourself a way to check the stream, particularly if the tour is meant to remain up overnight.
A repeated video file is not an uninterrupted broadcast. The machine can sleep or reboot, the process can stop, a network connection can drop, YouTube can reject an ingest configuration, or the key and URL can be wrong. The loop addresses only what happens when FFmpeg reaches the end of the input and can continue reading it; it does not monitor the internet connection, restart a failed process, or resolve account and ingest problems. For a channel with more than one continuous prerecorded stream, plan capacity and oversight separately; this guide to running two 24/7 streams on one YouTube channel covers a different operational question.
If the stream stops or health warnings appear, capture the relevant FFmpeg message without exposing the key, then check the basics in order: is the process still running, is the network available, does Live Control Room still show the expected stream, and do the URL and key match? Next check whether the selected encoder, bitrate, resolution and frame rate are suitable for the connection and the current ingest guidance. Changing several encode options at once makes it harder to tell what resolved the issue.
A Linux host also needs ordinary operational care. Avoid suspending the machine, closing a terminal in a way that terminates the process, or relying on a network path you cannot observe. If you use a process manager or automatic restart arrangement, understand how it behaves and test its recovery path before depending on it. Automatic restart may bring FFmpeg back, but it cannot guarantee that YouTube accepts the reconnection or that the connection remains stable.
Decide whether local looping is the right fit
Running FFmpeg locally gives you direct control over the source file, encode choices and logs. It can suit a channel that already has a Linux machine and someone prepared to check it. The trade-off is that the machine and connection become part of the broadcast path; a file loop cannot take over if the host is powered down or disconnected.
If you need a broadcast to continue with your own computer switched off, the operational question is no longer only how to place a loop flag. StreamNeo can remove the need to keep your local Linux machine running for file playout; you still need to prepare the file, provide the channel’s stream key, and monitor the resulting YouTube broadcast appropriately. It is YouTube-only, so it is not a fit if you need to send the same feed to another platform.
Whichever route you use, make the choice around who will notice and respond to a stopped feed, what connection is available, and whether you can test before viewers arrive. Do not choose a more complex codec or a higher output setting just because it is available in a software build. A simpler encode that matches the source and stays within sustainable upload capacity is easier to diagnose.
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
Does -stream_loop -1 make YouTube Live continue forever?
No. It asks FFmpeg to repeat the input file indefinitely while the process is able to run. It does not make the YouTube connection permanent, guarantee account eligibility, or recover every network or encoder failure.
Why must the loop option come before -i?
-stream_loop is an input option, so it applies to the input that follows it. Put -stream_loop -1 before -i "tour.mp4" to loop that file rather than placing the option after the input declaration.
What bitrate should I use for a property tour?
Choose based on the codec, resolution and frame rate you intend to send, then confirm that your upload connection can sustain the feed. YouTube’s current recommendations are codec-specific; its 5 Mbps H.264 recommendation for 1080p30 is a reference point, not a universal setting for every tour.
Can I use the same command if my tour has no audio?
Not without checking the file and output mapping. Inspect the input streams and choose the intended audio deliberately; if there is no audio track, remove or adapt the audio settings and confirm the result in YouTube’s preview.