Start with 1920×1080 at 30 fps and 14 Mbps video when your connection can sustain it reliably. For a lower-bandwidth or less demanding setup, 1280×720 at 30 fps and 8 Mbps is a sensible alternative.
Those are YouTube's recommended H.264 ingest rates, not guarantees of uninterrupted service. The important detail is that FFmpeg's stream-copy mode can avoid re-encoding only when the files, timestamps, container and output settings are already compatible.
What stream copy does and does not do
Stream copy tells FFmpeg to pass the existing audio and video packets through without decoding and encoding them again. In a command, this is usually written as -c copy. It can reduce processor use, avoid another generation of quality loss and make it practical to run a long pre-recorded programme on modest hardware.
It does not convert a file to the resolution, codec, frame rate or audio format that YouTube expects. It does not repair damaged timestamps, make different codecs join cleanly or guarantee that a transition between files will be invisible. It also does not choose a bitrate for you. The copied packets retain the properties they already have.
That makes stream copy conditional rather than a universal shortcut. If every input is already H.264 video with matching parameters, compatible audio and suitable timestamps, copying may be the cleanest route. If one file is HEVC, another is H.264, and a third has a different frame rate or audio layout, -c copy cannot harmonise them.
There is also a difference between the source file's bitrate and the bitrate YouTube receives. With stream copy, the outgoing video rate follows the encoded packets in the source. With re-encoding, you explicitly select an output rate such as 14 Mbps. YouTube then processes the live input for different playback formats, so viewers may not receive exactly the same version you send.
For a 24/7 channel, the low CPU use of copying can be valuable, but a predictable encoded output is often more valuable than the lowest possible processing load. A devotional loop, a study timer and a market update programme may all need different choices because their motion, source formats and transitions differ.
Check file compatibility before concatenating
Do not begin by building a long concat list. First inspect every file that will be part of the loop. FFmpeg's ffprobe can show the streams, codec names, dimensions, frame rate, sample rate, channel layout and duration. You are looking for a common output shape, not merely files that all open in a media player.
For example:
ffprobe -v error -show_streams -show_format input.mp4
Compare the results for the video streams:
- codec, such as H.264
- width and height
- pixel format
- progressive or interlaced scanning
- frame rate and time base
- colour information where it matters
- the presence and order of keyframes
Then compare the audio streams:
- codec, such as AAC
- sample rate
- channel count and layout
- stream order
- whether every file actually has audio
Matching dimensions alone is not enough. Two files can both be 1920×1080 while using different frame rates, pixel formats or timestamp structures. Two AAC tracks can still have different sample rates, channel layouts or encoder delay. These differences may be tolerated in one workflow and cause a failed join, a short silence or an audio drift in another.
The concat demuxer is particularly dependent on compatible inputs. A simple list looks like this:
file 'part-01.mp4'
file 'part-02.mp4'
file 'part-03.mp4'
The paths must be written in the format expected by your FFmpeg build, and filenames containing special characters need care. Before using a list overnight, test the first two files and inspect the output around their join. If the second file begins late, loses sound or shows a frozen frame, the problem is easier to isolate in a small test than after several hours.
If your content comes from several editing applications, normalise it before concatenating. That may mean exporting all parts with the same settings, or re-encoding the outlier files to a common intermediate format. This is one of the situations where a small amount of preparation is safer than expecting stream copy to correct incompatible media.
For channels built from daily recordings, keep a written media specification. It might say 1280×720, H.264, progressive video, 30 fps, AAC audio at 44.1 kHz, stereo. It is easier to reject one incorrectly exported file before it enters the playlist than to diagnose a failed live output later. A market bulletin workflow may also benefit from the practical checks described in this guide to building a 24/7 update channel.
Loop one input or build a concat list
There are two different looping problems. You may want to repeat one file indefinitely, or you may want to play a sequence of files and then return to the beginning. They are not interchangeable.
For one compatible file, FFmpeg can loop the input in real time:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c copy -f flv "$YOUTUBE_RTMP_URL/$STREAM_KEY"
This is only a pattern. The copied file still needs to be suitable for the selected output container and YouTube ingest path. The -re option makes file input proceed at approximately its native playback rate rather than being read as quickly as the computer can process it.
For several files, the concat demuxer is usually clearer than repeatedly changing inputs during a live process. Create a list, validate the common stream properties, and test a short output before committing to an overnight run. If the programme has an intentional pause or a branded transition, decide whether that transition belongs in the media itself or should be generated during re-encoding.
A concat filter is a different method. It decodes the inputs, joins them in a filter graph and then requires an output encode unless the result is passed through in a way that remains compatible. It gives you more control over differing inputs, but it uses more processing and brings the usual encoding choices back into the workflow.
Do not treat -stream_loop -1 as a service recovery system. It can repeat an input, but it cannot repair a disconnected network, a crashed process, a damaged file or a rejected stream. Similarly, a concat list can define programme order but cannot guarantee that the live broadcast remains available.
For a channel that changes its content regularly, a playlist supervisor may be more suitable than one enormous concat command. That adds operational complexity, so keep the first version simple: prove that one file works, prove that two compatible files join, then test the intended repeat behaviour. If you are considering a small computer for the job, compare the actual workload with the cautions in the Raspberry Pi 24/7 streaming guide.
Select the output container and settings
The output container must match the protocol and the streams you are sending. For the RTMP or RTMPS pattern used by YouTube Live, FFmpeg commonly uses the FLV muxer:
-f flv
The FFmpeg documentation describes real-time file input with the FLV muxer sent to an RTMP destination in its RTMP and related protocol documentation. You should use the documentation for the FFmpeg version installed on your system, because available options and accepted syntax can differ between builds.
When the source is already compatible, a copy-oriented command might look like this:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c copy -f flv "$YOUTUBE_RTMP_URL/$STREAM_KEY"
Do not assume that an MP4 file can always be copied directly into FLV without checking its streams. The source container and output container are separate concerns. A file may play correctly as MP4 but contain a codec, subtitle stream or metadata arrangement that is unsuitable for the FLV output you selected.
If you need a controlled H.264 output, use explicit video and audio encoding instead. A 1080p30 example is:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-vf "scale=1920:1080" -r 30 \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-g 60 -b:v 14M -maxrate 14M -bufsize 28M \
-c:a aac -b:a 128k -ar 44100 \
-f flv "$YOUTUBE_RTMP_URL/$STREAM_KEY"
This is an implementation example, not a universal command. Check the output dimensions rather than relying on the filter if the source aspect ratio is not already 16:9. A careless scale can stretch people, logos or text. You may need padding or cropping instead.
YouTube's current live encoder guidance lists RTMP and RTMPS, H.264, H.265 and AV1, with constant bitrate recommended. It recommends a two-second keyframe interval, with no more than four seconds between keyframes. The example uses 30 fps and a 60-frame GOP to represent two seconds, but you should verify the actual cadence produced by your FFmpeg build.
For standard SDR, YouTube also lists progressive scan, square pixels, Rec. 709, 8-bit depth, two B-frames and one reference frame. Its stereo audio guidance lists AAC or MP3, 44.1 kHz and 128 Kbps. These are output considerations for an encode; stream copy will not apply them to a source that does not already match.
Use the live-specific values rather than the separate recommendations for uploaded videos. For H.264 live input, YouTube lists these minimum and recommended rates:
| Output | H.264 minimum | H.264 recommended |
|---|---|---|
| 360p30 | 0.4 Mbps | 4 Mbps |
| 480p30 | 0.4 Mbps | 4 Mbps |
| 720p30 | 3 Mbps | 8 Mbps |
| 720p60 | 3 Mbps | 8 Mbps |
| 1080p30 | 5 Mbps | 14 Mbps |
| 1080p60 | 6 Mbps | 17 Mbps |
| 1440p30 | 7 Mbps | 21 Mbps |
| 1440p60 | 8 Mbps | 34 Mbps |
| 2160p30 | 11 Mbps | 42 Mbps |
| 2160p60 | 14 Mbps | 50 Mbps |
These figures are from YouTube's live encoder settings, not a promise that a connection carrying the minimum will remain stable. If you use H.265 or AV1, consult the relevant codec column rather than copying H.264 values. YouTube's published values differ by codec.
For most general-purpose 24/7 feeds, 1080p30 at 14 Mbps is a reasonable starting target when the source and connection support it. Choose 720p30 at 8 Mbps when sustained capacity is limited or consistency matters more than fine detail. Use 1080p60 at 17 Mbps only when smoother motion has a real benefit and the complete system can sustain it. Higher resolutions should be chosen because the source and audience benefit from the detail, not because the number is larger.
Remember to allow headroom for audio and transport overhead when comparing the chosen video rate with your upload capacity. A connection that reaches the target only during a short speed test is not the same as one that sustains it through the night.
Inspect timestamps and transitions
Timestamps are often where a file-based live workflow becomes difficult. A media player may hide small timing irregularities, while a muxer or live platform reacts to them. Look for negative timestamps, large gaps, non-monotonic presentation times and unexpected duration differences between audio and video.
Useful inspection commands include:
ffprobe -v error -select_streams v:0 \
-show_entries stream=codec_name,width,height,avg_frame_rate,time_base \
-of default=noprint_wrappers=1 input.mp4
For a closer look at packet timing, inspect packet timestamps on a short sample rather than dumping an entire long file. The exact command depends on what you need to see, but the goal is to identify whether the first frame begins at the expected time and whether timestamps move forward consistently.
A clean transition requires more than placing two filenames next to each other. If the first file ends on a non-keyframe, the next video may not begin cleanly when packets are copied. If audio begins with a different delay, the join can produce a click, a short silence or a gradual sync problem. A file with variable frame rate may also behave differently from a constant-frame-rate file even when both report the same nominal frame rate.
Watch the join, do not merely check that FFmpeg exits successfully. Play the resulting short test in the same kind of player your audience uses, and observe the first seconds after the change. Then send the test through YouTube and check the Live Control Room. A local file test cannot reproduce all ingest behaviour.
If your content is mostly still artwork with music, a sharp transition may be more noticeable than a small change in image detail. For ambience channels, a brief audio discontinuity can matter more than moving from 720p to 1080p. For a news loop, readable text and correct timing may matter more than a high frame rate. These are programme decisions as much as FFmpeg decisions.
Diagnose failures and consider re-encoding
When stream copy fails, separate the failure into three questions: did FFmpeg read the input, did it produce a valid output container, and did YouTube accept and process the transmitted stream. A single error message does not always identify which layer is responsible.
Common signs of an input or concat problem include a failure at the point where the second file starts, non-monotonic timestamp warnings, missing audio after a join, a frozen first frame or a process that stops when one file ends. Signs of an output or ingest problem include a rejected stream, unstable stream health, repeated reconnects or a live picture that differs from the local test.
Start with a short command using one file. Then test the same file with the intended output container and protocol. Add the second file only after the first test is sound. This sequence prevents you from changing the playlist, encoder, network and YouTube settings at the same time.
If the inputs do not share a reliable format, re-encode them to a common output. For 720p30 H.264, use 8 Mbps as YouTube's recommended live input rate and 3 Mbps as its listed minimum. For 1080p30 H.264, use 14 Mbps as the recommended rate and 5 Mbps as the minimum. Select CBR behaviour, a two-second keyframe interval and audio settings that match the target output.
Re-encoding consumes processor capacity and can introduce its own failure modes. A slow preset may not keep up with real time, especially at a higher resolution. Test CPU use, temperatures and output timing with the most demanding representative file, not only with a static slide. If the computer cannot encode reliably, lowering the resolution or frame rate may be more useful than forcing a higher target.
FFmpeg also documents FIFO output options intended to keep processing at real-time rate during temporary output failures and to attempt recovery. Those options can be part of a carefully tested deployment, but they do not guarantee that YouTube preserves one live event, prevents an outage or accepts every reconnection. Keep logs, rotate them sensibly and make sure a stream key is never exposed in logs or published examples.
If the main problem is that your computer must remain on and recover the process overnight, StreamNeo removes that particular operational burden by taking an uploaded video, connecting it to your YouTube channel and handling the continuing run without your computer being switched on. It does not change the need to prepare compatible media or check YouTube's current rules.
Test the full YouTube ingest path
A reliable preflight includes the source file, FFmpeg output, local connection and YouTube's own ingest view. YouTube advises choosing a quality that results in a reliable stream for your internet connection, then testing before starting the real broadcast. Its live encoder settings are the current reference for codec, bitrate, keyframes and related output choices.
First measure sustained upload capacity, not only a brief peak. Compare it with the selected video bitrate, audio and transport overhead. If the connection varies widely, choose the lower target that it can sustain rather than selecting a nominal rate that is reached only occasionally. If you use Wi-Fi, test from the exact location and equipment that will run the stream, or use the connection arrangement intended for the final deployment.
Next run a representative programme. Include ordinary movement, the busiest graphic or ticker, the loudest audio section and at least one file transition. A devotional loop with a static image is not a sufficient test for a news package with animated text. Likewise, a quiet ambience file may not reveal an audio issue that appears in a spoken announcement.
Open YouTube Live Control Room and inspect stream health and messages while the test is running. Confirm the received resolution and frame rate. YouTube can detect settings automatically, while manual resolution selection is available through a custom stream key. Do not assume that the dimensions reported by ffprobe are exactly what the platform receives after your filters, encoder and muxer have run.
Let the test continue long enough to expose an unstable connection, rising computer temperature, a timestamp issue or an unexpected process exit. The right duration depends on your deployment and risk tolerance; the point is to test the whole path rather than infer reliability from a successful start.
After the test, review the FFmpeg log and YouTube's messages together. Note the actual output settings, start time, transitions, reconnects and any gaps. Keep a copy of the working command with the stream key replaced by a placeholder. For future changes, alter one variable at a time.
YouTube Live latency is a separate choice from bitrate and resolution. If viewers need to interact with the channel, read how Normal, Low and Ultra-low latency affect loops before changing that setting. For a meditation or bhajan channel, the wider content and rights questions also deserve attention; the guide to 24/7 aarti and mantra streams covers that broader operating context.
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 bitrate should I use for a 1080p30 H.264 YouTube stream?
YouTube lists 5 Mbps as the H.264 minimum and 14 Mbps as the recommended input bitrate for 1080p30. Use 14 Mbps when your connection and encoder can sustain it reliably, rather than treating the minimum as a target for every setup.
Is stream copy better than re-encoding for a 24/7 stream?
It can reduce processor use and avoid another encode, but only when the input files, timestamps, codecs, streams and output container are compatible. Re-encode when you need to standardise resolution, frame rate, codec, audio or keyframe behaviour across different files.
Can I use -stream_loop -1 to guarantee an endless YouTube broadcast?
No. It repeats a file, but it does not guarantee that FFmpeg, your computer, your connection or YouTube will remain available. Test the complete ingest path and treat process recovery, network continuity and platform behaviour as separate risks.
Is 720p30 acceptable for a continuous channel?
Yes, when lower bandwidth or simpler encoding is more important than fine detail. YouTube lists 8 Mbps as the recommended H.264 input bitrate for 720p30 and 3 Mbps as the minimum, but the result still depends on the source, connection and live test.