A church encoder sending a sermon loop continuously to YouTube uses about 64.8 GB of outbound data a day at 6 Mbps, or 108 GB a day at 10 Mbps, before protocol overhead. Those are calculated estimates based on YouTube’s recommended H.264 ingest rates for 720p30 and 1080p30, not measurements of your particular stream.
That data is separate from the electricity your computer uses. To reduce power use without risking a night-long interruption, measure the computer and display first, make one change at a time, and check stream continuity in YouTube Live Control Room before keeping each change.
Can you reduce PC electricity use without stopping the stream?
Often, there are opportunities to reduce the power used by the display or computer, but there is no universal setting that will save a known amount and preserve every stream. The result depends on the hardware, encoder workload, Windows configuration and the way your streaming software is running. Treat each adjustment as a test, not a guaranteed fix.
First, separate the two quantities in the question. Internet data is the information the encoder sends to YouTube; electricity is what the computer, display and other equipment draw from the mains. Changing screen brightness may affect display power without changing stream bitrate. Changing the encoder’s resolution or bitrate affects network use and workload, but may also change picture quality. Neither should be mistaken for the other.
For continuous live ingest, the file size of the sermon is not the data-use figure. A video played into a live encoder is transmitted as an ongoing live feed, rather than uploaded only once. YouTube recommends 6 Mbps for H.264 at 720p30 and 10 Mbps at 1080p30 in its live encoder settings. At a sustained rate, multiply Mbps by 10.8 to estimate decimal GB sent in a day: 6 × 10.8 = 64.8 GB; 10 × 10.8 = 108 GB.
These figures describe the church’s outbound encoder traffic. They do not describe the total data delivered to viewers. YouTube says it transcodes live streams into multiple playback formats, so each viewer’s download depends on the format watched and how long they watch. If you mean ordinary on-demand sermon uploads, rather than a continuously encoded live broadcast, these live-ingest estimates do not apply.
Measure the PC and display baseline
Before changing settings, record what the existing setup actually does. Note the computer model, display model, Windows power mode, streaming software and encoder settings, plus whether the stream is running on an integrated or separate graphics processor if you know. Also write down the stream’s current resolution and frame rate. This gives you a reference if a change affects picture quality or stability.
Measure electricity at the wall if you have access to a suitable plug-in power meter and can use it safely with the equipment. Record the computer and display together, or measure them separately if the meter arrangement allows it. Keep the setup in the same state during readings: sermon playback, streaming software, display brightness and connected devices should not be changing between the baseline and a later comparison. A momentary reading can miss changes in workload, so observe more than one point during a representative period.
If you do not have a meter, you can still test whether the stream behaves reliably, but do not turn a Windows label or a manufacturer’s nominal rating into a measured energy saving. The aim is to see whether a carefully controlled change alters the actual draw in your setup. Avoid opening the computer or probing mains wiring to take a reading.
Log the stream state alongside power readings. For example, note the time, observed wattage if measured, encoder output, and whether Live Control Room reports a healthy incoming feed. This matters because a lower reading is not useful if the computer has gone to sleep or the encoder has stopped sending. You can also use this time to review the difference between computer-based and hosted operation in whether a 24/7 stream keeps running when your PC is off, but do not assume the two approaches have identical costs or controls.
Tune display and Windows power settings carefully
Start with the display, because it is usually the easiest component to test without changing the encoded programme. If nobody needs to watch the computer monitor overnight, lower its brightness or switch off the display while leaving the computer itself awake. Do not select a sleep action for the computer by mistake. Windows distinguishes display-off behaviour from sleep, and the available controls vary by system and version.
Test one display change by itself. Keep the stream running, allow time for the computer to settle into the new state, and check that the encoder continues to send. If a monitor is also being used for confidence monitoring, switching it off removes that visual check; arrange another way to see the stream status or keep the display on. The purpose is to reduce idle display use without losing the ability to notice a problem.
Then inspect Windows power settings. A computer that sleeps, hibernates or suspends network activity cannot reliably keep a local encoder broadcasting. Set the system to remain awake during the streaming period, and avoid applying a battery-saving policy that might throttle the encoder or network connection. You may test less restrictive settings for components that are genuinely idle, but do so individually and confirm the encoder remains active.
Do not disable protections or services just because a forum post calls them unnecessary. Power plans and driver controls differ, and a setting that is harmless on one machine may interrupt another. If the stream drops after an adjustment, restore the previous value before trying something else. For the wider workflow, the guide to setting up a nonstop YouTube channel for store product videos can help you think through source material and continuous operation, even if your channel carries sermons.
Check encoder and OBS workload
The encoder’s workload is another possible source of electricity use, but any reduction may affect the delivered image. YouTube’s recommendations provide useful reference points, not mandatory settings for every church. At 720p30, its recommended H.264 ingest bitrate is 6 Mbps; at 1080p30 it is 10 Mbps. These sustained rates correspond to the daily data estimates above, before overhead. Do not reduce bitrate or resolution solely to lower computer power unless the resulting picture remains suitable for text, faces, hymns and sermon slides.
Check what the software is actually encoding. A static slide with a talking speaker may need different treatment from camera footage with movement, but the required bitrate depends on the source and quality target. If you lower resolution or frame rate, compare the result on an actual viewer device: small text on a hymn or scripture slide can become harder to read even when the stream remains technically live. The bitrate guidance for a 4K 60fps YouTube stream explains why resolution and frame rate are part of the bandwidth and picture-quality decision.
In OBS or another encoder, watch the relevant statistics while the loop is running. Look for rendering or encoding lag, dropped frames and sustained CPU or GPU load. These indicators help distinguish a computer under load from a network path that cannot carry the outgoing stream. Do not infer that a quiet-looking preview means the encoder is idle; it may still be encoding and transmitting continuously.
YouTube advises leaving 20% upload headroom over the total outgoing bitrate. Under that rule, one stream at 6 Mbps calls for about 7.2 Mbps of available upload, and one at 10 Mbps calls for about 12 Mbps, with other network traffic considered as well. YouTube also recommends Ethernet for computer-based live streaming. Ethernet can improve connection reliability, but it does not reduce bitrate-based data usage. See YouTube’s network, encoder and bitrate guidance and connection recommendations.
Test changes in a controlled period
Choose a time when a brief disruption would be manageable, rather than making the first change shortly before an important service or leaving it unobserved overnight. Keep the current settings written down so you can restore them. Change one item, such as display behaviour, and leave encoder and network settings untouched during that test. If several adjustments happen together, you will not know which one caused a drop or a lower meter reading.
Give the test enough time to pass through ordinary variation in the sermon loop and computer workload. Compare like with like: the same programme section, software, peripherals and display state. Record any power meter reading, along with Live Control Room status and encoder statistics. A comparison is only useful if you note what changed and what remained constant.
Do not use a short test to claim that a change will always work. A stream can appear normal initially and fail later when a task starts, the system updates, or the source changes. For that reason, make low-risk display tests first and schedule more consequential power or encoder changes for a supervised period. Keep the source file and current scene collection untouched while testing, so recovery does not require rebuilding the broadcast.
Network use is a parallel check, not a substitute for the power test. The 6 and 10 Mbps examples are sustained encoder rates and yield approximately 1.944 TB and 3.24 TB over a 30-day month respectively, before overhead; the month calculation assumes 30 days. Your actual transfer may differ because of bitrate variation and protocol overhead. Check the internet plan’s sustained upload capability and any local data allowance directly with your provider rather than assuming the YouTube estimate is a bill prediction.
Verify continuity in Live Control Room
Use YouTube Live Control Room as one of the checks after each adjustment. Confirm that YouTube is receiving the broadcast, that stream health remains acceptable, and that the preview advances rather than freezing on an old frame. Also check the stream itself from a separate device or account where practical: the encoder may be sending while a viewing issue remains, or the local preview may look fine while YouTube has lost the feed.
Watch the status during the test, not just at its start. A single healthy indication does not establish that the overnight stream will remain uninterrupted. Check the encoder’s own output and logs as well, since Control Room and OBS describe different parts of the path. If the incoming bitrate becomes erratic, dropped frames rise, or the feed disconnects, treat that as a failed test and restore the last known-good configuration.
Remember that Live Control Room checks continuity, not electricity. A healthy stream does not prove that a setting reduced power, and a lower meter reading does not prove that the audience receives a sound picture. Keep separate notes for power measurement, transmission health and viewed programme quality. YouTube’s explanation of how live streams are transcoded for viewers is also useful when a viewer’s playback differs from the encoder’s source.
Restore settings if the stream becomes unstable
If the broadcast becomes unstable after a change, stop experimenting and return to the last recorded working values. Restore one change at a time in reverse order, then confirm the feed is back in Live Control Room. If a computer has slept or the encoder has stopped, wake or relaunch it as appropriate and verify a fresh incoming signal; do not assume that an old preview means broadcasting has resumed.
For a recovery plan, keep the stream key private, preserve a record of the encoder profile, and know how to restart the broadcast without editing the original sermon file. If the same fault returns after restoring settings, investigate the relevant layer: sleep state and encoder load on the computer, upload capacity and connection on the network, or stream configuration in YouTube. Ethernet is worth considering for a computer encoder because YouTube recommends a wired connection, but it does not cut the amount of encoded data sent.
If you cannot supervise a local computer consistently, that is an operational constraint rather than a setting problem. A cloud-hosted workflow can remove the need to leave the church’s own computer running; StreamNeo is one such way to keep an uploaded sermon loop broadcasting while your computer is off. Consider the workflow and recovery requirements before changing systems, and keep the same checks for the YouTube feed.
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
Does looping a sermon mean the internet uploads the video only once?
No. If the sermon is being played into a live encoder, the encoder continuously sends the live feed to YouTube. The original file’s size is not the total outbound data for a 24/7 broadcast.
How much data is 24/7 at 720p30 or 1080p30?
Using YouTube’s recommended H.264 rates, 6 Mbps at 720p30 estimates to 64.8 decimal GB per day, and 10 Mbps at 1080p30 to 108 GB per day. These are sustained-rate calculations before overhead, not a measurement of your channel or viewers’ downloads.
Will turning off the monitor stop the stream?
Turning off only the display need not stop the encoder, but a sleep or hibernate action on the computer can. Test the display setting while watching Live Control Room and confirm that the computer remains awake and the feed continues.
Does Ethernet reduce the stream’s data use?
No. Ethernet may help connection reliability for a computer-based stream, but it does not change the configured bitrate or the resulting data estimate. Keep enough upload capacity for the stream and other network activity.