** UPDATE ** This page continues to get a lot of traffic, however I no longer recommend the workflow used here, and the tech stack described here is out of date. Due to the complexity of reliable streaming, and the need for available support when things go wrong, I recommend you look to Resi: https://resi.io
----------------------------------If your church is looking into the multi-site model, you've joined an exciting community of Christ-followers seeking to geographically spread the gospel of love in an intimate, community-oriented way. With the advancement of today's IP-based networks and computer processing capabilities, multi-site video venues are now possible to just about any church. The purpose of this tutorial is to explain how your church can technically execute an IP-based Multi-site HD Video Venue with LIVE/DVR (time-shift) capabilities, without an outrages budget!
Who is this tutorial for, and why was it written?
As Christians, our mission is to spread the knowledge of Christ's love and saving grace as He builds His Church. To accomplish this mission, we must work together and share our learnings so we don't unnecessarily duplicate efforts. You don't need to be a programmer or computer genius to make affordable multi-site a reality, but this tutorial does require intermediate technical competency, and is written primarily for church Technical Directors and IT staff.
Can't I just use Livestream, uStream, Twitch, or some other traditional streaming provider in my multi-site?
Imagine a visitor at your multi-site campus who is really connecting with your remote pastor, and just as your speaker is describing to that visitor how they can accept Jesus into their life, bam... buffering. That just doesn't fly. Not only will your volunteers feel helpless while watching a spinning wheel and hoping that the video comes back, your visitor will also lose confidence in the credibility of your environment.
The problem with using traditional streaming providers for your remote-site lies within the method they use to deliver the audio/video data to the browser-player. In their method, data is pulled from remote servers as the video plays along... Some of these players can cache or buffer a small amount of data ahead of the current playtime -- usually a few seconds, but if there is any network congestion between your player and the remote server you will eventually see buffering during your live playback. Even using newer technologies like adaptive bitrate streaming will not guarantee buffer-free playback if network congestion last more than a few seconds. And while occasional user-end buffering is generally acceptable for those watching from home or on a mobile network, you need something more robust in a live hosted environment.
Enter: Local DVR
In order to overcome this potential for buffering during playback you must remove the possibility of network congestion between the DVR server and the player. You can accomplish this by storing the audio/video data at your playback site instead of storing it on a remote server. With this method, the player is pulling data from a local source (a hard-drive on the same computer for example), eliminating the potential for unexpected network congestion between the data and the player.
In this walkthrough you will learn end-to-end how to capture uncompressed video, encode and stream an HD audio/video stream to a cloud server, and configure a local DVR (at your remote site) to record and playback the stream live or on a delay using Microsoft IIS, a free server platform that has been used to deliver streaming content worldwide in the last four Olympics.
Why Windows? Why IIS? Why Microsoft Smooth Streaming?
It's common knowledge that most of the House of Worship community is built around Apple Products. Macs are simple for volunteers to use, and there is little upkeep. However, Apple doesn't offer media server software capable of capturing and serving live streams in a DVR fashion. Wowza Streaming Engine can run on Mac, but their software costs near $1,000 per license -- and it is needed at each remote campus ($$).
Microsoft IIS on the other hand is completely free, and can be installed on any PC running Windows 7 or greater. This makes it ideal for churches with smaller budgets. Also, unlike most traditional streaming protocols (RTP, RTMP, RTSP, ect) which use unreliable UDP over a ports often blocked by firewalls, Microsoft Smooth Streaming transports over HTTP (port 80) with reliable TCP.
How much will this cost?
In brief, the average start-up cost for equipment:
Imagine a visitor at your multi-site campus who is really connecting with your remote pastor, and just as your speaker is describing to that visitor how they can accept Jesus into their life, bam... buffering. That just doesn't fly. Not only will your volunteers feel helpless while watching a spinning wheel and hoping that the video comes back, your visitor will also lose confidence in the credibility of your environment.
The problem with using traditional streaming providers for your remote-site lies within the method they use to deliver the audio/video data to the browser-player. In their method, data is pulled from remote servers as the video plays along... Some of these players can cache or buffer a small amount of data ahead of the current playtime -- usually a few seconds, but if there is any network congestion between your player and the remote server you will eventually see buffering during your live playback. Even using newer technologies like adaptive bitrate streaming will not guarantee buffer-free playback if network congestion last more than a few seconds. And while occasional user-end buffering is generally acceptable for those watching from home or on a mobile network, you need something more robust in a live hosted environment.
Enter: Local DVR
In order to overcome this potential for buffering during playback you must remove the possibility of network congestion between the DVR server and the player. You can accomplish this by storing the audio/video data at your playback site instead of storing it on a remote server. With this method, the player is pulling data from a local source (a hard-drive on the same computer for example), eliminating the potential for unexpected network congestion between the data and the player.
In this walkthrough you will learn end-to-end how to capture uncompressed video, encode and stream an HD audio/video stream to a cloud server, and configure a local DVR (at your remote site) to record and playback the stream live or on a delay using Microsoft IIS, a free server platform that has been used to deliver streaming content worldwide in the last four Olympics.
Why Windows? Why IIS? Why Microsoft Smooth Streaming?
It's common knowledge that most of the House of Worship community is built around Apple Products. Macs are simple for volunteers to use, and there is little upkeep. However, Apple doesn't offer media server software capable of capturing and serving live streams in a DVR fashion. Wowza Streaming Engine can run on Mac, but their software costs near $1,000 per license -- and it is needed at each remote campus ($$).
Microsoft IIS on the other hand is completely free, and can be installed on any PC running Windows 7 or greater. This makes it ideal for churches with smaller budgets. Also, unlike most traditional streaming protocols (RTP, RTMP, RTSP, ect) which use unreliable UDP over a ports often blocked by firewalls, Microsoft Smooth Streaming transports over HTTP (port 80) with reliable TCP.
How much will this cost?
In brief, the average start-up cost for equipment:
- Primary Site (video-origin): $1450
- Note: This does not include cameras, sound gear, ect; and assumes a local network is in place.
- Per Remote Site (DVR/playback-destination): $1,275-2,000*
- Note: This does not include a switcher, projector, screen, speakers, ect; and assumes a network connection is available.
- *$1,275 is the bare minimum and does not allow you to preview the stream (unless you have another available computer). A $2,000 budget would include a second computer to preview the stream ahead-of-time.
Where do I start?
This walk-through is broken-up into 3 parts :
This walk-through is broken-up into 3 parts :
- Part 1 - Primary Site (Est. 6/19/14): Select components for a desktop encoder. How to capture and encode an HD/SDI audio/video signal. Encoding settings for Microsoft Expression Encoder, which utilizes the GPU(s) to create an HTTP Smooth Stream.
- Part 2 - Cloud Server (Est. 6/26/14): Configure a cloud server running Microsoft IIS to receive and distribute the stream.
- Part 3 - Receiving Site (Est. 7/3/14): Capture the stream from the cloud server at a remote site, and use a highly efficient Windows 8 application for reliable playback that is smoother than any browser-based player.
- How to build a computer. If you need help, refer to this post for a good step-by-step example.
- What type of camera, sound-board, switcher, ect, you should buy.
Before you go any further, can you meet the Network/Bandwidth requirements?
If you have a slow or unreliable network, don't bother attempting to stream until that is fixed first. Consider the following:
- Do you have enough upload capability at your primary site? Do you have enough download capability at you receiving sites? Refer to this YouTube guide and Part 1 for a general guideline on the bitrate that you will need, and complete a bandwidth test at speedtest.net.
- If you offer public internet at your location, it should be capped so the bandwidth you need to stream is always available.
- Do not use WiFi to stream under any circumstances. Do not put your encoder behind a cheap switch.
- Enable QOS for audio/video packets (ask your IT director)
- If it's possible to bypass the premise firewall, do it.
If you're satisfied with the above considerations, continue on to part 1!
Please provide feedback through comments to improve and update this tutorial. We cannot improve each other if we do not communicate (Proverbs 27:17).
Good luck, God-bless, and give praise to our Lord & Savior, Jesus Christ.
Page last updated 6.18.2014
Good luck, God-bless, and give praise to our Lord & Savior, Jesus Christ.
Page last updated 6.18.2014
No comments:
Post a Comment