To keep an FFmpeg YouTube stream running during a power cut, you need backup power for the whole local chain: the Raspberry Pi, video source, router, and modem or ONT. Powering only the Pi is not enough if the camera, broadband equipment, or upload path shuts down.
A UPS can bridge a mains interruption only for as long as it can supply the combined load. It cannot ensure that your internet provider's access network remains available, so test the complete setup and plan for a clean shutdown when the battery is low.
What a power cut can interrupt
A live stream is a chain of dependencies rather than a single computer. FFmpeg may be running correctly on the Raspberry Pi, but the broadcast can still stop when another part of the chain loses power or connectivity.
The interruption may happen at several points:
- The Pi may shut down, reboot, or lose its boot storage after an abrupt power loss.
- A camera, USB capture device, audio interface, or other source may turn off.
- The router may reboot and take time to reconnect.
- The modem or optical network terminal, usually called an ONT, may lose power even if the router remains on.
- A switch, USB hub, HDMI converter, or powered adapter may stop supplying the source.
- The internet access network outside your home may become unavailable even while every device inside remains powered.
- FFmpeg may lose its output connection and need to reconnect.
This is why a Pi-only battery test can give a misleading result. The process still exists locally, but YouTube may no longer receive the stream.
There is also a difference between a brief interruption and a long one. A UPS changeover that is clean enough for the router and Pi to remain running may preserve the session. A longer outage may exhaust the battery, cause the broadband line to drop, or expose a fault that does not appear during normal mains operation.
Before changing the power arrangement, decide what “continuity” means for your channel. A devotional audio loop with a simple pre-recorded source has different requirements from a camera stream with USB capture and live audio. If the stream can stop and restart without serious consequences, a controlled shutdown may be preferable to trying to keep every device running indefinitely.
List every device the stream depends on
Start by drawing the actual route from source to YouTube. Write down each powered device, not just the Raspberry Pi.
For a simple pre-recorded stream, the list might contain the Pi, its power supply, the router, and the modem or ONT. A camera-based setup may also need a camera, USB capture device, powered USB hub, microphone, audio interface, HDMI converter, and network switch. A wired connection can add another switch or media converter. A wireless setup removes the Ethernet cable but does not remove the router's power requirement.
Record the following for every item:
| Device | What to record | Why it matters |
|---|---|---|
| Raspberry Pi | Model, supply rating, measured draw | The correct supply depends on the board and attached peripherals |
| Video source | Camera, file storage, capture device or converter | A dead source can stop or freeze the encode |
| Audio equipment | USB microphone, mixer or interface | Audio may disappear while video continues |
| Router | Input voltage, current and power draw | It provides the local network and often handles reconnection |
| Modem or ONT | Input requirements and measured draw | The broadband termination may be separate from the router |
| Switches and hubs | Supply requirements and load | These can be hidden single points of failure |
| UPS or battery unit | Output, changeover, low-battery behaviour | It must support the complete load, not just one device |
Check labels first, then measure actual consumption where possible. A label can show a maximum input value rather than the power used during your stream. A camera that is idle during testing may also draw less than it does with infrared lighting, a motorised mount, or an active display.
Keep the Pi's power cable and the network equipment's adapters in the same inventory. It is easy to buy a battery unit with the right connector for the Pi but no suitable output for the router or ONT. It is also possible to power the router while leaving the ONT off, which produces a local Wi-Fi network without a working broadband path.
If you are still deciding how the Pi will send video, the guide to running an FFmpeg YouTube stream from a Raspberry Pi over Wi-Fi covers the streaming side. For a power-cut plan, treat its network equipment as part of the same system rather than as an afterthought.
Match the Pi supply to its model and peripherals
The Raspberry Pi model determines the starting point for the local power plan. Raspberry Pi's official setup documentation lists 5 V at 5 A for Raspberry Pi 5, 5 V at 3 A for Raspberry Pi 4 Model B, and 5 V at 2.5 A for Pi 3 and earlier models in its table. Check the current Raspberry Pi getting-started documentation for your exact board before selecting a supply.
Those figures should not be treated as a promise that every setup will draw the same amount. USB devices, storage, cooling accessories, displays, and capture hardware can change the demand. A supply and cable that work for a lightly loaded Pi may behave differently when the board is encoding video and powering peripherals.
Raspberry Pi also warns that voltage loss in a removable cable matters. The supply may be rated correctly while the cable, connector, or extension introduces enough loss to cause instability. Use a suitable supply and cable for the model, and pay attention to undervoltage warnings or unexplained reboots during a sustained encode.
As Raspberry Pi Ltd. puts it in its official documentation, “We recommend using an official Raspberry Pi power supply suitable for the Raspberry Pi model you’re powering.” That is useful guidance for the normal supply. Your battery arrangement still needs to provide the appropriate voltage and current during mains loss.
A Raspberry Pi UPS HAT can be useful when the problem is specifically keeping the board powered, but a Pi-focused HAT should not automatically be assumed to power a router, modem or ONT. Check its output rails, connectors, load limits, changeover behaviour, and low-battery signalling. A product manual written for a Raspberry Pi 4 Model B does not establish compatibility with every Pi model or prove the runtime of your complete chain.
You also need a plan for peripherals. If a USB camera is powered from the Pi, its load is part of the Pi's demand. If the camera uses a separate adapter, that adapter belongs in the UPS inventory. If a capture device is powered through a hub, the hub and its supply become another dependency.
Do not solve a power-cut problem by adding a larger microSD card or a different boot medium alone. Storage choice can affect reliability, but it cannot keep the stream running when the Pi or network equipment has no power. Raspberry Pi's documentation warns that sudden power-downs can corrupt storage, so stable power and orderly shutdown behaviour matter as much as storage selection.
Estimate the combined UPS load and runtime
The correct UPS capacity depends on the total load and the duration you want to cover. There is no universal runtime for a Raspberry Pi stream because the equipment list, battery condition, conversion losses, and network hardware vary.
Add the measured or conservatively estimated load of every required device:
Pi + source + capture equipment + router + modem or ONT + switches and converters
Then account for the UPS itself. A battery unit may convert between battery and output voltage, and that conversion is not lossless. Battery age and temperature can also affect the result. A product headline based on a particular load does not tell you what your configuration will do.
If a device label gives voltage and current rather than watts, multiply them as a rough starting point:
watts = volts × amps
This is an estimate, not a substitute for measurement. Some adapters list maximum current, and some devices vary their draw considerably. For a dependable plan, measure the real configuration while FFmpeg is encoding, the source is active, and the network connection is in use.
Compare UPS choices using the following questions:
| Comparison point | What to verify | Why it matters |
|---|---|---|
| Output voltage and current | Whether every connected device receives the required output | A connector that fits is not proof of electrical compatibility |
| Complete-chain load | The measured load of the Pi, source and network equipment together | A Pi-only rating may be inadequate for the whole stream |
| Changeover behaviour | Whether devices remain powered during the transition | A reboot can interrupt both FFmpeg and the broadband link |
| Measured runtime | Runtime with your real configuration, not an unrelated test load | Runtime changes with load and battery condition |
| Battery replacement | Whether the battery can be maintained or replaced | Battery health changes the useful backup period |
| Low-battery signalling | Whether it can trigger an orderly shutdown | This reduces exposure to abrupt storage corruption |
| Network outputs | Whether the router and modem or ONT can share the backup | Keeping only the Pi alive does not preserve internet access |
If the UPS cannot provide the combined load for the period you need, there are several honest choices. Reduce the number of devices, simplify the source, use a lower-complexity stream, accept a controlled stop, or choose a different operating arrangement. Do not describe a theoretical runtime as a guarantee.
For a pre-recorded file, it may be practical to shut the Pi down cleanly when the reserve is low. For a live camera channel, stopping the source may be less acceptable, but the same physical limit remains. A battery can delay a shutdown; it cannot remove the energy requirement.
If the goal is a channel that does not depend on equipment in your home, compare that architecture with streaming pre-recorded videos on YouTube 24/7 from a VPS. It changes the power dependency rather than eliminating every dependency, so compare it with your source, network and maintenance needs.
Keep the router and modem or ONT powered
The router and the modem or ONT are separate responsibilities, even when your provider supplies them in one box. Identify which device terminates the broadband connection and which device creates your local network. Both may need power during a mains interruption.
A router with no ONT may still show a Wi-Fi name and allow the Pi to connect locally. That does not mean it has a route to YouTube. Conversely, an ONT with no router may still have an optical link but no local device able to send the stream. Include both where they are separate.
Use the original adapters where possible and check their input requirements before connecting them to a DC battery output. If your backup unit supplies AC, the original adapters may be used, but the UPS must support their combined load. If it supplies DC directly, voltage, polarity, connector size and current capacity all need to match.
A wired Ethernet connection can reduce one variable in the local link, but it does not make the stream independent of the router or ONT. A wireless connection can work, but its reliability should be judged in the exact location and configuration where the stream will run. Test with the same network mode you intend to use overnight.
The stream configuration also matters. YouTube advises choosing resolution, frame rate and bitrate for the available connection, testing before going live with representative motion and audio, and monitoring stream health. Its live-stream guidance recommends RTMPS as the secure extension of RTMP. Read the current YouTube live-streaming help rather than treating one bitrate as suitable for every broadband connection.
A stream with uncomplicated, mostly static visuals may be easier to carry through a marginal upload path than a detailed camera scene with constant motion. That does not make a lower setting universally correct. Measure upload performance at the location, consider competing traffic, and watch the health messages during a realistic test.
Understand the limits when the access network fails
Local backup power only protects equipment that is inside your premises. Your provider's access network, street equipment, fibre route, mobile backhaul, or upstream systems may be affected by the same outage or by a separate fault.
This creates two different failure cases. In the first, your local equipment loses power but the provider's network remains available. A suitable UPS may keep the stream connected. In the second, the Pi, router and ONT remain on but the access path is unavailable. No larger Pi supply can repair that missing connection.
You can investigate a backup connectivity path, such as a mobile connection, but do not assume it will work during every local outage. Check the actual upload performance at the premises, whether the backup device remains powered, and whether it stays connected when the primary service fails. Coverage and outage behaviour vary by location, and no particular Indian provider can be recommended from the equipment list alone.
A second connection also adds equipment and configuration. A mobile router, USB modem, dual-WAN router or manually switched hotspot needs power and a tested route to YouTube. If it is not already connected and configured, it may not help during a night-time outage.
Keep your expectations precise. The aim of the UPS is to maintain the local chain while the upstream path is available. It is not a guarantee that the broadcast will remain live, and powering every box in the room does not prove that the internet access network will stay online.
Configure FFmpeg for recovery, not magic
FFmpeg can recover from some output failures, but recovery settings are a software aid rather than a power solution. The FFmpeg formats documentation describes the FIFO pseudo-muxer and options for attempting recovery after failures, including network-output problems. Depending on the installed build and version, the relevant behaviour can include whether recovery is enabled, how long FFmpeg waits, and how many attempts it makes.
Check the documentation for the FFmpeg build installed on the Pi. Options and defaults can differ, so copy a setting from a current manual only after confirming that the local command accepts it. A command that starts successfully but does not implement the recovery behaviour you expect is not a recovery plan.
Recovery also has limits. FFmpeg cannot restart a dead camera, power a failed router, or restore an unavailable ISP path. Even when it reconnects successfully, YouTube may show a visible interruption. The channel may resume, but that is different from proving that viewers experienced no gap.
Build recovery around the actual failure you are testing. A brief network interruption is different from a Pi reboot. If the input file is local and still available, FFmpeg may be able to reopen the output. If the source is a camera or capture device that has reset, the input may need separate handling.
Keep the stream key and endpoint configuration available for a restart, but protect the key as a credential. The YouTube stream key and stream URL guide explains their roles before you automate a restart. Do not paste a real key into a public script, article, screenshot or support post.
For a simple pre-recorded source, a process supervisor or carefully tested restart script may help after a process failure. That logic should include limits and logging rather than restarting endlessly. Repeated restarts can consume the remaining battery and hide a fault that needs attention.
Test the complete chain during an outage simulation
Test the same Pi, source, cables, router, modem or ONT, UPS and FFmpeg command that you intend to leave running. A partial test answers a different question.
First, run the stream from mains power and confirm that the source, audio, upload path and YouTube stream health are normal. Record the measured load if you have a meter. Check that the Pi is not showing undervoltage warnings and that the source does not reset under sustained use.
Next, simulate the changeover according to the UPS instructions. Watch whether the Pi, router, ONT, camera and capture device remain powered. Check the local network, then confirm that FFmpeg continues to send data. A light on the router is not enough evidence; inspect the actual stream health and the source output.
Then test a brief network interruption separately from a power changeover. This shows whether FFmpeg's recovery settings behave as expected. Use representative motion and audio, because a static test image may not expose an overloaded upload path or an audio-device failure.
Observe the system for the intended operating period rather than relying only on the first few minutes. Note the battery reserve, device temperature, any reboots, upload warnings and whether the ONT reconnects. You are measuring this configuration, not establishing a runtime for all Raspberry Pi systems.
Finally, test the low-battery decision. If the unit can signal low reserve, confirm that the Pi receives the signal and that your shutdown action is safe. If it cannot, decide how you will monitor it and when you will stop FFmpeg manually. Raspberry Pi documentation warns that sudden power loss can corrupt storage, so an orderly shutdown is preferable to allowing the battery to reach an uncontrolled cut-off.
Write down the restart procedure while the system is working. Include the power order, network checks, source checks, FFmpeg command, stream-key location, and what you will do if YouTube reports no incoming data. A short checklist is more useful at three in the morning than an assumption that the system will recover itself.
If your channel has several streams, also confirm which device and key belong to each one. Running multiple broadcasts has additional failure points, so read the practical considerations in running two live streams on one YouTube channel before extending the same UPS plan.
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
Can I keep the stream live by powering only the Raspberry Pi?
Usually not reliably. The source, router, modem or ONT, and any required hubs or converters also need power, and the provider's access network may still fail outside your home.
Which Raspberry Pi power supply should I use?
Choose one suitable for the exact Pi model and its attached peripherals, using the current Raspberry Pi documentation and a suitable cable. The supply rating alone does not establish how long a battery unit will run the complete chain.
Will FFmpeg reconnect after a power cut?
FFmpeg recovery settings may help with some network-output failures, but they cannot restore power or an unavailable broadband path. Confirm the options supported by the installed FFmpeg build and test the resulting behaviour with the real source.
How large should the UPS be?
Measure the combined load of the Pi, source, router, modem or ONT, and other essential equipment, then compare that load with the UPS output and measured runtime. Do not rely on a generic runtime claim, because the result depends on the equipment, battery condition, conversion losses and outage conditions.