Things to consider when broadcasting to satellite campuses
Your message is important. It can comfort and save. When reaching the congregation at remote locations, don’t let your message get lost because a lack of quality or video dropouts. Consumer and prosumer products leave remote worshippers dissatisfied, especially when projected on a large screen. You can now, cost-effectively, utilize the same broadcast quality solutions relied on by major television networks for delivering video over satellite, dedicated circuits, and/or the Public Internet.
The purpose of broadcasting to multiple locations is to better minister and facilitate worship for current and new attendees. While watching and listening to senior pastors, congregations must feel the same experience as if they were at the main campus. Commonly, the remote stage is set up identical to the main campus, but also incorporates a very large projection screen to display the pastor at actual size. Movements, gestures, and the sermon are viewed as if they are talking directly to each person. When done correctly, you feel a real presence, connection and involvement, unlike watching TV. Yet, one video glitch can instantly remove that “suspension of disbelief”.
In a typical design, the live feed transmits from the main campus’s production router output to a distribution method of choice. When deciding on the best workflow, consider the following questions: Will you transmit your entire service, or just the sermon portion, or the music portion as well; how will your timing mesh with their timing; are your graphics applicable to their service; or should the remote sites control their own graphics and switch to live feeds when appropriate? Planning a joint coordinated service may be more difficult than planning two independent services. Once you have a production strategy in place, you must decide which delivery method best fits your budget and needs.
Getting broadcast quality video distributed to multiple locations: An overview of three methods with an in-depth technical focus on IP delivery
1. Satellite
Not that long ago, satellite meant “satellites in space”, and sometimes that’s still applicable. It is a relatively simple process, but may not fit everyone’s budget. A satellite transmission system includes an encoder, modulator, up-converter, amplifier, and transmit antenna. The equipment is powered up and you start transmitting about 15 minutes prior to your service. The remote site(s), through a satellite antenna, lock onto the carrier with a satellite receiver, start decoding, and connect an HD-SDI output to their projector and sound system. There are two main benefits to this approach, (1) broadcast quality video and extremely reliable delivery even to rural areas, and (2) the transmission cost is the same whether it is received at 1 or 1000 sites.
2. Dedicated Telco Circuits
Dedicated circuits can be a cost-effective solution, depending on your local topology, and very reliable. However, they may not be available in your particular area. In many metro areas, you can lease an SDI or “270” circuit, for point-to-point service. Your local carrier should provide and install the equipment, and connect the service. Depending on your contract, installation and terminal equipment may be provided for free, but there will be a monthly service charge. Simply connect an encoder at the main campus and a decoder at the remote site.
If 270 circuits aren’t available, check into a DS3. You will want a “nailed down” circuit, with telco provided routers configured in “bridge” mode.
3. IP-Based Networks
Don’t assume that just because an encoder has an Ethernet interface, you can just connect it to the Internet and stream to the remote sites. Broadcast video and streaming video are two different things. Although they use similar underlying technologies, the application, approach, and methodologies are entirely different. Likewise, the IP network infrastructure has different requirements.
Long before 100baseT, MPEG encoded programs were originally designed to be transported between encoders, multiplexers, modulators, IRDs (professional broadcast equipment) over ASI (Asynchronous Serial Interface) on PTP coax cables at 270 Mbps. As IP technology leap-frogged broadcast technology, equipment manufacturers leveraged the lower cost IP technology to transport live content between devices. Today, this only works properly on “very tightly controlled, managed, and maintained” networks. Without proper conditioning, it won’t work on the public Internet, an IP leased line, or even possibly your existing LAN. Why not? For an important and quick technical explanation:
Issues with MPEG over IP based Networks
All MPEG encoded content is packetized into 188-byte packets, with a 4-byte header that includes a 0x47 sync byte and a unique PID per element or elementary stream (video, audio, data). These are transmitted in such that all of the packets occur at a regular interval, and each elementary stream packet must also arrive at that regular interval at the receive end. This is the time base not only for synchronization of the link from end-to-end, it is also used to phase-lock-loop the demux, video and audio decoder chipsets within the receiver.
Furthermore, one element within your MPEG program stream (usually the video), is designated as the PCR (Program Clock Reference). The PCR value is a detailed timestamp inserted into the packet extended header, as well as offset information. According to specifications, the PCR packet interval must be </= 40 msec, and be at a constant interval. This is necessary for A/V synchronization and receiver buffer management.
Any irregularity in this consistent interval is called jitter. Luckily, a little bit of jitter is allowed, but not to exceed +/- 500 nsec. That’s not much tolerance. Additionally, if there is jitter or an offset from the regular interval, the actual amount of offset must also be indicated in the MPEG packet header as “PCR offset”. The information indicating the actual amount of offset must be accurate to within 30 ppm.
MPEG encoding, broadcast and transmission equipment are content and payload aware, and have the ability to read, and even re-write the PCR and offset values if they are doing any stream manipulation.
IP networks were designed for and work great for best-effort, TCP transport. They flawlessly pass the content payload from point-to-point error free, without any regard to the content itself. If there is an error in the packet, the receiving end NACK’s the packet and it is retransmitted from the sender. At the receive end, the PC unpacks the payload from the IP packet and re-assembles the file. This can even correct for errors caused by issues in the underlying layers of the OSI model, Physical, Data Link and Network.
However, when transporting live MPEG video over IP networks, it is usually a UDP transport stream, with seven 188-Byte MPEG packets per IP packet. It’s transmitted blindly, to anyone configured to receive it. Not only is there no luxury of ACK, NACK and retransmit, the underlying layers must also be perfect.
An IP packet is intentionally not content aware. Any network congestion at any switch, router, line, or path re-route will affect the timing of IP packet arrival at the receive destination. Even if they were transmitted as a smooth stream with all packets occurring at a regular interval, in order, they won’t arrive at the receive end that way.
Think about how that affects the PCR timestamp, interval, offset, and indicated offset value. An IP router can’t reach into the packet payload and re-write the PCR values so they are guaranteed to be arrive at the receive end wrong.
Transmitting video over IP can be the most cost-effective alternative. Many Houses of Worship already have Internet access, if not, the infrastructure is easily accessible and cost-effective. Many tried video over IP and gave up because it “didn’t work as well as planned.” As explained above, they likely got bit by the “PCR jitter bug.”
A few companies provide viable solutions to successfully broadcast video over IP. They’ve developed “routers”, or “edge devices”, to condition signals for Internet traffic, then recover and reassemble the packets in their original form. These content aware “Link Conditioning” devices are placed at each end of the IP transmission path and re-assemble packets in the proper order. They also realign IP and MPEG packets corrupted during transmission, provide a packet-stable, and more importantly, a PCR stable output at the receive site.
Should you attempt doing this on your own, be sure to use professional broadcast quality hardware, the proper test equipment, and please don’t believe your local ISP or IP service provider when they say their network or your connection is “good enough” to pass broadcast video. Perfect in the IP world is not necessarily good enough in the broadcast world.