A Raspberry Pi can send an FFmpeg stream to YouTube Live, but keeping it running through a monsoon outage depends on the whole chain: input hardware, power, network equipment and the internet connection. Start by mapping what the stream needs, then measure upload capacity, back up the essential devices and test recovery on the setup you will actually use.
There is no universal UPS size or India-wide network choice that can guarantee continuity. A battery that keeps the Pi on does not help if the router or ONT loses power, and an automatic FFmpeg restart cannot repair a dead input or unavailable internet connection.
Map the complete Pi-to-YouTube chain
Write down every component that must work for viewers to see and hear the stream. A typical chain might be a camera or capture device, Raspberry Pi, storage, router, modem or ONT, and the ISP’s network. Add a powered switch, USB audio interface, fan or other accessory if the stream depends on it. If you are playing a file rather than capturing a camera, note where that file is stored and whether the Pi can read it after a restart.
For each item, record its power source, connection type and what failure looks like. A camera might freeze while the Pi remains online; an ONT could lose power while Wi-Fi still appears available; a USB drive might not remount after reboot. These differences matter because a green power light on the Pi does not prove the broadcast is reaching YouTube.
Separate the chain into three questions: can the Pi keep producing the intended video and audio, can every required device stay powered, and can data travel from the Pi to YouTube? Identify which components are shared with household use. A router that someone switches off at night, for example, is not a dependable always-on component even if its power backup is adequate.
This inventory also helps decide whether a small computer is the right fit. If the workload is a simple compatible file loop, the Pi may be suitable; if the job requires substantial transcoding or several inputs, test that exact workload rather than assuming a board can handle it. For another perspective on the trade-offs of a local machine, see keeping a podcast stream running on an old laptop.
Measure upload capacity and set a conservative stream
Measure stable outbound upload from the actual connection and at the times the stream will run. A single speed-test result is only a snapshot; repeat measurements under ordinary household conditions and note whether other people or devices are using the link. Where possible, use a wired connection between Pi and router to remove Wi-Fi variability from one part of the chain.
YouTube’s streaming tips say the total stream bitrate must remain below available upload bandwidth and recommend leaving 20% headroom. Treat that margin as a starting constraint, not a guarantee against congestion or an ISP interruption. If the connection is inconsistent, choose a lower video bitrate or a less demanding resolution and frame rate so that normal variation is less likely to push the stream over capacity.
YouTube’s current encoder settings guidance recommends RTMPS where supported, constant bitrate, and a two-second keyframe interval, with four seconds as the maximum. Its H.264 guidance lists different bitrate recommendations by resolution and frame rate: for example, 720p30 is listed at 3 Mbps, while 1080p30 is listed at 14 Mbps. These are platform recommendations, not a promise that a particular Pi can encode that mode or that your connection will sustain it. Check the live table before choosing settings because codec and output mode affect the recommendation.
Keep the aggregate bitrate in view: video, audio and any overhead all travel over the same upload connection. Select the lowest output quality that serves the channel well and remains within measured capacity with headroom. If your source is already encoded in a compatible format, a workflow that avoids transcoding may reduce the Pi’s work, but confirm that the actual file, FFmpeg command and audio path behave as intended. The FFmpeg loop settings for a 4K 60fps cloud stream are useful context for understanding how demanding a different environment can be, not a preset to copy onto a Pi.
Plan backup power for the devices that matter
A Raspberry Pi UPS is only one part of the plan. List every essential powered device and decide whether it needs to remain on during a cut: the Pi, camera or capture device, router, modem or ONT, and perhaps a switch. If any required link goes dark, the stream can stop even when the Pi continues running. Avoid buying a battery based only on the Pi’s model name or a seller’s claimed runtime for a different load.
Match the Pi’s supply to the board. Raspberry Pi’s power supply documentation gives model-specific recommendations: it lists 5 V at 5 A for Raspberry Pi 5 and 500, with peripheral current limited when using a 3 A supply; Raspberry Pi 4 and 400 are listed at 5 V, 3 A, and Raspberry Pi 3 at 5 V, 2.5 A. Verify the current guidance for your exact model and consider connected USB devices, cable quality and voltage loss. A supply’s maximum rating is not the same as the board’s measured consumption or an estimate of battery runtime.
For each UPS or battery option, check output voltage and connector compatibility, transfer behaviour, supported load, usable capacity under that load, and whether the system can signal a clean shutdown. Measure power draw in the deployed configuration if you need to estimate runtime. A vendor’s runtime figure may assume a different load, battery condition or operating mode, so do not treat it as your expected outage duration without checking the assumptions.
The router and ONT may need separate backup arrangements or a UPS with suitable outputs. Then check whether your ISP’s local equipment and service remain available during a mains cut at your address. Powering a home ONT does not prove that the provider’s equipment serving the area has backup power. Cellular service is not a universal fallback either: coverage, congestion and local power arrangements vary. Ask the provider about the specific connection and test the alternate path where you plan to use it.
If your battery system exposes status and your software supports it, plan a clean shutdown before charge is exhausted. Sudden loss of power can risk storage integrity, and a corrupted boot medium can turn a short outage into a longer recovery. A Raspberry Pi power supply or clock battery is not an outage backup. Consider whether the content and configuration can be restored if storage is damaged, rather than relying on a single card as the only copy.
Configure and observe FFmpeg and YouTube
Treat process supervision as one layer of recovery, not as proof that the stream is resilient. A service manager or watchdog can restart FFmpeg after it exits, but it cannot supply missing camera input, restore credentials, reconnect a failed ISP circuit by itself, or correct an exhausted battery. Decide what should happen after each fault before enabling automatic retries: repeated rapid restarts may obscure the original problem and make logs harder to read.
Use the current FFmpeg documentation for the options appropriate to your input, output and installed version. There is no single reconnect command that is safe to prescribe for every input and deployment. Test whether a temporary network loss leaves the process waiting, causes it to exit, or produces a stream YouTube no longer accepts. Confirm separately what happens after a clean Pi reboot, a power interruption, and a camera or file-input failure.
In YouTube Live Control Room, observe stream health during a private or otherwise controlled test. YouTube advises testing the complete stream before going live and monitoring its health; its guidance also discusses backup encoder failover. A second encoder only helps if it is configured, powered and connected independently enough to cover the failure you are addressing. If both encoders rely on the same router, ONT and power source, they may fail together.
Record enough information to tell what happened: FFmpeg logs, service restart events, Pi uptime, UPS status if available, and the time YouTube stopped receiving the stream. You do not need to watch every log line continuously, but you do need a way to distinguish “FFmpeg exited” from “the process is running but cannot reach YouTube”. A channel owner who wants to avoid leaving a home computer responsible for file playback and process recovery can use StreamNeo to turn an uploaded video into a YouTube live stream without keeping that computer on; it does not replace checking the channel setup or connectivity assumptions.
Test outages and recovery on the real setup
Do not infer recovery from a configuration file or a successful desk test of the Pi alone. YouTube recommends testing the complete stream before going live. Use a private test broadcast or another controlled arrangement, with the same Pi, capture device, power backup, network path, FFmpeg settings and YouTube event you intend to use. Check video and audio at the viewing end as well as health in Live Control Room.
Run failure tests separately so that the result is interpretable. First test a controlled mains interruption while the Pi and required network equipment are operating. Confirm that the power transfer does not reboot the Pi or produce undervoltage, and that the camera, router and ONT remain on. Then test a brief network interruption, observing whether FFmpeg reconnects, exits or needs intervention. Finally, test process restart and a full reboot after power restoration. Avoid deliberately exhausting a battery unless its manufacturer’s instructions and your recovery plan make that safe.
For each test, write down the initial conditions, what failed, what viewers saw, how long recovery took in that run, and what action was needed. A single successful test proves only that this particular scenario worked once; it does not establish a runtime guarantee or cover a longer outage, degraded mobile coverage, a different camera fault or battery ageing. Repeat after changing the UPS, OS, FFmpeg command, router or capture path.
Also verify the YouTube side of recovery. A recovered FFmpeg process does not necessarily mean the stream event and player behave as you expect. Check whether the same event resumes, whether YouTube reports a healthy incoming stream, and whether audio and picture are present. If you use a backup encoder, test a real handover rather than assuming that two configured outputs will fail over cleanly. Keep a manual fallback plan for cases the test cannot cover, such as an ISP outage that lasts longer than the battery can support.
Diagnose whether the failure is power, network or process
When the stream stops, avoid changing several things at once. First establish which part of the chain is still alive. Check whether the Pi is powered and reachable, whether its input is present, whether the router and ONT show normal status, and whether the internet connection is available from another device. Then inspect FFmpeg logs and YouTube’s health display for the same time window.
| What you observe | Likely area to check | Useful next check |
|---|---|---|
| Pi has rebooted or shows undervoltage symptoms | Power, cable or load | Review supply, UPS transfer, USB load and cable condition |
| Pi is reachable but input is missing | Camera, capture device or storage | Check device detection, file mount and input-specific logs |
| FFmpeg is running but YouTube receives no data | Network path or output session | Test route and DNS, inspect output errors, check router and ONT |
| FFmpeg has exited | Process, input error or invalid output | Read the final log lines before restarting and verify the service manager |
| YouTube reports poor stream health while the process remains active | Upload capacity or encoding settings | Compare measured upload, bitrate, frame rate and encoder load |
These clues are not diagnoses by themselves. For instance, an active Wi-Fi connection can coexist with an offline ONT, and a running FFmpeg process can still be blocked on a dead input. Use the failure record from your tests to narrow the possibilities, and change one part of the setup at a time.
If the Pi repeatedly reboots, look for supply mismatch, cable voltage drop, peripherals drawing more power than expected, or UPS transfer behaviour. If the Pi stays up but upload disappears, focus on the router, modem/ONT and provider path rather than increasing the Pi’s battery. If FFmpeg alone exits, address the specific logged error and then test the restart behaviour. A restart loop may make the display look active without restoring a valid stream.
For a file-based channel, keep source files and the working command documented in a place you can reach if the boot card fails. The guide to making an always-on stream from a playlist in Google Drive illustrates a different source workflow; whichever method you use, confirm how it behaves when its storage or network dependency disappears.
Build a continuity checklist for your location
Before leaving the setup unattended, make a one-page record with the Pi model and supply, attached peripherals, source type, encoder settings, tested upload conditions, backup power coverage, and the network devices that remain powered. Include the date of the last complete-chain test and the faults it covered. This is more useful than a generic recommendation because it captures the actual equipment and provider path at your premises.
Review the checklist whenever something changes: a new USB device, a different resolution, a router replacement, an ISP plan or a battery with a different output. Each change can affect power draw, encoding load, network stability or recovery. If your stream is business-critical, decide who will receive an alert and what manual action they can take when an outage exceeds the tested case.
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 keep my YouTube live stream running during a power cut?
Back up every device the stream requires, not only the Pi, and test a controlled interruption with the complete chain online. Also confirm that the ISP connection remains available at your location during a mains cut; a powered router alone does not establish that.
How do I restart FFmpeg automatically if it disconnects?
A service manager can restart FFmpeg if the process exits, but a network interruption may leave it running or require different handling. Check the FFmpeg documentation for your version and input, then test process exit, network loss and reboot separately on the deployed setup.
What UPS do I need for a Raspberry Pi and router?
There is no universal size: the answer depends on the Pi model, peripherals, router, modem or ONT, measured load, connectors and the runtime you need. Confirm compatible output and transfer behaviour, then estimate and test runtime with the actual devices connected.
Will my internet work during a power outage in India?
It depends on the provider, access technology and local network equipment serving your address. Ask your ISP about backup arrangements for the exact connection and test any alternate route where you will use it; no nationwide option can be assumed to stay available.