Current Issues in Streaming Media

Transcription

1 Current Issues in Streaming Media Fabian Meier, January This paper discusses current and past issues in Streaming Media. The goal is to outline specific problems that are solvable by technical and other means. The first section lists issues that were big obstacles in the past few years and how these problems have been solved today. The second section discusses five current issues in Streaming Media. Three issues are technical problems and two issues are of non-technical nature. When solutions for those five issues have been found, streaming media technology has the potential to dominate media distribution and as a consequence replace the current broadcast TV distribution, cable TV distribution and physical video rental. Past Issues The past from a streaming media perspective means the last five years. Five years ago the Internet began to take off, the MPEG video compression standard started to get broad acceptance and RealAudio was launched. The fundamental question used to be is streaming audio and video over the Internet possible at all? The following areas used to be a focus of streaming products and research. Video Compression Technology Problem: Video compression used to be an exotic technology. PC s were to slow to encode or decode compressed video in real-time. Today: There are many free and commercial video codecs available. The quality of compressed video is good enough at low and medium bandwidths to find a wide acceptance among consumers. PC s Problem: In the past a typical PC was not fast enough to decode a compressed video in real-time not even to mention the more demanding task of encoding. Today: A typical below-thousand-dollar PC has enough CPU speed to decode a compressed video to a full screen in real-time. No extra hardware is required. Even encoding in real-time is feasible with a decent PC. Player Software Problem: There were only very few video decoder application available. Player software had to be downloaded from the Internet, typically it was not pre-installed on new PC s. Downloading video decoder software took a long time over slow modem connections. The first video streaming players didn t deal well with dropped packets and looked terrible. Today: There are 160 million RealPlayer installed worldwide. Microsoft Media Player is shipped with every new Windows PC, so is the QuickTime Player with every new Mac. Downloading and installing software over the Internet has become a lot easier.

2 Digital Video Problem: The equipment to digital video used to be very expensive. Digital video equipment was used by a very small user base, and ran on very expensive workstations. Digital recording equipment such as cameras and digital video tapes was very expensive. Today: The cost of video i/o boards, digital video editing software and hard disc space decreased dramatically in the last five years. $4000 buys a DV video camera, a video editing software package, enough hard disc and a powerful PC enough hardware and software to edit a full-length movie. The DV format and the Firewire technology were a catalyzer for affordable digital video. Streaming Media Servers Problem: There used to be only one product: RealAudio servers. Today: Today the market for streaming server software is highly competitive. There are many companies in this field which results in a high degree of innovation. Competing compression standards and streaming standards cause confusion and compatibility problems, but at the same time this competition keeps the pace of innovation high. Killer App Problem: When the first Internet radio broadcasts were compared to CD s and regular broadcast radio, Internet radio looked complicated, clumsy and amateurish to the streaming media outsider. For the emerging streaming media field Internet radio was a proof of concept, for the rest of the world it was another wacky idea. Using the Internet for streaming radio stations seemed to be a waste of valuable bandwidth. Today: Internet radio is a killer app for streaming media. Using Internet radio is very reliable and uses relatively little bandwidth (14kbps 56kbps). There are around currently around 4000 Internet radio stations worldwide. The only major technical problem of streaming radio is the start-up times (this topic is discussed in the next section). The Last Mile Problem Problem: The last mile problem was perceived to be the main bottleneck for broadband Internet uses. Fiber to every house was the obvious solution, but the general consensus was that it would take a long time to install this infrastructure; therefore streaming video would not be realistic for consumers any time soon. Today: The last mile is not the main problem anymore. DSL and cable connections are only two to three times more expensive than a modem connection over a phone line and are relatively easy to install. DSL and cable modems don t require a complicated fiber installation, they operate on existing cable TV and phone lines. The majority of modem users have 56k modems. The number of DSL and cable modem Internet users is in the millions. The average DVD bandwidth is around 5 Mbps (DVD is using MPEG-2), with the newest compression standards similar quality can be achieve with rates between 800 kbps and 1.5 Mbps. However, this is still higher than most DSL rates which are typically around 400 kbps. The important thing is that the video quality over a 400 kbps connection is good enough that streaming over a DSL line can be become a serious challenger of Video, DVD and cable TV usage. From an economic point of view the Internet backbone cost is the current bottleneck. Hollywood Problem: The early adopters of streaming media were radio stations. The first streaming video applications were used stamp size video resolutions and the compression artifacts didn t impress the content providers and creators. Video conferencing was the obvious application for streaming video over the Internet. Today: Video conferencing over the Internet is still not a very popular application, mainly because of the high network latencies. Hollywood is waking up it realizes that streaming media is new and very important distribution medium. The success of the DVD helped the acceptance of compressed video.

3 Current Issues This section lists issues that have to be address in order to make streaming media a successful technology, without elaborating in detail how a specific solution could look like. A solution could be a product, a standard or simply a number of circumstances. For example the reason for decreasing Internet backbone bandwidth cost is a combination of new products, consumer demand, open standards and regulatory factors. The first three issues are of a technical nature that can be addressed with technical solutions, the other two issues are of a non-technical nature. 1. Current Streaming Protocols don t cope well with Internet Congestion The current streaming protocol implementations don t deal well with Internet congestion at higher rates (DSL rates and above). The emphasis on edge caching or edge streaming of a number of products and services supports this assumption. The inability to deal with real-world networking conditions at higher bandwidths results in the annoying blinking congestion message in a player application. A streaming media protocol should be able to deal with the following three Internet traffic categories:?? Constant packet loss between 2% and 10%. Typically backbone routers drop packets in order to manage heavy traffic.?? Changing latencies between 50 and 300 ms. Latencies are caused by queued packets in a router. Each router between a client and a server adds extra latency.?? High packet loss events. If a router becomes too congested due to high traffic, the router will drop packets during a period between 1 to 10 seconds. A router can only hold a finite number of packets in its queue, dropping packets is a way to decrease the number in the queue. All these events result in varying bandwidth and varying latency. Current streaming implementations don t deal well with these conditions. Some streaming solutions are very good at covering up the effects of packet drops. Load Test on a RealServer A load test on a RealServer (details can be found in the Appendix) showed the behavior of the server under different networking conditions. A network emulator was used to simulate the Internet. The conclusion of this test was that the RealServer does not deal well under minimal network traffic (latency larger than 100 ms and 5% constant packet loss) at DSL rates. If there was minimal packet loss and latency the RealServer had a significantly lower throughput between server and client than the actual available bandwidth. However, at Modem rates (56 kbps) the RealServer and RealPlayer dealt very well under intense traffic conditions The RealPlayer approaches Internet congestions with switching automatically to a lower bitrate (SureStream Technology) and does sophisticated video post processing to compensate for the lost packets. Conclusion A good streaming protocol should be able to deal with all different types of Internet congestion and should be close to the upper bound of the average throughput. Some TCP implementations are actually pretty good getting close to the upper bound under different networking conditions. The upper bound is the average bandwidth between a server and a player, regardless of any latencies. Streaming media will be accepted as a mature technology if a streamed video at DSL rates can be viewed without any visual degradation despite intense network congestion.

4 2. Proprietary compression standards Dealing with different, incompatible streaming player applications is a mess for end users and the streaming media industry. The issue is complex. There are two main reason why RealNetworks, Microsoft (with their MPEG-4 flavor) and Apple (Sorensen codec) are pursuing their proprietary video codec strategies:?? Fast innovation cycle (Good reason). Having proprietary protocols and codecs allows RealNetworks to have the transmission protocol code, the video codec and the video post processing unit work tightly together. The result is impressive: even without SureStream, the RealPlayer does an excellent job at displaying streamed video even if a significant number of packets are lost. The freedom of a company to innovate and improve their algorithms results in a faster development cycle than if every change has to go to a standards committee. An important property of a standard is that a standard does not change. This is a contradiction to the need to improve algorithms and functionality constantly.?? Control over player and server software (Bad reason). A company with a proprietary closed standard and a large distribution of player software (there are 160 million installations of the RealPlayer) might not be very willing to share that wealth with anybody else. Apple and Microsoft have a different business strategy than RealNetworks: Apple and Microsoft give their streaming server software away for free because they want to push their OS sales whereas RealNetwork focuses on making money with streaming products. For example the new version of Microsoft Media Services is free, but it runs only on the Windows NT server OS (it can t be installed on a NT workstation). A solution that the three big players in streaming (RealNetworks, Apple and Microsoft), other streaming media companies, end users and content providers might like is a third party player with plug-ins. Such a player would be most likely an open source project, and it would use open and proprietary decoder plugins. 3. Slow Player Start-up time Today the time between pressing the play button on a streaming player and the actual start of the medium is anywhere between 5 and 30 seconds. This slow start-up time of a streaming media player results from buffering on the player side. The size of the buffer is configurable in some streaming players. The reason for using a buffer is to absorb network jitters (changing network latencies). Today a user can choose between a long start-up time and smooth media playback (larger buffer size) or a shorter start-up time and more interruptions in the media playback. A player with a start-up time that approaches a lower bound of start-up time should be feasible. The lower bound for the start-up time is the network round trip time (RTT) plus the time to decode the first group of pictures (GOP). The RTT is between 100 ms and 1000 ms, the time between two Intraframes between 1 and 7 seconds. Therefore the lower bound could be as low as one or two seconds. In order to compensate for streaming protocols that don t cope well with Internet congestions the buffer size gets increased. One way to shorten the start-up time is to sacrifice the video quality by reducing the bitrate of the video stream during the first seconds. A more sophisticated approach would be to select the bitrate and the time when the bitrate is below the target encoding bitrate for each stream, the decision would be made as a function of the current networking conditions between the streaming server and the client.

5 4. Internet Backbone Bandwidth Cost Internet Backbone bandwidth cost is still very expensive a T1 line (1500kbps) costs around $300 to $1000 per month. One explanation for the high cost is that the backbone capacities are still relatively small. UUnet is one of the largest backbone providers in the world. It connects the metropolitan areas and data centers worldwide. Between the East Coast and the West Coast of the US UUnet runs about eight OC48 pipes with a bandwidth of 2.5 Gbps each total 20 Gbps. This is enough bandwidth to support only around 50,000 streaming connections at 400 kbps (DSL) rates. Or this is enough for only 13 streams of uncompressed HDTV bandwidths of 1.5 Gbps. Current Approaches Avoiding using the expensive backbone seems the best solutions at the moment. Two different solutions approach this problem: Caching and Content Delivery Networks (CDN). Caching is done by installing streaming media caching appliances (for example CacheFlow appliances) inside local ISP s just before the backbone connection. The idea behind a CDN is that it is cheaper not to stream over the backbone by installing streaming servers inside large ISP s (one example of a CDN is Akamai). These two solutions work only for certain streaming applications well: caching works well for popular content and CDN serve only content from content providers that pay the CDN to host their content. In addition to savings on backbone cost both approaches improve the quality of service (QoS) of the streaming connection between server and client. Because a CDN streaming server is located closer to the end user, there are less routers between the server and the end user, which reduces latency and packet losses. Future Approaches The backbone cost is decreasing constantly, hopefully with the same speed as Moor s law. Continuous investments into the public and private Internet infrastructure, progress in networking technology and an increasing demand are factors that will drive the backbone cost down. 5.Security Concerns of Content Owners Movie studios and TV stations will be hesitant in making their content widely available if their concerns regarding piracy can t be adequately addressed. These are the main concerns:?? Illegal copies. Streamed content could be copied to the local hard disk, even if the content was encrypted. The encryption can be broken.?? Illegal distribution. Illegally copies of streamed content can easily be copied to a CD-ROM or made available through streaming from a location outside the US. Possible Solutions:?? Encryption. Each streamed content can be individually encrypted at the streaming server such a system is a lot more secure than the current DVD encryption.?? Watermarking. In addition individual watermarks can be added to each stream at the streaming server, so the person who made illegal copies can be identified.?? Information on usage. A central information system that provides up to the minute information on when and how each content is being used might address certain concerns of content owners There are a number of products available that address these concerns. Individual solutions might most likely not address the overall concern enough. Despite the best encryption between a movie studio and the streaming server, the streaming server and the player, at one point the compressed video has to be decoded. The decoded video can be captured with hacks at any location in the PC: from RAM, disk, bus, etc. Once captured, the bitstream can be decoded and then again encoded into any format. The best way to protect the content is to pipe the encrypted stream

6 directly into a video card, where the bitstream is decrypted and decoded in hardware. Even then, the analog or digital output to the monitor can be captured on a second PC with a $100 capture card. The same issue applies to copying copy-protected DVDs. Conclusions All the discussed five issues are solvable. The interesting question is what will happen when these issues have been addressed? Will there be one dominating player with a proprietary technology or will open standards prevail? And how will new functionality from new technologies such as MPEG-4 influence current and new applications of digital media?

7 Appendix: Testing the RealServer with a Internet traffic emulator Goal of the Test: Different Internet congestions are simulated in the reproducible lab setup. The RealServer streams a clip to a RealPlayer over a simulated Internet. This test measures the actual throughput of the streaming connection under different networking conditions (packet drop and latency/jitter). Ideally the throughput should not be affected much by the tested networking conditions. Test Procedure: A RealServer on workstation 1 streams content over an network emulator (The cloud, from Shunra), also on workstation 1, to a RealPlayer on workstation 2. Two different clips are used: a bitstream encoded at 36 kbps and a bitstream encoded at 362 kbps. Per session (each clip has a length of 2 Minutes and 38 seconds) the networking conditions (settings in the the network emulator) are not changed. Each session has different latency and packet drop settings. The measured result per session is the actual achieved average bandwidth (throughput) during the play time (including the start-up time of the RealPlayer). The average bandwidth is taken from the statistics panel of the RealPlayer. A cross check with the bandwidth measurements of the network emulator makes sure the measured value is correct. It is important to note that the bandwidth values from the RealPlayer are rough estimates. Each session at different networking conditions is a data point in the diagram of Figure 2 (a session is a white square with a measured throughput value in kbps). Note that for packet drops of 10 % the maximum bandwidth is also 10 % (for example a DSL connection with a maximum bandwidth of 384 kbps will therefore have a maximum throughput of 0.9 * 384 kbps). The measured average bandwidth in the RealPlayer with perfect networking conditions (no packet drop, no latency) is about 30 % higher than the actual encoded bitrate either the displayed bitrate number is too high or the actual bandwidth of the streaming protocol is higher than the encoded bitrate (this would be faster than real-time transport). Test Setup Workstation 1 (RealServer): Windows 2000, 500 MHz, 512MB RAM Software: - RealServer 7, 1 stream served to RealPlayer on Workstation 2 Test clips: - Encoded with RealProducer one bandwidth, SureStream option was turned off. - Clip 1 (DSL rate): stave_384.rm, 2:38 min, 6,986 kb, average bitrate = (6986 * 8 *1024 Bytes)/ 158 s = 362 kbps. Bitrate in the RealPlayer Statistics Window: 350 kbps. Codec: RealVideo 8.0, 30 fps, video bitrate = 318 kbps - Clip 2 (Modem rate): stave_56.rm, 2:38 min, 700 kb, average bitrate = (700 * 8 * 1024 Bytes)/ 158 s = 36 kbps. Bitrate in the RealPlayer Statistics Window: 34 kbps. Codec: RealVideo 8.0, 15 fps, video bitrate = 29 kbps Internet Emulator: Shunra, The Cloud. This emulator software works between the windows sockets and the Ethernet card driver (similar to a packet sniffer). The software can drop IP packets, add delay to each packets and also measures the actual througput. It also can limit the bandwidth. Emulator Settings: Maximum Bandwidth: 1.5 Mbps. This setting makes defines an upper limit through the network emulator (since 384 kbps was the highest bandwidth used, this feature was really never used).

8 Packet drops: 0%, 2 %, 4 %, 8% (random packet drops. 8 % means that 8 out of 100 IP packets are dropped). Network Latency (this emulates network jitter): randomly changing latency, with a gaussian distribution, stdev= 50ms, mean: 0 ms, 50 ms, 100 ms, 200 ms, 300 ms, 500 ms, 600 ms. Workstation 2 (RealPlayer): Windows NT, 900 MHz, 512MB RAM RealPlayer 8 Basic. Conclusion: See Section 1) under Current Issues. The viewing quality is highly dependent on the networking congestions. At DSL rates the Real protocol performs very poorly inside typical Internet congestions (latencies between 50 and 250 ms; 0..6 % of random packet drop).

9 Figure 1: Physical and Logical Test Setup

10 Figure 2: Measured Througput under different Networking Conditions Measured Througput vs. Continous Network Conditions (Latency, Packet Loss) (DSL bitrate) RealServer 362 kbps, test clip: stave_384.rm 600 ms Legend 500 ms 27 Measured Throuput in [kbps] Latency [ms] 400 ms 300 ms 200 ms Throuput with ideal network conditions in [kbps] Range of excellent viewing quality of the bitstream in the RealPlayer 100 ms ms 0 % % 8 % 12 % 16 % Packet Loss [%] Range of typical real world networking conditions Measured Througput vs. Continous Network Conditions (Latency, Packet Loss) (Modem bitrate) RealServer 36 kbps testfile=stave_56.rm 600 ms ms 400 ms 45 Latency [ms] 300 ms ms ms ms 0 % 4 % 8 % 12 % 16 % Packet Loss [%]