Live Streaming Basics
Oct 19, 2011 4:22 PM, Provided by Digital Rapids
Expanding a ministry’s reach through live video streaming.
The popularity of web and mobile video offers a powerful opportunity for expanding the reach of your ministry. While on-demand (prerecorded) video is an important element of any faith-based online site, live video streaming adds the element of immediacy that can deepen the connection between you and your viewers. Live streaming, however, has a few more technical considerations that you should plan for.
One of the most common ways houses of worship are using live streaming today is to reach congregants unable to attend sermons in person. These could include ill or elderly followers, travelers, those away from their home area for an extended period (such as university students), or even those who have moved permanently from the local area but still wish to maintain their connection. Streaming technologies allow such remote worshippers to be reached on devices ranging from personal computers to mobile phones.
Another increasing use of streaming technologies is to connect multisite church organizations, enabling live sermons to be delivered across multiple gathering locations.
Basic Overview of Streaming
At a basic level, there are four key steps in a typical streaming setup, with the content following a linear flow: video source --> streaming encoder --> streaming distribution server or service --> viewer
The streaming encoder is used to transform the source video signal (which may be an analog signal, such as composite, Y/C or component; or a digital signal, such as IEEE-1394 DV or SDI) into a web-friendly stream. This transformation involves compression (to “squeeze” the video and audio signals down to a data rate that can be streamed over network and Internet connections) and “wrapping” the compressed video and audio into a format and protocol used to transport the content. The church can decide what bit rate (data rate) the video streams will be compressed down to. Essentially, a larger bit rate enables higher video quality, but requires higher Internet bandwidth for both the church and viewers.
The resulting stream is sent from the streaming encoder to a distribution (streaming) server or external service (content delivery network, or CDN), from which the content is delivered to viewers. Note that in a typical situation with multiple viewers, there is generally not any “direct” connection between the viewer and the encoder—they connect only to the distribution server or CDN.
These transformations and delivery occur in realtime, so the viewer is seeing the content effectively live as it happens (although generally subject to a small delay—seconds, not minutes—incurred by the nature of network data transport).
Viewers usually access the live content through a video player embedded in a web page; the sophistication of these players varies from simple linear playback (like traditional television), to more sophisticated players with DVR-like functionality (pausing or rewinding the live streams).
A key factor in the success of the streaming is the church’s Internet (or private network) connection, which we’ll talk about in more detail in the next question, but needs to be mentioned here first.
The choice between the church using its own distribution server and using a CDN is largely based on the number of viewing locations to be reached, and the available Internet connection upload (sending) bandwidth. When using its own streaming server inside the church, the amount of bandwidth needed by the church is essentially the sum of all of the individual viewing bandwidths—the bit rate of the stream times the number of viewers. For example, if you’ve chosen a 750Kbps (note that this is kilobits, not kilobytes, per second) bit rate, and you have 100 viewers, the total bandwidth demand is 75,000Kbps (75Mbps)—far greater than the upload speeds of the majority of Internet connections, so not practical.
A CDN service provider, however, lets you scale to a virtually unlimited number of viewers, providing you’re willing to pay for that level of service. (The service cost is generally based on the amount of data transferred from your account, which will grow with your number of viewers). The church only needs to send a single stream to the CDN over its outgoing Internet connection; it’s the CDN who needs the big bandwidth to deliver to all of the viewers.
In contrast, if you are only streaming to a small number of locations, using an inhouse streaming server may be effective. For example, if the goal is to stream to two other campuses within a multisite organization, and the chosen data rate is 3Mbps, then the total outgoing bandwidth demand is 6Mbps, which is possible with a sufficiently fast connection (more on that again shortly). Note that we’ve used a higher data rate in this example on the assumption that the streams will be displayed on large TVs or monitors in this scenario, so it’s important to maximize the resolution and quality of the streams being delivered.
Note that in the case of a single viewing location—such as an output stream being transmitted to a single remote location in the case of a two-site church—the streaming server or CDN may not be necessary, as a one-to-one connection could be formed between the receiver (player) and the encoder. This is not, however, the scenario that most churches will face when they begin streaming.
The source to the encoder could be as simple as the output of a single video camera, or could be an output feed from a complete production environment (with multi-camera switching, etc.). Many churches already have such a production environment from which the encoder can receive a feed.
Acceptable Use Policy blog comments powered by Disqus