over the Internet using MPEG-DASH Real-Time Broadcast Video Services over the Internet using MPEG-DASH Backhaul and Primary Distribution over the Internet does not require service contracts, special IT knowledge, or expensive adapters. This is now simple to do.
Executive Summary There is a simpler alternative to traditional real-time broadcast video service transport. This alternative uses the Internet lingua franca, HTTP, in the form of MPEG-DASH adaptive bitrate live profile. In this paper, the phrase traditional real-time broadcast is given context and then followed by a brief introduction to MPEG-DASH. The old and new are contrasted, and finally the end-to-end quality of service delivery with MPEG-DASH is investigated.
Context for Change Traditional real-time broadcast video services are often considered to be Standard Definition and High Definition compressed below 20Mbps using either MPEG-2 or Advanced Video Compression (AVC). Synchronized Audio usually includes 2 to 6 channels PCM, AAC, or HE- AAC. Ancillary data, such as closed captions, may also be present. Transport of these compressed signals is then required among and between two or more locations and using a variety of techniques. The encoded audio, video, and ancillary channels are multiplexed into a Transport Stream then wrapped, seven per Ethernet packet, for IP delivery (MPEG-2 TS/IP or SMPTE 2022-2). This is also called Light Contribution or Primary Distribution. Example 1: Station Group Centralcast using Constant Bitrate MPEG-2/AAC frame compression over high bitrate private networks using Forward Error Correction (FEC) packet recovery. Good for Point to Multipoint Primary Distribution. Example 2: Special Event Live-to-Air using Variable Bitrate AVC/HE-AAC compression with buffering and Automatic Repeat request (ARQ) packet error recovery from the field to a production center. Good for Occasional Use Live Events. A new live transport technique is emerging that uses the public internet and the very simple file transfer protocol known ubiquitously as HTTP.
MPEG DASH Arrives The Motion Pictures Engineering Group (MPEG) created the international standard Dynamic Adaptive Streaming over HTTP (DASH) as a means to converge from many into one the existing family of Adaptive Bitrate (ABR) distribution technologies: Apple HTTP Live Streaming, Microsoft Smooth Streaming, and Adobe Flash. All of these must have an input video source that is encoded and pre-processed in sequential time slots and then delivered as files, where each file contains the compressed media for one time slot. The number of video frames per time slot is typically both fixed and between 30 and 600. These files are called segments and have the special property of being capable of stand-alone decode. In other words there is no motion prediction across file boundaries. The audio is in a separate file and shares a presentation timeline with the video for synchronization. MPEG-DASH is interoperable ABR. [Note: Adaptive Bitrate can be confusing. Just be aware that in this context, adaptive refers to the decoder adapting to network conditions. Adaptive does not refer to the encoder dynamically changing the level of compression. The ABR encoder is designed to simultaneously output many versions of the compressed video as files distinguished by the quality in direct proportion to the file size. In other words, the bigger the file size the higher the quality. ] Today, ABR is primarily used for video-on-demand (VOD). However, live ABR, specifically the MPEG-DASH Live profile, is beginning to attract attention. The two big differences between Live ABR and VOD ABR are time synchronization of the seek logic and the complexity in the decoder rate adaptation. For example, when the decoder first detects network trouble, does it immediately abort and adjust to a lower quality or wait with potential disastrous consequences of buffer underun? Lastly, MPEG-DASH allows for encapsulation in an appropriately flexible and standardized format called ISO Base Media File Format (ISO-BMFF or MP4). ISO-BMFF is specifically designed for multi-media file transport and better for ABR than MPEG-2 TS/IP. This whitepaper is focused on real-time live ABR. How can file transfer be Low Latency? It s Relative The minimum end-to-end latency of ABR is typically between 5 and 60 seconds limited primarily by how many frames are encoded in each segment file. At 720p60 fps (frames per second), if the encoder is configured for segment file duration of 600 frames then it takes at least 10 seconds to accumulate and encode. Plus 10 more seconds are buffered during file receive and decode. Finally adding transmission delay and error recovery increases end-to-end latency up to 30 seconds. However, with careful attention to encoding parameters and decoder rate adaptation algorithms, a low end-to-end latency is possible, even less than five seconds!
Pull Video from the Encoder versus Push Video to the Decoder ABR transport is started when the Decoder requests to pull media files from the Encoder s built-in web server using the HTTP protocol. Pulling files using HTTP requires the establishment of a reliable two-way communication path using the Transmission Control Protocol (TCP). TCP lies in contrast to existing methods where Video over IP data packets are pushed from the Encoder to the Decoder typically using the one-way User Datagram Protocol (UDP) protocol, commonly called TS over IP (TS/IP). UDP reliability is enhanced by the number of Forward Error Correction (FEC) packets delivered with the media packets. The more FEC packets sent, the more reliable the service. ABR uses TCP while your existing service likely uses UDP. TCP TCP is suited for applications that require high reliability, and transmission time is relatively less critical. TCP handles reliability and congestion control. There is an absolute guarantee that the segment file remains intact. TCP is slower due to automatic repeat request (ARQ) round-trip time. UDP UDP is suitable for applications that need fast, efficient transmission, such as games. There is no ordering of messages and no tracking connections. There is no guarantee that the packets sent will reach the destination. UDP is faster because there is no repeat request. TCP packets are buffered at decoder. Lost packets are requested again. Quality switch up or down according to buffer and estimated throughput. Aqua = estimated throughput Navy = chosen quality level Green = video buffer level UDP packets are buffered at decoder and lost packets are detected in the buffer and recovered using FEC. Under bad conditions, correction may not be possible. Data packets are Blue FEC packets are Red
Quality of Service Measurements Automatic Repeat Request (ARQ) ARQ is an algorithm for reliable two-way communications. ARQ is part of TCP. ARQ can be added to UDP. Bandwidth measured in bits/second is the maximum rate that information can be transferred. TCP will optimize use of the available bandwidth. For UDP, this MUST be known in advance. Throughput measured in bits/second is the actual rate that information is transferred. TCP will adapt to low throughput. UDP will collapse. Latency measured in milliseconds is the delay between the sender and the receiver. This is mainly a function of the packets travel time, and processing time at any nodes the information traverses. Latency will delay TCP ARQ. UDP is not affected by latency. Jitter measured in milliseconds is the variation in the time of arrival at the receiver of the packets. With high jitter, the Decoder (UDP and TCP) will always resort to packet recovery logic. Error rate is the number of corrupted bits expressed as a percentage or fraction of the total sent. For TCP, error rate will be measured in segments (Segment Error Rate). For UDP error rate will be measured in packets (Packet Error Rate). 1. Decoder Requests to start video. This is optional with UDP since Encoder is allowed to start at any time 2. Encoder begins to transmit packets to Decoder 3. Decoder detects lost packet due to timeout delay in buffer and requests a re-transmission 4. Encoder sends replacement 5. Decoder acknowledges good packets Takeaway: ARQ improves reliability, requires buffering and adds latency. TCP failures will cause ABR file transfer failure. At the decoder, this is corrected by pulling a different file that is smaller in size. This is repeated until the file arrives or the buffer underruns. When throughput later increases then the decoder again pulls the higher quality segments. Bandwidth Throughput Quality of Service UDP failures will cause packet loss. At the decoder, FEC and ARQ can be added to correct the packet loss. FEC adds latency and overhead. ARQ also adds latency and requires a two-way communication channel. Video errors result if the lost UDP packet is not corrected in time. Bandwidth Throughput TCP Packets Time UDP Packets Time When throughput is reduced, ABR with TCP maintains a reduced Quality of Service while UDP simply fails.
over the Internet using MPEG-DASH Inside the Workflow IP networking is on a trend to replace all other protocols where professional video is compressed for broadcast transport. This change has been underway since 2000 facilitated by sales of IP equipment vendors. So by now, your workflow includes IP data networking for better or for worse. The security of your IP data network assets, including video workflow, demands oversight by IT specialists. Most workplaces have dedicated staff who understands Network Address Translation (NAT), Domain Name Services (DNS), Dynamic Host Configuration Protocol (DHCP), Dynamic Port Forwarding (DPF), and Content Delivery Networks (CDN). Firewalls and routers provide this security by enabling various configuration settings to grant or deny network traffic both into and out of your Local Area Network. IP networking is both simple and complex. HTTP is SIMPLE. There are millions of web browsers using HTTP every day. Over the years great effort has been exerted to both simplify and secure this protocol. Behind the scenes, operating systems and modern web browsers cooperate with corporate IT firewalls and routers to streamline the HTTP protocol. MPEG-DASH uses HTTP. Most CDNs understand HTTP and can provide transparent and convenient point to multipoint delivery. In contrast, configuring a private service using UDP is COMPLEX. This is because most, if not all, UDP services are filtered by your firewall. Working with UDP services demands special configuration of firewalls and routers in order to allow video over IP traffic to flow. A choice must be made to either move your video adapters outside the firewall or schedule your IT administrator for custom firewall configuration. With MPEG-DASH, press GO and see results. Or configure your LAN, Firewall, and ISP to play nice with your UDP Service.
Conclusion The technology in Adaptive Bitrate Encoding is SIMPLE and POWERFUL. ABR is used by all high quality Over the Top (OTT) consumer video servers. The magic behind a high quality OTT video experience is HTTP and the public internet. It is important to know that ABR is not only for consumers but can also be used for contribution and primary distribution applications. During high internet congestion, with ABR, you do not lose your picture. Instead there is only a temporary quality reduction. Over days and weeks, with ABR, the average quality is higher as the decoder dynamically adapts to time varying increases in available throughput. With ABR, your IT administrator will never call asking why the ISP throughput collapsed when you started your video service. When ABR detects competition for bandwidth, it backs down allowing other services to continue. In summary, ABR can be used for contribution and primary distribution, not just OTT. In fact, when the end-to-end network is unpredictable ABR may represent the only reliable option. We invite you to try the new PiXiE AVC HD encoder/decoder with MPEG-DASH. Visit www.path1.com/products/pixie Simple. Reliable. Video from anywhere to everywhere over the Internet. 6650 Lusk Boulevard, Suite B100 San Diego, California 92121 www.path1.com 858.366.4391