Sometimes, the challenges of traditional RF-based systems broadcasters use daily to move all sorts of A/V from the field into the studios are insurmountable. These include rain fade, lightning, strategic parking issues and the fact that most RF used for signal transport is line of sight. Add to that the costs of building and operating ENG vehicles, SNG trucks, satellite time and receive/repeater sites, and the cost of transporting live broadcast quality video to and from studios can get very expensive.
Broadcasters have looked to the Internet for a viable alternative to RF-based systems. Because most Internet streaming video uses store-and-forward technology, its robustness becomes subjective in terms of the dependability and latency broadcasters generally require. There have been some consumer and prosumer-level video streaming devices on the market that do a fairly good job with SD, but the introduction of sophisticated error correction systems, such as deep packet recovery (DPR), gives broadcasters the opportunity to use the public Internet for real STL-quality HD broadcast level applications, such as ENG, live EFP and STL.
What it's not
DPR is not a store-and-forward technology. DPR delivery is different than file-based transport systems such as Flash, Windows Media, Microsoft Silverlight or Akamai streaming. DPR is standards compliant, real time, full motion, full frame rate, high resolution video. It is a solution designed to transport broadcast-quality HD over any IP network including public Internet, telecom, cable, private/dedicated, LAN/WAN, wireless or satellite. It uses hardware encoders and decoders instead of decoding video and audio inside a browser embedded software decoder running on and displayed on a PC.
DPR supports both Single Program Transport Stream (SPTS) and Multiple Program Transport Stream (MPTS) with ATSC PSIP tables. It provides bidirectional transport with 256-bit AES encryption for video, VoIP, high fidelity audio, LAN; all with low latency, QoS and network management. DPR goes much deeper than SMPTE 2022 Forward Error Correction (FEC), which enables the transmission of robust live streams across previously unusable networks.
DPR operates at the packet stream level and is transparent to the encoding technology. It supports encoded HD, SD, MPEG-2, H.264, and JPEG-2000. It provides correction to network induced issues including jitter, out of order packets, dropped packets and burst loss. DPR is designed to provide much broader and stronger protection than standard FEC techniques.
An integrated remote network management system provides complete control of all devices for network access, monitoring, storage, distribution and status reporting. It constantly verifies network performance in resolutions of once per second for all network devices and the Internet carrier service. This proactive approach maintains a healthy and reliable network, essential for delivering uncompromised video quality and performance
The Brick
The DPR "Brick" is a standards-compliant H.264 encoder, bidirectional audio system, hardware decoder, Ethernet switch with QoS, encrypted tunneling hardware, with convenient user connection points. When paired with the mating hardware at the "studio" end, it allows the user to rapidly deploy a full-featured audio/video system utilizing low-cost Internet such as DSL, cable or 4G modems. Encoders are available supporting SD-SDI, HD-SDI, ASI, composite, TSoIP and HDMI inputs.
The DPR system enables encrypted tunneling and auto-homing to the studio eliminating IT connectivity and VPN issues. Tunneling is widely used in virtual private networks. The hardware/software tunnels in the DPR system are layer 2 and don't depend on special protocols such as GRE to establish and secure the connection between the two sites. Traditional IPSec (most secure) or PPTP (less secure) VPNs often have trouble establishing connections through inexpensive routers. This is a major drawback for a traditional VPN implementation. DPR designer engineers moved to the tunneling approach after having difficulty passing IPSec VPN traffic from their homes and hotel rooms. These sites often use inexpensive consumer grade routers that have difficulty passing the protocols used by traditional VPNs.
Auto-homing as the term is used here, describes how the client end of the tunnel finds the central site. Each tunnel has a client and a server side. The server side can host multiple clients. In other words, a mobile system is configured as a client and points to the server. The client is provisioned to look for the server and only needs to have an Internet connection to find home. Each end will automatically find the other. There is no need to deal with IP addressing in the field, eliminating guess work
Latency is always an issue in live TV and is adjustable to as low as 100ms or up to as high you want. Why would you want to crank up the latency? More latency provides more time to recover dropped packets.
On a pristine network, where the system is operating purely as a safeguard, 200-300ms would be typical. For a mobile system with unknown Internet quality, users typically run anything from 2-7 seconds of delay. The length of the delay in the system is a function of the number of retries allowed for a dropped packet, and the round trip time allowed.
Bandwidth depends on the application. In an STL scenario delivering an ATSC 19.39Mb/s stream from the studio to the transmitter, the system would like to see a minimum of 25Mb/s bandwidth at the transmitter. That overhead deals with any dip in the Internet service and provides space for other services being delivered to the transmitter site, such as LAN data, high-fidelity audio, VoIP and site control data like transmitter remote control, video surveillance and alarms, generator, fuel levels and tower light monitoring, among others.
In an ENG application, bandwidth will depend on whether the source is SD, HD, MPEG-2 or H.264. Typically, H.264 SD is transported at a video rate of 1-3Mb/s. In that scenario, the system would like to see around 4-5Mb/s of service. For HD, H.264 streaming at a video rate of 6Mb/s and would need approximately 8-10Mb/s of bandwidth. In general terms, it's best to reserve about 25 percent of the bandwidth for overhead.
Let it rain
Instead of parking the ENG or SNG vehicle, raising the antenna, covering cables across sidewalks with duct tape and hoping no one trips, the user simply connects the DPR to the Internet. As it boots up, it automatically establishes a protected connection. It then sounds the network for throughput speed, jitter and latency. From these results, the encoder and network protection parameters are set. Plug in your audio and video sources into an encoder connected to the DPR and you're ready for live broadcasting.
High-speed Internet connections are available nearly everywhere. During severe thunderstorms and lightning, the Internet is more reliable and significantly safer for operators in the field than a satellite or terrestrial RF vehicle. Even during the nicest weather, anyone who has ever been dispatched in an ENG van at the last minute to a breaking story at a nightmare location with impossible parking and a canopy of trees and utility lines might be thinking a little more seriously about this realistic Internet alternative.
The author would like to thank Rick Cabalka at Superior Access Solutions for his assistance in preparing this tutorial.
