To switch sermon videos automatically in OBS, you need a control path from your presentation software to OBS that changes scenes when the service content changes. Adding a video as an OBS Media Source lets you play it, but does not by itself tell OBS when to switch scenes.
One documented approach is to connect Church Presenter to OBS through OBS WebSocket and map content types, such as slides or video, to named scenes. Before choosing a setup, test those mappings through the full service sequence; a configuration guide cannot guarantee that every local network or production arrangement will behave the same way.
How much data does a 24/7 church stream use?
For the church’s internet connection, the useful first estimate is the video and audio data sent by the encoder to YouTube. This is outbound encoder traffic. It is not the total data used by everyone watching the stream, and it is not a measurement of what your church’s router will record.
A simple estimate uses the encoder’s combined video and audio bitrate, expressed in megabits per second (Mbps), and multiplies by the hours streamed. At a steady bitrate, the calculation gives a planning estimate for the data payload sent from your streaming connection. Actual network totals can differ because of variable bitrate, protocol overhead, reconnections and other traffic on the same connection.
The distinction matters when you are checking a mobile broadband allowance or a connection with a data cap. A church sending a continuous stream may have a consistent outbound workload even when few people watch. YouTube’s viewer delivery happens separately: viewers receive data according to their playback format and how long they watch.
If you need a closer view of stream settings before doing the arithmetic, start with the OBS bitrate guidance for a 24/7 YouTube stream. Use the bitrate that your own encoder is actually configured to send, rather than assuming that a resolution alone tells you the data rate.
The encoder upload estimate formula
Use this formula for an estimate of outbound encoder traffic:
Data in GB ≈ combined bitrate in Mbps × hours × 0.45
The factor 0.45 converts megabits per second over an hour into gigabytes using decimal units. To estimate one day at a steady bitrate, multiply the combined bitrate by 24 and then by 0.45. For a month, use the number of days you plan to stream, not a generic month length if you are budgeting for a particular billing period.
“Combined bitrate” means video bitrate plus audio bitrate. If OBS shows video at 4.5 Mbps and audio at 160 kbps, convert the audio figure to 0.16 Mbps and add it: 4.5 + 0.16 = 4.66 Mbps. Use the encoder output settings, not a file’s size or the speed of your internet connection.
This calculation assumes a continuous stream at the stated combined rate. It is a calculated estimate, not measured usage, and it does not promise an exact total including overhead. If the encoder uses variable bitrate, the average can move above or below the setting you used. A real traffic counter may also include protocol overhead, reconnect attempts, other devices and unrelated uploads.
You can also work backwards. If your provider gives you an outbound data allowance for a billing period, divide that allowance by the number of streaming hours and by 0.45 to get a rough maximum combined bitrate in Mbps. Leave headroom for other network activity and variation rather than treating that result as a safe exact limit.
Worked estimates for 720p30 and 1080p30
Resolution and frame rate do not determine a single bitrate. The settings you choose, the encoder and the scene content all affect the rate. The examples below therefore use explicit illustrative settings, rather than claiming that every 720p30 or 1080p30 stream uses the same amount.
Assume a 160 kbps audio track, or 0.16 Mbps. For the video, use 3.0 Mbps as an example 720p30 setting and 4.5 Mbps as an example 1080p30 setting. These are assumptions for demonstrating the arithmetic, not prescribed settings or a statement of YouTube’s current requirements.
| Example output | Video bitrate | Audio bitrate | Combined bitrate | Calculated outbound data per day |
|---|---|---|---|---|
| 720p30 | 3.0 Mbps | 0.16 Mbps | 3.16 Mbps | about 34.1 GB |
| 1080p30 | 4.5 Mbps | 0.16 Mbps | 4.66 Mbps | about 50.3 GB |
For 720p30, the daily calculation is 3.16 × 24 × 0.45, which is about 34.1 GB. For 1080p30, it is 4.66 × 24 × 0.45, or about 50.3 GB. Both numbers refer only to calculated outbound encoder traffic under the stated assumptions. They are not measured usage or guarantees of an exact total inclusive of overhead.
The higher example adds about 16.2 GB of calculated outbound traffic per day. In return, it may provide more picture detail, which can matter for small text on sermon slides or a camera image. You still need to choose a setting that your connection can sustain and that suits the content. A slide-heavy service and a camera shot with movement may not encode in the same way at a given setting.
If you are comparing stream formats, do not transfer a setting from another church without checking its context. Your 24/7 stream bitrate checklist can help frame that decision; then enter your chosen output bitrates into the formula above. Keep a note of whether OBS is using a constant or variable rate, because that affects how closely a setting represents the average data sent.
What the estimate includes and excludes
The estimate includes the nominal audio and video bitrate sent by the encoder, multiplied by stream duration. It is useful for comparing two configurations or making a first-pass allowance for an always-on broadcast. It is not a counter reading from your ISP, OBS or router.
It excludes any promise about protocol overhead, retransmissions, brief reconnections, changes in bitrate, or other traffic on your church connection. Nor does it include uploads from a separate device, such as someone sending a recording or backing up service files. If other equipment shares the connection, its traffic should be considered separately when you assess the connection’s total demand.
A stream that drops and reconnects could use a different amount than a simple uninterrupted calculation suggests. So could an encoder that changes its rate with the image. For planning, calculate a baseline from your settings, then inspect actual network counters over a representative service period. Do not relabel the calculated number as measured usage.
If the stream is assembled from recorded sermons and worship segments, the source library and playback workflow are separate from the outbound data calculation. A pre-recorded video playlist workflow can help you think through continuous playback, but the encoder still sends a live output at its configured rate while the broadcast is running.
Why viewer data use is different
Your encoder sends one stream to YouTube. YouTube then delivers playback to viewers. Those viewers do not each receive a separate copy from your church’s upload connection, so multiplying your encoder estimate by the number of viewers would give the wrong estimate for the church’s outbound traffic.
Viewer delivery data varies with playback format and watch time. A viewer watching at a higher resolution can receive a different data volume from someone watching at a lower resolution. One person watching for the whole service also uses more delivery data than someone who checks in briefly. The viewer’s own connection and playback conditions matter as well.
This makes two separate questions. “How much data does our encoder upload?” is answered with the outbound bitrate calculation. “How much data might viewers consume?” requires assumptions about the formats they watch and how long they stay. Do not include viewer delivery in your church’s upload estimate; it is not traffic sent from the church to YouTube.
If your church is considering a continuous replay channel beyond its live service, the guide to scheduling a 24/7 radio livestream is a useful adjacent workflow. The same distinction applies: the origin connection’s encoded stream and the platform’s delivery to viewers are different parts of the path.
Estimate your church’s monthly upload
For a monthly planning estimate, use the combined bitrate and the number of hours you expect the encoder to be live. For a stream running all day, every day, multiply the combined Mbps by the days in your billing period and by 24, then by 0.45. For a church streaming only during services, use the actual planned hours rather than assuming a full month of continuous output.
For example, with the illustrative 720p30 settings above, a 30-day continuous run would calculate as 3.16 × 24 × 30 × 0.45, or about 1,024.9 GB of outbound encoder traffic. With the illustrative 1080p30 settings, 4.66 × 24 × 30 × 0.45 gives about 1,510.9 GB. Those are arithmetic estimates from the stated settings, not measured totals, and they exclude overhead and any other use of the connection.
For a weekly service lasting three hours, use 3.16 × 3 × 0.45, or about 4.3 GB per service under the same 720p30 assumptions. Multiply by the number of services in your billing period. If you add a rehearsal stream, a pre-service loop or an overnight replay, include those hours too. This keeps the estimate tied to the schedule you actually intend to run.
When a billing period is close, avoid planning right up to its full data cap based on arithmetic alone. Your network may carry other traffic, and counters may account for traffic differently from this simplified calculation. Record the selected bitrate, service hours and the resulting estimate so that you can compare them with the provider’s actual usage display later.
Ways to check actual network use
Use more than one view if the decision matters. OBS shows the stream output state and configured encoder settings; your router or broadband provider may expose traffic totals. Those counters can help establish actual network use over time, but they may include devices beyond the streaming computer and may not distinguish the broadcast from other uploads.
A practical check is to note the router or provider counter before a test broadcast, run a representative service-length stream, then note the counter afterwards. Keep other large uploads off the connection if you want a cleaner comparison. The difference is measured network traffic for that period, not a pure measurement of encoder payload unless the counter isolates that traffic.
Also check for a stable connection at the encoder. A speed test can indicate available bandwidth at the moment of testing, but it does not measure the total data used by the stream, nor does one result establish how the connection will behave through a long service. If video quality or dropped frames vary, review the encoder’s output and connection indicators while considering other traffic on the network.
For automation, keep the scene-switching test separate from the network test. The Church Presenter guide describes enabling OBS WebSocket, entering the connection details in its OBS settings, and mapping content types to scenes. Its setup uses localhost when both applications are on the same computer; if they are on separate computers, it says to enter the OBS computer’s local IP address and keep both on the same local network. See the Church Presenter OBS connection guide for the vendor’s current steps. Use the host, port and password shown by your own OBS setup rather than assuming a value from a guide.
Map a presentation slide content type to your slides scene and a video type to a scene with the intended media source. In the documented workflow, content types that have not been mapped leave OBS on its current scene. Check the connection indicator, verify scene names, then rehearse the service sequence before going live. This is especially important if sermon playback is controlled by another computer, since the local network path must work during the actual service.
OBS’s Media Sources documentation describes file playback options such as looping and restarting when a source becomes active. Those settings concern playback, not the presentation-to-OBS control path. OBS also lists capture cards among its source types; a capture card can bring in an external HDMI signal, but it is not required for software-driven scene changes.
If a church runs a repeated sermon or worship file rather than a live presentation sequence, the burden may be less about switching scenes and more about keeping playback consistent while nobody is at the control desk. StreamNeo can remove that specific need to leave a church computer running by turning an uploaded video into a YouTube live stream that continues with the computer switched off, though it is YouTube-only and does not automate OBS scene changes during a service.
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 adding a sermon video in OBS make it switch automatically?
No. An OBS Media Source can play a local file, with options such as looping or restarting playback when the source becomes active. Automatic scene changes need a separate control path from your presentation or another control system to OBS.
Can Church Presenter switch OBS scenes when sermon content changes?
Church Presenter’s documentation describes connecting to OBS through WebSocket and mapping live content types to scenes. Treat that as a documented workflow, not a guarantee for every setup. Confirm the connection and rehearse the full service sequence on your own equipment.
Does a capture card automate the scene change?
No. A capture card is an input source for video arriving over HDMI. It can be useful when OBS needs an external video signal, but it does not itself detect presentation content or change scenes.
Does the daily data estimate include viewers watching YouTube?
No. The formula estimates calculated outbound encoder traffic from the church to YouTube, based on the bitrate and hours. Viewer delivery data is separate and varies by playback format and watch time.