Secrets To Live Streaming Success

In Uncategorizedby tfwm

Pitfalls to Avoid and Best Practices

Houses of worship are embracing the use of streaming video to expand the reach of their ministries. Video on the Web and mobile devices allow churches to reach congregants unable to attend sermons in person.

While on-demand video is an important element for faith-based websites, live video streaming adds the element of immediacy that can deepen the connection between you and your viewers. Live streaming can also be used to connect multisite church organizations, enabling live sermons to be delivered across multiple gathering locations.

Live streaming, however, has more technical considerations that you must plan for to be successful. While advances in streaming technology and recent encoding solutions have made Web streaming easier and more accessible to houses of worship than ever before, there are some common misconceptions and mistakes that those implementing streaming for the first time often discover too late. This article highlights a few of the potential pitfalls, with advice on how to avoid them.


Before delving into these pitfalls, it’s useful to review the basics of a streaming workflow. At a simplified 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 encoder transforms the source video signal into Web-friendly (or mobile- friendly) data streams. This transformation involves compression (to “squeeze” the video and audio signals down to a data rate that can be streamed over network 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 encoder to a distribution (streaming) server or external service (Content Delivery Network, CDN), from which the content is delivered to viewers. (Note that in the case of a single stream being sent from an origin site to one remote campus, a direct connection may be possible, with no server or CDN required at all). In a typical situation with multiple viewers or destination sites, there is generally not any “direct” connection between the viewer and the encoder – they connect only to the distribution server or CDN. Viewers access the live content through a video player embedded in a web page or on their mobile device.


A fairly common misconception is that if you’re just creating a small, low-bitrate output for the Web or mobile phones, you can get away with using a lower-quality source signal. In fact, the opposite is true- low-quality sources have a lot of video noise, etc. that makes the video harder to compress, and you’re wasting bits compressing the junk in addition to the content. In a low bit rate output, those wasted bits are a higher percentage of the total, so you can end up with a LOT lower quality output than if the source had been “clean”.

You should always use the best quality signal possible, starting at the camera itself – lower-end cameras can introduce noise into the video signal, and lighting is also a big factor in compression quality. Video shot in low light has considerably more video noise than well-lit video; low-light video that looks OK on a monitor connected directly to the camera can look considerably worse once compressed for streaming. For connectivity, SDI digital signals are ideal. For analog video, component signals are the best, followed by Y/C (S-Video) and composite. The best encoding systems have video processing capabilities that can do a lot to help “clean up” the less-than-ideal video sources to create a goodquality output – but fantastic quality starts with a good source.


There’s a trade-off between visual quality and your choices of resolution and bit rate. A common mistake is to decide to stream at higher resolution (frame size) with the expectation that it will provide better quality. The problem is that a larger size requires more compression to achieve a specific bitrate; so the resulting visual quality may be much lower than smaller sizes at the same bitrate. Streaming at a lower resolution can actually give better quality than streaming at higher resolution at the same bit rate.

If you want to increase your resolution, you may need to use a higher bit rate to accommodate it.


That leads to another possible mistake, though – choosing too high a bit rate relative to your viewers’ connections.If your bit rate exceeds the sustainable bandwidth of a viewer, it’s likely to result in an unwatchable experience (lots of buffering, stuttering, etc.). Be sure to offer a stream with low enough bit rate for the “minimum” connection you expect of your viewers. In fact, it may be best to consider offering streams at multiple bit rates – at least one for those with slow connections, and a high-quality stream for those with fast connections. Some encoders can output multiple streams at various resolutions and bit rates simultaneously from the same source signal, but don’t forget that if you’re offering multiple streams, your Internet connection must be fast enough to send those streams out simultaneously.


Whether to use an in-house distribution (streaming) server or CDN depends 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 to reach multiple viewers is essentially the sum of all of the individual viewing bandwidths. If you’ve chosen a 750Kbps bit rate, and you have 100 viewers, the total bandwidth demand is 75,000Kbps (75Mbps) – far greater than the upload speeds of most Internet connections, so not practical. If instead you’re streaming to just two other sites, an in-house distribution server may be viable.

A CDN service provider lets you scale to a virtually unlimited number of viewers. The church only needs to send a single stream to the CDN over their outgoing Internet connection; the CDN effectively replicates the stream for each viewer, so it’s the CDN who needs the big bandwidth to deliver to all of the viewers.


It’s very important to distinguish the upload (outgoing) speed of the church’s Internet connection from the download (incoming) speed.When Internet Service Providers promote the speed of their service, the number they’re citing is generally the download speed – and on all but the highest-end offerings, the upload speed is significantly less (we’ve seen service packages with 12Mbps download speed but only 1Mbps upload). The sustainable upload speed should also allow for overhead beyond the video itself – if your video stream is 1Mbps, a 1Mbps upload link won’t be enough.


Ideally, the Internet connection used for sending the streaming video should be separate from the general Internet connection that the church uses for other tasks such as e-mail, web browsing and other uses. Sharing an Internet connection between The outgoing streaming and other tasks can result in unexpected performance drops as the various tasks contend for bandwidth. A dedicated line ensures that the outgoing stream isn’t affected by any other Internet activity at the church.