A Raspberry Pi FFmpeg stream can keep sending video through a mains power cut only if every local device needed to upload it also stays powered. Back up the Pi and its suitable supply, plus any router, modem or optical network terminal (ONT) that loses power; a Pi battery alone cannot preserve a broadband connection that has gone dark.
Even with the full local chain on backup, your stream still depends on the ISP and its upstream network. You can reduce the chance that a local power cut stops your broadcast and test how your setup behaves, but no UPS or battery can guarantee an uninterrupted stream.
Map the local chain before buying backup
Trace the signal from the video file to YouTube. In a simple setup, FFmpeg reads a file from storage on the Raspberry Pi, encodes or packages the audio and video, and sends the result over the home network to the internet. The local equipment between the Pi and the ISP connection is part of the stream, not an optional extra.
Draw your own chain, including anything that is easy to overlook:
| Device or link | What it does | Check during a power cut |
|---|---|---|
| Raspberry Pi and power supply | Runs FFmpeg and reads the source file | Does the Pi remain powered without low-voltage warnings or reboots? |
| Storage, if separate | Holds the file or other input FFmpeg needs | Is it powered from the Pi, or does it need its own supply? |
| Router | Connects the Pi to the local network and often provides Wi-Fi or Ethernet routing | Does it stay powered, and does its WAN connection remain available? |
| Modem or ONT | Connects the premises to the broadband provider’s access network | Does it lose power during an outage, and is it backed up? |
| ISP and upstream network | Carries traffic beyond your premises to YouTube | Is the provider’s network still working? Your local battery cannot answer this. |
Some homes have a router and ONT as separate units; others have an integrated device, and some broadband connections use a modem. Check what is physically installed rather than assuming the router is the only network device. The ONT is usually a small box where fibre enters the premises. If it switches off, the router may remain lit but still have no path to the internet.
Also note how each item receives power. A Pi powered from a USB-C adapter, router on a DC barrel plug, and ONT on a separate adapter may require different backup outputs. A multi-output UPS can be convenient, but only if its voltage, current capacity, connector and battery-backed sockets suit each load. Do not connect a device to an output merely because the plug fits.
This chain map helps distinguish a power fault from a network or software fault later. It is useful whether the stream is devotional music, a Hindi news loop, or an ambience channel. If the broadcast uses a repeating audio programme, the advice on looping meditation video with FFmpeg can help you check the source side separately from its power supply.
Identify the Pi and its power requirement
Before choosing a battery or UPS, identify the exact Raspberry Pi model and the board’s power input. Raspberry Pi’s official computer setup documentation gives recommended supply information for current models. It lists 5 V at 5 A for Raspberry Pi 5, while a 3 A supply limits current available to peripherals; Raspberry Pi 4 Model B uses 5 V at 3 A. These are supply recommendations, not measurements of how much power your stream will use or how long a battery will last.
Pi 3 and earlier models have different connectors and requirements, so do not carry a Pi 4 or Pi 5 assumption over to an older board. Confirm the model from its markings or the system information, then check the corresponding official guidance. If you have a case, fan, camera, USB storage or another peripheral attached, account for it too. The board’s requirement is not necessarily the entire load of the equipment connected to it.
Output labels matter. A battery pack may advertise a large capacity but have a USB port that cannot sustain the voltage and current your board needs. A long or poor-quality cable can also lose voltage before power reaches the Pi. Use a compatible supply and cable, and check the UPS documentation for its output under battery operation, not only its mains pass-through behaviour.
A Raspberry Pi UPS HAT is a board-level approach, but it does not automatically power a separate router, modem or ONT. A general UPS can serve multiple devices if it has the right outputs and enough capacity, but its Pi output still needs to meet the model’s requirements. If you are comparing products, check compatibility, which outlets are backed by the battery, and stated runtime under a load near your own. No specific unit has been validated here, so treat vendor specifications as claims to verify for your equipment.
Do not diagnose an unstable stream as a software problem until you have checked supply quality. A Pi that undervolts or reboots can interrupt FFmpeg even when a battery indicator says it is charged. The supply should work for the actual board and peripherals during battery operation, not just appear to match the connector.
Include the broadband equipment in the backup plan
A mains cut can stop the stream in two separate places: the Pi can lose power, or the broadband equipment can lose power. If the Pi remains on but the router or ONT does not, FFmpeg may continue running locally while its connection to YouTube fails. This is why the backup boundary must include every device in the local upload chain that requires mains power.
Check the labels on the router and ONT adapters for output voltage, current and polarity. Then check the backup unit’s specifications for compatible outputs and the total load it supports on battery. A common practical arrangement is a UPS with AC outlets for the Pi’s normal supply and network adapters, but confirm that those outlets remain live during an outage and that their combined load is supported. A DC UPS may reduce conversion steps for compatible equipment, but output matching and connector polarity still matter.
Place the equipment so that its power cables can reach the battery-backed outputs without strain. Label the adapters before connecting them, especially if the router and ONT use similar plugs. Avoid improvised splitters or adapters unless their ratings and wiring are suitable. If a device has an unexpectedly high startup draw, or the UPS reports an overload when the chain starts, reassess the arrangement rather than repeatedly resetting it.
If your broadband equipment is in a different room or is powered from a different socket, factor that into the plan. A battery beside the Pi does not help a router elsewhere unless it can safely power it too. Conversely, if the network provider’s access equipment outside your premises loses power, your local backup cannot keep that part of the connection alive.
Think of the aim as maintaining the premises-side chain, not making the whole internet independent of electricity. A pre-recorded YouTube live stream using XSplit has the same basic dependency: its local encoder and broadband equipment need power, whatever software produces the stream.
Estimate runtime for your actual workload
There is no reliable fixed runtime for “a Raspberry Pi and router”. Runtime depends on the battery and UPS, the devices attached, conversion losses, battery age and condition, and how much capacity remains available. It also depends on your outage target. A setup intended to ride through a brief interruption is a different requirement from one expected to operate for an extended cut.
Start with the equipment, not the UPS’s headline VA rating. VA is a sizing specification, not a promise of hours. List the Pi and its supply, router, modem or ONT, plus any separately powered storage or network switch. Where available, use each device’s power rating as an initial estimate, but remember that an adapter’s maximum output rating is not necessarily the device’s typical draw. A plug-in power meter can help measure an assembled mains-powered chain, if used safely and within its rating.
Then compare that load with the UPS’s stated runtime information. Look for the load basis and the conditions used; a runtime figure at a substantially different load is not directly comparable. Battery condition matters too, and a battery that has aged or been left discharged may perform differently from a new one. If a vendor does not provide a comparable runtime basis, do not turn its capacity label into a confident number of hours.
A useful planning table might look like this:
| Item | Supply or rating to record | Included in the backup test? |
|---|---|---|
| Pi and attached peripherals | Board model, required supply, attached USB devices | Yes |
| Router | Adapter output and any device rating available | Yes |
| Modem or ONT | Adapter output and any device rating available | Yes |
| Other essential equipment | Storage, switch or active cooling if needed | Yes, if the stream depends on it |
| Battery or UPS | Supported load and runtime conditions from its documentation | Compare with the whole chain |
If you later remove a device or change the Pi, recalculate and retest. The stream’s video settings influence network bandwidth and may influence encoding load, but they do not turn an unknown UPS runtime into a known one. YouTube advises selecting a stream quality that fits the available connection and testing with content similar to the real event. Its live encoder guidance is a useful starting point for configuring a stream, not a guarantee about your home’s upload path.
For a 24/7 channel, plan a test at the real resolution, bitrate, audio and motion rather than leaving FFmpeg idle. A mostly static image and a busy news loop may exercise the encoder differently, while both still need the same local power chain. Monitor battery status if the UPS provides it, but use observed runtime from a controlled test of your own equipment as the practical check.
Run a controlled interruption test
Test the complete setup before relying on it overnight. Choose a time when a short stream interruption is acceptable, tell anyone who depends on the channel, and keep a way to restore normal power. A power test can drop the broadcast even when the battery behaves as expected, so do not begin with an important live programme.
First run the channel on normal power and check that FFmpeg is publishing and YouTube Live Control Room shows an incoming stream in good health. Note the displayed stream health and confirm that the expected audio and picture are present. If your setup uses a local monitor, use it as an additional check rather than as proof that YouTube is receiving the stream.
With the equipment running, simulate the intended interruption using the UPS manufacturer’s approved test method, or disconnect the UPS input from mains if its instructions permit this. Do not pull plugs from live equipment or open electrical enclosures. The test should move the full chain to battery; switching off only the Pi while leaving the ONT untouched would not test the actual outage boundary.
Observe each device. Does the Pi remain on without rebooting? Do router and ONT indicator lights remain in their normal state? Does the Pi retain its network route? Does the stream remain healthy in Live Control Room? Record what happened and how long the chain operated before you restore mains, but do not extrapolate that observation into a guaranteed duration under different battery condition or load.
Repeat the test after changes to equipment, cabling, UPS placement or software. A brief interruption test checks a different thing from a long runtime test: it can show whether the transfer itself causes a failure, while a longer controlled run helps assess battery endurance. Stop if the UPS reports overload, a supply becomes unusually hot, or any device behaves abnormally. Follow the equipment instructions and use a qualified electrician for mains wiring questions.
Check FFmpeg recovery and YouTube stream health
Power continuity and software recovery are separate layers. A UPS can keep the Pi powered while a network interruption causes FFmpeg’s publishing session to end. Likewise, a process supervisor can relaunch FFmpeg after it exits, but that does not prove the new process has reached YouTube successfully.
Use a service supervisor or other established process manager to restart FFmpeg if it exits, and make sure it does not create repeated overlapping processes. Check the logs for the actual exit reason. A loop in a shell script may restart a process, but careless retry behaviour can hide a bad stream key, a missing input file or an internet connection that remains unavailable.
FFmpeg supports RTMP and RTMPS, and its protocol documentation describes RTMP as operating over TCP/IP. Do not assume that reconnect switches documented for HTTP apply to an RTMP publishing session: FFmpeg’s HTTP protocol source describes HTTP-specific behaviour, not a blanket guarantee that YouTube publishing resumes after every drop. Configure and test the protocol you actually use.
During the controlled interruption, check three things independently: whether the FFmpeg process is running, whether it is sending data after network or power returns, and whether YouTube Live Control Room reports a healthy incoming stream. A process that appears in a process list may be stuck, retrying, or writing errors. A healthy status in the control room is stronger evidence that YouTube is receiving a usable signal, but watch the picture and listen to audio as well.
If recovery fails, narrow the cause. Confirm that the input file is still accessible, the stream key is current, the Pi has network access, and the encoder settings fit the available upload. For a channel that changes content over time, the advice on making an Indian music stream look like a radio station can help with presentation, but presentation does not replace a recovery test.
Know where local backup ends
When all equipment inside your premises remains powered, the broadband connection can still fail beyond your backup boundary. The ISP may have an outage, a local exchange or fibre path may be affected, or upstream connectivity may be unavailable. A UPS in your room cannot power or repair those parts of the route.
This distinction is important when interpreting a test. If the Pi, router and ONT stay powered but the stream stops, check whether the local network still reaches the internet before changing FFmpeg settings. If the connection returns after the cut but YouTube remains unhealthy, inspect FFmpeg’s logs and the Live Control Room. A clear sequence helps you avoid buying a larger battery to solve an upstream fault.
A second connection, such as mobile broadband, can be a separate contingency if it is available and suitable, but it has its own coverage, data, power and routing constraints. Do not assume it will take over automatically: the Pi, router and connection configuration must support a tested failover path. Even then, YouTube’s service and other upstream networks remain dependencies.
YouTube recommends testing stream settings and monitoring stream health; those checks are particularly useful when a channel must run unattended. But no local setup makes a 24/7 broadcast independent of every provider in the route. The practical goal is to reduce local failure points, know how the system recovers, and have a clear response when an external link is down.
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
Will a battery on the Raspberry Pi keep the stream online?
Only if it powers the Pi adequately, and even then it does not keep a separate router, modem or ONT alive. Back up every local device the stream needs, and remember that the ISP and upstream route remain outside your premises-side backup.
Can I use a Raspberry Pi UPS HAT for the whole setup?
A HAT can provide backup to a compatible Pi, subject to its output and battery limits. It will not automatically power a separate router or ONT, so those devices need their own suitable backup or a UPS that supports the full chain.
How long will a UPS run my Pi and router?
There is no single runtime that applies across models, batteries and connected equipment. Compare vendor runtime information at a load like yours, then test the assembled chain under controlled conditions; VA alone does not tell you how many hours it will run.
If FFmpeg restarts, does that mean the YouTube stream has recovered?
No. Check that FFmpeg is sending data again and confirm in YouTube Live Control Room that the incoming stream is healthy, with the expected picture and audio. A running process is not proof of successful publishing.