Skip to content
streamneo.
Setup Guides12 min read

How to Convert Videos to the Right Format for a Nonstop YouTube Stream with FFmpeg

Loop a video with FFmpeg, match YouTube Live encoder settings, and test the stream before relying on a long-running broadcast.

sn.
StreamNeoPublished 5 October 2026
Worth sharing?

To loop a video file into YouTube Live with FFmpeg, repeat the input and configure the outgoing stream as two separate parts of the job. You also need to match the output to YouTube’s current encoder guidance, test the feed, and keep an eye on the computer and connection; no single command guarantees an uninterrupted broadcast.

The practical aim is a stream that remains watchable through repeated playback, not simply a file that has been converted. Start by checking what the file contains, then choose output settings for its intended resolution, frame rate, codec, and available upload capacity.

Check the source video and its properties

Before encoding, find out what you are starting with. Check the video dimensions, frame rate, aspect ratio, video and audio codecs, audio channel layout, and duration. FFmpeg’s ffprobe can report those properties; for example, ffprobe -hide_banner input.mp4 prints a readable summary. The exact output varies with the file, so use it to inspect rather than assuming every MP4 has the same contents.

Decide what viewers need to see. A devotional channel showing a still image and lyrics may not benefit from preserving a high source frame rate. A local news loop with moving footage may need more detail and smoother motion. Keep the target resolution and frame rate aligned with the source and purpose: scaling up a small file does not restore detail that was never recorded.

Check the file from beginning to end, not just the first few seconds. Look for black gaps, silent sections, sudden changes in loudness, orientation changes, aspect-ratio bars, and abrupt cuts at the point where the file will loop. Listen for audio clipping or a soundtrack that ends before the video. If the file contains several segments already joined together, inspect those transitions as well.

Re-encoding is not automatically necessary. If the source already has a suitable codec, frame rate, dimensions, and audio, a direct copy may avoid needless quality loss and reduce processing. But copying source streams does not make them conform to the output you intend to send. If the source needs scaling, a different frame rate, a compatible codec, or a changed audio layout, encode those parts deliberately.

For a resolution decision, compare the viewer goal and the upload you can sustain, rather than choosing the largest available number by default. Our guide to 1440p versus 1080p streaming quality discusses that trade-off. A 1080p target is not inherently right for every source, and a smaller, clean source can look better than an enlarged one with the same output dimensions.

Loop the input separately from output encoding

FFmpeg’s -stream_loop -1 option repeats an input indefinitely. It is an input option, so put it before the -i that names the file. The FFmpeg documentation describes the option in its command-line documentation. In a basic layout, ffmpeg -stream_loop -1 -i input.mp4 ... tells FFmpeg to read the file again when it reaches the end.

That loop setting controls where frames and audio come from. It does not choose the YouTube video codec, bitrate, keyframe interval, audio format, or destination. Those belong to output configuration. Keeping the two responsibilities separate makes it easier to diagnose a black screen or failed connection: the file may not be looping as expected, or the outgoing stream may be incorrectly encoded or addressed.

For file playback intended to be sent at real-time speed, FFmpeg’s -re option is commonly included before the input. Without real-time pacing, a file reader can process a local file faster than its playback duration, which is not the timing you want for a live programme. Treat it as part of the input workflow, not a reliability switch: it cannot make a slow connection faster or repair malformed media.

A repeat point can still be noticeable. If the final frame and audio do not lead naturally into the opening, viewers may hear a click, a short pause, or a jarring change each time the file restarts. For a long devotional recording, that might be less disruptive than an abrupt restart in a news bulletin or study lesson. Review the boundary and, if necessary, edit the source into a better loop before broadcasting.

If your plan is to play multiple files in sequence rather than repeat one file, the playlist and transition behaviour need their own checks. The article on streaming a prerecorded chemistry revision channel is a useful example of thinking about the programme as a schedule, not just a single command. A single-file loop has fewer moving pieces, but it also repeats the same ending and beginning.

Match output settings to YouTube requirements

Choose the codec and bitrate together with the target resolution and frame rate. YouTube’s live encoder settings guidance publishes separate recommendations by codec and ingestion format. It lists H.264, H.265/HEVC, and AV1 video, AAC or MP3 audio, constant bitrate (CBR), and frame rates up to 60 fps. Its advanced guidance also includes progressive scan, square pixels, CABAC, Rec. 709 for SDR, and 44.1 kHz stereo audio.

For conventional SDR H.264, YouTube’s table gives these example video bitrate recommendations. The values are YouTube’s published settings, not universal rules for every codec or stream. Check the current table for your chosen codec and output before relying on a value.

Ingestion format H.264 minimum H.264 recommended
1080p at 60 fps 6 Mbps 17 Mbps
1080p at 30 fps 5 Mbps 14 Mbps
720p at 60 fps 3 Mbps 8 Mbps
720p at 30 fps 3 Mbps 8 Mbps

YouTube lists different recommendations for AV1 and H.265. For example, its table recommends 10 Mbps for 1080p at 30 fps and 12 Mbps for 1080p at 60 fps for those codecs, with a 4 Mbps minimum for both cases. Do not copy an H.264 value into an AV1 or HEVC command and assume the recommendation is equivalent. The page also identifies H.265 as its recommended HDR video codec and says AV1 is not supported for HDR; check its latest guidance if you intend to send HDR.

For H.264, YouTube recommends CBR and a keyframe interval of two seconds, which should not exceed four seconds. In FFmpeg, a GOP setting such as -g 60 represents two seconds only when the output is 30 frames per second. At another frame rate, work out the frame count for the intended interval rather than leaving the example unchanged. Keyframe timing and bitrate are separate settings: one does not substitute for the other.

A starting command might look like this, but it is illustrative, not a tested recipe or a promise of continuity. Replace the placeholders and settings to match the file, selected YouTube table row, available upload, and FFmpeg build. The 4500k bitrate shown here is an example only and is not a YouTube recommendation for every resolution and frame rate.

ffmpeg -stream_loop -1 -re -i input.mp4 \\
  -c:v libx264 -preset veryfast -b:v 4500k -maxrate 4500k -bufsize 9000k \\
  -g 60 -c:a aac -b:a 128k -f flv \\
  "rtmps://<YouTube-ingest>/<stream-key>"

This example requests H.264 video, AAC audio, a video bitrate limit, a GOP size, and an FLV output container. If your source is not 30 fps, -g 60 does not express a two-second interval. If it is not already the target size or frame rate, the example does not scale or convert it. Those changes require appropriate filters or output options and should be checked with a local test before you use them on a live channel.

Audio deserves its own check. YouTube’s guidance lists 128 Kbps for stereo audio and 384 Kbps for 5.1 surround sound, as well as 44.1 kHz stereo. Pick a layout and output that suit your programme; a mono talk or music file does not need to be turned into surround sound. Watch levels for clipping and listen to a complete loop boundary, as a technically valid audio stream can still be uncomfortable to hear.

Configure the stream URL and key

In YouTube Studio, configure the live stream and obtain the stream URL and stream key for the encoder. YouTube’s live stream settings guidance explains the platform-side settings. The command’s destination combines the ingest address with the key according to the format accepted by your encoder; the placeholder in the example is not a literal URL to copy.

YouTube recommends RTMPS. Confirm that the FFmpeg build you are using can connect to the destination and protocol, and use the current ingest details displayed in YouTube Studio. Do not put a real stream key in a public script, screenshot, shared chat, or article. A person with the key may be able to send a broadcast to your channel, so store it privately and replace it if it is exposed.

Keep the configured destination and key distinct from the media settings in your notes. If you revise the bitrate or change from H.264 to another codec, that does not mean the key changes. Conversely, a correct encode cannot compensate for a wrong or revoked key, a different selected live event, or a destination copied from an old setup. Check the selected event and stream status in Studio before beginning a public broadcast.

A local file sent directly to YouTube gives you control over the command and the machine running it, but it also leaves that machine and its connection in the operating path. If you are comparing this with other ways to keep a recorded loop online, the guide to moving a local YouTube loop to a hosted workflow in India can help frame the operational choice. For a narrower explanation of key handling and connection setup, use YouTube’s current official instructions rather than relying on an old copied command.

Check encoder capacity and network stability

An encode has to be produced and uploaded continuously. A computer that can play a file may still struggle to encode it in real time, particularly if the chosen resolution, frame rate, or codec is demanding. Watch CPU or hardware-encoder load, temperature, and memory during a representative test. If the machine is repeatedly overloaded, reduce unnecessary processing or choose a less demanding target that still suits the source and audience.

The upload connection must carry the total stream bitrate with room for variation. YouTube recommends leaving 20 per cent headroom over the total bitrate. Include audio when estimating the total and account for other devices or activity using the same connection. A speed test at one moment is not proof that the route will remain stable overnight; note whether the connection is shared, subject to data limits, or prone to interruptions.

For a small business or a home channel in India, consider what else depends on the broadband connection. A video call, cloud backup, or household download can compete with the live upload. Schedule large uploads outside the broadcast where practical, use a wired connection if you can, and check whether a power interruption or router restart is likely to stop the session. These are risk reductions, not guarantees.

Resolution, frame rate, codec, and bitrate form a set of choices. A higher bitrate may preserve more detail, but it needs more upload capacity and does not improve a low-detail source. A lower target can be more appropriate for a simple still-image programme or a constrained connection. If the stream is meant to run unattended, favour settings the actual machine and connection can sustain over settings chosen only because they are larger.

Consider what should happen if the process exits. A terminal command that stops after a network failure does not restart itself merely because the input loops. You need a way to notice the interruption and decide whether to restart the process, correct the cause, or use an operating arrangement that monitors and restarts a dropped broadcast. StreamNeo can remove the burden of keeping your own computer running for a file-based YouTube loop when that is the specific problem you need to address; it does not remove the need to prepare the file and verify the channel.

Test the stream and monitor interruptions

YouTube Help says, “Make sure to test before you start your live stream.” Its encoder guidance advises tests with audio and movement similar to the planned stream, and monitoring stream health and messages during the event. Use a private or otherwise appropriate test first. Confirm that the picture is moving, the audio is present and balanced, and the selected resolution and frame rate appear as expected in YouTube Studio.

Let the test run long enough to reach the file’s end and repeat point. Check for a visible pause, audio discontinuity, frozen frame, or process error when the input loops. A short preview of the opening cannot reveal a bad ending. If your programme uses a static visual, include a moving test segment as YouTube advises, then confirm the real programme behaves as intended.

During the test, watch the platform’s stream health indicator and any messages in Studio. On the computer, note whether FFmpeg reports dropped frames, connection errors, or encoder problems. If the stream degrades, change one relevant variable at a time where possible: a bitrate that exceeds reliable upload, a frame rate the source cannot supply cleanly, an unsupported codec, or a key that is wrong. Keep a record of the working settings, but review them when YouTube updates its guidance or when the stream setup changes.

For an unattended run, create a simple check routine: verify the live status before leaving, return to check after the first loop, and confirm that the feed is still healthy at intervals that fit the consequences of a failure. Decide who will receive an alert and what they should do if the encoder stops. A command, however carefully configured, cannot report a power cut to someone who is not monitoring it or ensure that a broadband connection stays available.

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

How do I loop a video with FFmpeg on YouTube Live?

Put -stream_loop -1 before the input’s -i option, then configure the output codec, bitrate, audio, and destination separately. Include real-time pacing for a file used as a live source, and test the repeated file in YouTube Studio. The loop option does not guarantee an uninterrupted stream.

What bitrate should I use for a 1080p YouTube stream?

Use YouTube’s current recommendation for the selected codec and frame rate, not one value for all 1080p streams. For H.264, YouTube’s table lists 14 Mbps recommended at 1080p30 and 17 Mbps at 1080p60; AV1 and H.265 have separate figures. Make sure the total bitrate fits your upload with headroom.

Does the command shown here work for every FFmpeg installation?

No. It is an illustrative pattern, and available encoders, muxers, protocol support, and source characteristics vary by build and file. Check your installed FFmpeg capabilities and validate the output with a test stream before relying on it.

Can FFmpeg alone keep a YouTube stream running all night?

No single FFmpeg command can guarantee that. The machine, power, connection, source file, stream key, and YouTube’s service status can all affect continuity. Plan how you will detect and respond to a dropped stream, and monitor stream health during the broadcast.

YOU’VE REACHED THE END

Keep the ideas coming.

More guides, useful tools and a little help for your next broadcast.

Back to the journal ↗
YOUR NEXT READ

A little more to explore.

More Setup Guides guides ↗ · All topics ↗