
SPONSORED WHITE PAPER
|
Video Distribution Systems |
For many years systems designers have faced the challenge of transmitting video signals with acceptable quality, typically using copper coaxial cables as the medium. These signals are subject to the noise, attenuation and bandwidth limitations associated with this medium. While the use of other media such as fibre optics avoids many of these problems, a different challenge remains; the increased number of sensors in complex installations and the need to present multiple video feeds on typically one or two high-resolution displays at each of many consoles. Conventional video switching, whatever the physical medium, places fundamental limitations on the number of sensors and displays that can be connected to each other and often introduces a single point of failure at the switch itself while providing insufficient flexibility for the addition of further sensors as the system is upgraded or enhanced.
The widespread availability of very high-speed packet-switched digital computer networks provides one solution to the problem of distribution of multiple high-resolution video signals. The potential benefits associated with these networks, including resilience, flexibility, security, low latency and high speed, make them eminently suitable for the transmission of video over short or long distances. This article summarizes some of the key technologies involved in constructing a video distribution system (VDS).
Before video signals can be sent on a digital network, they must first be converted to digital format. However, a digitized uncompressed television-quality video signal requires a transmission rate of approximately 20 Mbyte/sec or 160 Mbit/sec, with higher resolution signals such as HDTV imposing even higher demands on the network. It can be seen that even modern networks supporting data rates of 10 Gbit/sec could reach saturation when required to carry data from many sensors in a moderately complex installation. As a result, some form of data compression is highly desirable when sending video data across networks.
The key factors to be considered when choosing appropriate compression algorithms include image quality for a given compression ratio, suitability for image type (sensor images or synthetic symbology), latency and easy availability of encoder/decoders (codecs), including hardware assist where necessary. A common choice is JPEG 2000, a wavelet-based algorithm that offers higher quality than its DCT-based JPEG predecessor and which also supports lossless compression where the highest quality is essential, perhaps to allow further image processing after reconstitution. A popular alternative is MPEG-4 Part 10 (H.264), a multimedia coding standard which is the successor to the widely used MPEG-2 and provides efficient transmission of moving video images and audio with intrinsic resilience to network errors. JPEG 2000 is well suited to high-quality compression of sensor or synthetic images with minimal latency, while MPEG-4 is suited to compression of conventional moving images. CWCEC’s Orion PMC/PCI card is an example of a product supporting two channels of JPEG 2000 hardware-assisted encoding/decoding.
 |
For transmission on a digital network, the compressed or uncompressed video image must be encapsulated or packetized. Digital networks typically support the Internet Protocol (IP), a data-oriented protocol that in turn comprises a number of standard methods for encapsulating and transmitting packets of digital data. IP itself is a connectionless protocol, not requiring setup of any circuit to the receiver, and requires additional ‘layers’ of protocol if a reliable end-to-end connection is required. For the purpose of video distribution, issues such as packet sequencing and retransmission after detection of missing or corrupted packets are typically less significant. Occasional missing images can be resolved by replication of the last known good image, while protocols such as MPEG-4 can have built-in recovery from missing data.
Two core members of the IP suite are User Datagram Protocol (UDP) and Transmission Control protocol (TCP). UDP does not provide packet reordering or guaranteed delivery and is thus well-suited to a time-sensitive application such as VDS where dropped packets are preferable to delayed packets. It also allows broadcasting of data (sending to all hosts on the network) and multicasting (sending to all hosts subscribed to a specific multicast address), multicasting in particular being very well suited to a VDS application where a video stream from a given sensor may be required at multiple consoles but where it would be undesirable to send a separate stream (thus increasing the network load) to each such console.
While UDP can be used as the underlying basic packet transmission mechanism, a VDS of any complexity will require a higher level of protocol to provide facilities such as quality of service negotiation, image timestamping and delivery monitoring. The Realtime Transport Protocol (RTP) is an IETF standard which defines a standard packet format for delivering audio and video over a digital IP-based network. The RTP Control Protocol (RTCP) is used alongside RTP; it transmits periodic control packets to participants in a streaming session and is used to monitor the quality of service provided by RTP to allow, for example, limitation of the network data flow rate by increasing compression or dropping packets. RTP itself is algorithm-independent, and can carry a ‘payload’ of packets from a JPEG 2000, MPEG-4 or other compressor. The use of RTP in a VDS essentially guarantees an ‘open system’ with interoperability of components from different vendors. Figure 1, below, illustrates the core components of a server/client-based VDS.
 |
Figure 2 - VDS Block Diagram |
While the essential components of a VDS are image capture, compression, decompression, reconstitution and display, other functions can add significant value to the system. One of these functions is the ability to record digital video streams for subsequent playback, either through the VDS (the playback function acting as an alternate video input to the system) or on a local console. The video will typically be recorded in its compressed form to reduce storage needs. Advanced functionality would include delayed replay-while-recording for use during a mission. The potential applications of high-quality digital recording and playback include debrief, training and forensic evidence.
A VDS server may also implement initial processing of the input video data, including sensor fusion (for example, the combination of input from day, night and thermal imaging cameras) and image stitching (for example, to form 360 degree views).
In summary, a VDS designed using state-of-the-art technology will support sensor and synthetic video input from ‘legacy’ low-resolution TV up to HDTV and high-resolution component video (typically 2560 x 1600 pixels), will allow selective use of one or more compression algorithms suited to the characteristics of the video inputs and the network performance, will use standard network protocols and will offer flexibility and scalability. It will be suited to a wide variety of benign and rugged applications including airborne (manned and unmanned), naval, ground vehicle (including local situational awareness) and simulation, and will be based on leading-edge network technology suited to the operating environment.
May 1, 2008
[back to top]
Comments on this article? Send them to comments@fpgajournal.com
|