You can run a local playlist through FFmpeg on a Raspberry Pi 4 and send it to YouTube Live using the stream URL and key from YouTube Studio. The Pi can play the files and act as the encoder, but the resolution, bitrate and continuous performance must be tested on your own board, media and internet connection.
The important detail is option placement: -stream_loop -1 belongs before the input it loops. For several separate files, use a supported concat list rather than assuming that this option alone understands every playlist format.
What you need before starting
You need a Raspberry Pi 4 Model B with Raspberry Pi OS installed, local storage containing the media, FFmpeg, a YouTube channel permitted to use live streaming, and an upload connection that you can test for sustained use. You also need a suitable USB-C power supply. Raspberry Pi specifies 5 V at 3 A, or 15 W, for the Raspberry Pi 4 Model B in its current getting-started documentation, as listed on Raspberry Pi's site in October 2026: Raspberry Pi's power guidance.
That specification describes the supply rating. It does not prove that a particular adapter, cable, board, case or USB accessory will behave well in your room. Use a power supply intended for the board and avoid treating a random phone charger as equivalent. If your area has power interruptions, consider how the Pi will restart and whether the stream should be checked after a restart. This is a resilience question for your installation, not something the FFmpeg command can solve.
Keep the playlist media on storage that the Pi can read consistently. A local directory is easier to troubleshoot than files spread across removable devices or network shares. Leave enough free space for the operating system, logs and any temporary files you create while preparing media. The official sources do not establish a required SD-card size for this workflow, so choose storage based on your files and test it rather than relying on a universal figure.
Use only material that you have permission to broadcast. That might be music you made, licensed devotional content, commissioned videos, public-domain material where the relevant rights really apply, or recordings for which you have permission. A file playing successfully on the Pi does not settle copyright, channel eligibility or YouTube policy questions. Check the current YouTube Studio status and the rights attached to each item before making the channel public. You can also read whether YouTube allows looping the same video in a live stream for the difference between technical looping and the platform questions around it.
Before choosing a command, inspect the FFmpeg build installed on the Pi:
ffmpeg -version
ffmpeg -encoders
ffmpeg -muxers
The exact package version and available encoders depend on your operating system and installation. Do not assume that a command copied from another Raspberry Pi contains the same codecs or hardware support. If an encoder name is missing, select one that your installed build reports or change the approach after checking the build documentation.
Check the Pi, power and local network
Start with a short diagnostic session before attempting an overnight broadcast. Confirm the board model, check that the clock is correct, verify that the media directory is readable, and make sure the Pi can reach the internet. A command can be syntactically valid while the system still has a failing cable, a full filesystem or an unreliable route to YouTube.
A wired Ethernet connection is a sensible practical choice for a fixed streaming device because it removes one local wireless link from the path. It is not a guarantee of upload capacity or uninterrupted streaming. If you must use Wi-Fi, test from the exact position where the Pi will remain, with the same router and other household activity that will be present during the real broadcast.
Measure the upload connection at a time representative of your planned schedule. Do not use a brief result as proof that a long broadcast will remain healthy. Watch for changing upload capacity, packet loss, data limits imposed by your connection, and local congestion. India contains many different fixed-line and mobile network arrangements, so there is no single India-specific result that can be applied to every home, office or shop.
Power and networking should be checked together. A stream may stop because of a power interruption, a loose cable, a router restart, a thermal problem or an FFmpeg process that has exited. YouTube's stream-health panel can show ingest problems, but it cannot tell you every local cause. Keep the Pi somewhere ventilated, avoid blocking its case openings, and observe its behaviour during a representative test. Do not treat an unmeasured temperature, CPU load or uptime as a known result.
If your goal is an unattended devotional, ambience or local-information channel, decide what happens after a reboot. The simple version is to log in and start FFmpeg manually. A more dependable operating plan uses a startup service or a small supervision script, but that adds another configuration layer that must itself be tested. First prove that the media, command and YouTube connection work manually. Automate only after you can diagnose a normal start and a normal stop.
A 24/7 channel also needs a content plan, not just a process that never exits. The guidance in how often to change content on a 24/7 YouTube stream can help you think about repetition, freshness and what viewers should expect from the schedule.
Prepare the playlist and media files
There are two different tasks here: looping one input file and cycling through several files. FFmpeg documents -stream_loop as an input option. The indefinite form is -stream_loop -1, and it must appear before the input to which it applies. FFmpeg's documentation explains the general rule that options usually apply to the next input or output, so see the FFmpeg command-line documentation when adapting the examples.
For one file, the relevant shape is:
ffmpeg -stream_loop -1 -i input.mp4 ...output-options... output-url
The position is not decoration. This is different from putting -stream_loop -1 after -i input.mp4, where it may no longer apply to that input as intended. When a command has several inputs, option scope becomes even more important. Read the command from left to right and identify which input each option controls.
For separate files, make a concat list. Create a plain text file such as playlist.txt:
file '/home/pi/media/morning.mp4'
file '/home/pi/media/bhajan-02.mp4'
file '/home/pi/media/quiet-loop.mp4'
Use paths that exist on your Pi. If a filename contains an apostrophe, whitespace or unusual characters, follow the concat demuxer's escaping rules rather than copying this example unchanged. Keep the list in a directory you can back up and edit. You should also confirm that each path is readable:
while IFS= read -r line; do
printf '%s\n' "$line"
done < playlist.txt
A concat list is not a magic conversion step. Files with different dimensions, frame rates, codecs, sample rates or time bases may not join cleanly through a stream-copy workflow. A playlist assembled from files with matching technical properties is easier to operate. If your sources differ, you may need to decode and re-encode them into one consistent output, which increases the work required from the Pi.
You can inspect each file before building the live command:
ffprobe -v error -show_streams -show_format /home/pi/media/morning.mp4
Look for the video dimensions, frame rate, codec, audio presence and sample rate. You do not need every file to be identical for every possible FFmpeg workflow, but you do need to know what changes at each transition. A short test that contains only one easy file will not reveal whether the third item has a missing audio stream or a format that causes the process to fail.
Decide what should happen at the end of the list. A concat input can read the entries in sequence, but indefinite repetition of a multi-file list depends on the input method and command you choose. Do not append -stream_loop -1 and assume it turns every arbitrary playlist file into a robust 24/7 schedule. Test the exact list, including the transition from its last entry back to its first, before connecting it to a public broadcast.
If the source material is primarily static imagery or long ambience footage, reducing unnecessary processing may matter. The article on making a 24/7 ambient stream use less CPU with FFmpeg is relevant, but any lower-processing method still needs to be checked against your source files and the encoders available in your build.
Create the YouTube Live encoder stream
Open YouTube Studio and create or select the live stream that will receive the Pi's output. In the encoder workflow, YouTube provides a stream server URL and a stream key. FFmpeg needs both values in its output configuration. YouTube's encoder setup instructions describe this workflow and note that first-time live-stream activation may take up to 24 hours, as listed on YouTube Help in October 2026.
Treat the stream key like a password. Do not put it in a public screenshot, commit it to a public code repository or paste it into a support forum. If you believe it has been exposed, use YouTube Studio's available key-management controls and update the FFmpeg command with the replacement.
YouTube recommends RTMPS as the secure option for encoder ingest. Copy the complete server address shown in Studio rather than manually shortening or reformatting it. The exact URL and key belong to your channel's live setup, so use placeholders while writing or testing shell scripts:
rtmps://your-server-address/your-path/STREAM_KEY
Do not start with an assumption that the broadcast is public. Use the visibility and scheduling controls in YouTube Studio to choose the intended workflow. Start FFmpeg, watch for the incoming preview and inspect the stream-health messages in Live Control Room. Depending on the stream setup, you may then need to start or confirm the broadcast in Studio.
The first test should use representative media. Include the loudest expected audio, a scene with normal movement, a transition between files and enough runtime to expose obvious failures. A five-minute test can reveal a wrong key or absent audio, but it cannot establish how your Pi behaves overnight. Treat it as a staged check, not proof of uninterrupted operation.
Build the FFmpeg loop command
A live output normally needs a video encoder, an audio encoder, a container suitable for the YouTube ingest protocol and a destination URL. YouTube's published H.264 recommendations include 720p30 at 3–8 Mbps and 1080p30 at 5–14 Mbps, as listed on YouTube Help in October 2026. These are ingest recommendations, not a promise that your Pi or Indian upload connection can sustain either choice.
A command template for one repeatedly looped input might look like this:
ffmpeg \
-re -stream_loop -1 -i /home/pi/media/channel.mp4 \
-c:v libx264 -preset veryfast -b:v 4000k -maxrate 4000k -bufsize 8000k \
-r 30 -g 60 \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://YOUR_SERVER/YOUR_STREAM_KEY"
This is a template, not a tested Raspberry Pi 4 result. The -re option asks FFmpeg to read the input at its native rate rather than sending a file as quickly as possible. -stream_loop -1 is placed before the input. The video bitrate, frame rate, GOP setting, audio rate, encoder and preset must be checked against your build, source and connection.
YouTube recommends constant bitrate, a keyframe every two seconds and no longer than four seconds, plus AAC or MP3 audio for RTMP or RTMPS. In the example, -r 30 and -g 60 express a two-second GOP if the actual output frame rate is 30 frames per second. If you change the frame rate, recalculate the relationship instead of leaving the values unexplained. The recommendation is from YouTube's encoder settings guidance, not from a Raspberry Pi benchmark.
The example's 4 Mbps video rate sits within YouTube's stated 720p30 range, but that does not make 720p30 guaranteed on your board. It is also not a universal choice for every source. Start with a setting appropriate to your connection and content, then watch YouTube's stream health and the Pi's behaviour. A high-motion source can require more work than a mostly static image, while a small source can make a higher output resolution wasteful.
If your build includes a suitable hardware-assisted encoder, you may investigate it, but do not insert a hardware encoder name without confirming that ffmpeg -encoders lists it and that its options match your command. Hardware support, driver state and image packages vary. If you cannot explain what a selected encoder does on this particular Pi, use a short private test rather than making it the basis of an unattended channel.
For multiple files, one possible starting shape is:
ffmpeg \
-re -f concat -safe 0 -i /home/pi/playlist.txt \
-c:v libx264 -preset veryfast -b:v 4000k -maxrate 4000k -bufsize 8000k \
-r 30 -g 60 \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://YOUR_SERVER/YOUR_STREAM_KEY"
This command reads a concat list once. It does not, by itself, establish an endlessly repeating multi-file playlist. You need to test the concat method and then choose a repeat strategy that works with the exact files and FFmpeg build. One approach is to place the command in a supervision loop that starts it again when the list ends, but that creates a new process and may cause a visible break in the live output. Another approach is to create a single prepared media file that already contains the desired sequence and loop that file. Each approach has trade-offs.
Do not use a concat stream-copy shortcut merely because it reduces CPU use. If the files are not compatible, transitions can fail or produce bad timestamps. Re-encoding the prepared sequence can take more time and storage, while stream copying can preserve the original streams only when the inputs and output requirements line up. The right choice is input-dependent.
Choose between 720p30 and 1080p30 carefully
YouTube's published ranges give you a useful comparison, but they do not answer the Pi-specific question. The following figures are YouTube's H.264 ingest recommendations as listed on YouTube Help in October 2026:
| Output target | YouTube-recommended video bitrate | What you must still test |
|---|---|---|
| 720p30 | 3–8 Mbps | Upload stability, source quality, encoder load and transitions |
| 1080p30 | 5–14 Mbps | Higher upload demand, source quality, encoder load and transitions |
A lower target may be easier for a constrained upload connection, but it can make detailed text, small news tickers or busy scenes less clear. A higher target may preserve more detail, but it asks more from the connection and may ask more from the encoding path. Neither row proves that a Pi 4 will sustain the workload continuously.
Test from the actual location and connection. Run the intended command with representative content, check for dropped frames and stream-health warnings, and observe whether the Pi remains responsive. If the upload becomes unstable, reduce the demand one variable at a time. Do not change resolution, frame rate, encoder, bitrate and audio simultaneously, because you will not know which change helped.
For a devotional or music channel, audio continuity may matter more than maximum picture detail. For a local news loop, readable text may matter more than a large canvas. For a study channel, slides and screen recordings can expose scaling or small-font problems. Choose from what viewers need to read or see, then verify what the Pi and connection can deliver.
Test output and monitor the broadcast
Begin with a private or otherwise controlled test in YouTube Studio. Confirm that the preview appears, audio is present, the aspect ratio is sensible and the stream-health panel is not reporting an ingest problem. YouTube explicitly recommends testing before starting a live stream; follow that advice rather than making the first public broadcast your systems test.
Watch the FFmpeg terminal as well. An advancing frame count and encoded time do not by themselves prove that viewers are receiving a healthy stream. Look for connection errors, repeated reconnects, audio messages, timestamp warnings and an early process exit. Save the command and its output in a private log so you can compare a successful run with a failed one.
Check the transitions. Let the first file finish, observe the next file, and if you have a repeat method, watch the return to the beginning. Listen for an audio gap or sudden level change. Confirm that a file with different dimensions or no audio does not break the process. A playlist is only as reliable as its least compatible entry.
Check the system during the test rather than only at the start. Watch CPU use, memory pressure, storage space, network activity and temperature with the tools available in your Raspberry Pi OS installation. The official sources used for this guide do not provide a measured CPU limit, temperature result or maximum continuous resolution for this exact workflow. Record what your own Pi does under the intended load.
A long unattended stream needs an incident plan. Decide who will receive an alert, how you will access the Pi, where the stream key is stored, and what you will do if the process stops. A shell loop can restart FFmpeg after an exit, but indiscriminate restarting can hide a bad input, a rejected key or a full disk. Add logging and inspect the reason for failure before making automatic restarts part of the routine.
If you do not want the channel to depend on a powered-on home computer, StreamNeo removes the specific task of leaving the Pi or another local machine running: upload the finished video, add the YouTube stream key, and let the broadcast run from the cloud with automatic monitoring and restarts. It is YouTube-only, so it does not replace this Pi workflow where local encoding or another destination is required.
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 one FFmpeg file forever?
Place -stream_loop -1 before the input it applies to, as in ffmpeg -re -stream_loop -1 -i input.mp4 .... It is an input option, so placing it after the input can change its effect. Test the exact command with your installed FFmpeg build before connecting it to a public stream.
How do I loop several files on YouTube Live?
Use a concat list or prepare one combined file, then test the chosen repeat method. -stream_loop -1 does not automatically understand every arbitrary playlist format, and separate files may have incompatible codecs, dimensions or audio streams. Watch the transition from the last item back to the first.
What bitrate should I use for YouTube Live from India?
YouTube lists H.264 recommendations of 3–8 Mbps for 720p30 and 5–14 Mbps for 1080p30, as listed on YouTube Help in October 2026. These ranges are not an India-wide network guarantee or a Pi 4 performance result, so test the upload connection and stream health from the actual installation.
Can a Raspberry Pi 4 run this continuously?
The documented command does not establish a guaranteed resolution, CPU load or uninterrupted runtime on every Pi 4. Media format, encoder availability, power, cooling, storage and the upload path all matter. Run a representative long test and plan how you will detect and recover from a stopped process.