CHAPTER 10
Audio and Video Streaming
In this chapter, you will learn about
• Conducting a needs analysis for streaming AV systems
• Conducting a network analysis for streaming AV systems
• Designing an AV streaming system that takes into account bandwidth, latency, and other requirements
• Compression and encoding
• Identifying the appropriate transport and distribution protocols for streaming
• Multicast and unicast distribution
• Devices and technologies required to stream AV to users
Streaming media comprises IPTV, live video and audio streaming, and video on demand. It is also the foundation for other networked AV systems, such as networked digital signage and conferencing.
In order to design a successful streaming application, you must think carefully about the customer’s needs and how they impact service targets. For example, how much bandwidth will your AV streams require? How much latency and packet loss can users tolerate?
Some answers depend on the network itself; some depend on how content is encoded to travel over that network. If you understand the concepts underlying the capture, compression, encoding, and distribution of digital media, you’re on your way to designing a variety of networked AV solutions.
Streaming AV Needs Analysis
When conducting a needs analysis for a streaming media solution—or for any networked AV system—you need to discover not only what the customer wants but also whether the current networking environment can deliver. Typical questions related to traditional audiovisual applications (regarding room size, viewer positioning, etc.) may be impossible to answer, because the customer may not know with any certainty where end users will be when they access streaming content. Instead of asking about the room where an AV system would reside, you need to delve into issues relating to streaming quality, bandwidth, latency, and delivery requirements. You need to think in terms of tasks, audience, endpoint devices, and content. And you need to explore these issues in the context of an enterprise network, not a particular venue.
Ultimately, what you learn in the needs analysis will help inform the service-level agreement (Chapter 14) for your streaming AV system—and possibly other more encompassing SLAs. Not to mention, as you’re collecting information about the customer’s needs, you should always ask yourself, “How is this going to impact network design?” Because eventually, you may have an IT department to answer to.
Streaming Tasks
In the design of any AV system (networked or non-networked), form follows function. The needs analysis begins with discovering the purpose of the system. Assume you’ve already established that your customer needs to stream AV. Why? What tasks will streaming AV be used for?
Decisions regarding bandwidth allocation, latency targets, and port and protocol requirements should be driven by a business case that is established in the needs analysis. How do the tasks that the prospective streaming system will perform contribute to the organization’s profitability, productivity, or competitiveness? If you can make a valid business case for why your streaming system requires a high class of service, opening UDP ports, or 30 Mbps of reserved bandwidth, you should get it. But you need to understand that “the picture will look bad if we don’t reserve the bandwidth” is not a business case. Conversely, “the picture will look bad if we don’t reserve the bandwidth, and if the picture looks bad, the intelligence analysts won’t be able to identify the bunker locations” is an excellent business case.
If there’s no business case for high-priority, low-latency, high-resolution streaming video, for example, then the user doesn’t need it and it probably shouldn’t be approved. In that case, be prepared to relinquish synchronous HD streaming video if the customer doesn’t really require it. Just be sure you document the lower expectations as your system’s service target.
The most basic question of a needs analysis is, “What tasks will the streaming system be used for?” Answering that question in detail should reveal the following:
• The importance of the system to the organization’s mission
• The scope of use (i.e., number and variety of users)
• The frequency of use
If the task is a high priority, the streamed content will require priority delivery on the network, which affects the bandwidth allocated and the class of service assigned to it. The nature of the task will also impact latency requirements. As you delve further into the tasks that the streaming system must support, you may ask questions such as, “Do users need to respond or react immediately to the streamed content?” If so, latency requirements should be very, very low—like 30 milliseconds.
Furthermore, find out: “Will any delay in content delivery undermine its usefulness?” This question is also aimed at determining how much latency is acceptable in the system, outside of immediate-response situations. And the answers will help address follow-on questions, such as, “Can we use TCP transport, or is UDP necessary?” and “How should the data be prioritized in a QoS architecture?”
Audience
The user is the star of the streaming needs analysis (or any needs analysis, for that matter). In fact, who the audience is specifically may be a major factor in a business case for a high-resolution, low-latency streaming system. We’re talking about the organization’s hierarchy here. If the main users are fairly high in the hierarchy—management, executives—they may demand a high-quality system to match their status.
If on the other hand the system will be used broadly throughout the organization, you may need to consider the bandwidth implications of such widespread use. Would a multicast work? (We cover multicasting in detail later in this chapter.) Should different groups of users be assigned different service classes? You’ll understand better when you identify the audience.
Where the audience is located, however, may be your primary challenge in offering a streaming system that meets the customer’s needs. It’s actually a far more complex issue when it comes to streaming applications than traditional audiovisual systems. Asking about location should reveal whether all users (the audience) are on the same LAN or WAN, and whether some users will access streaming content over the open Internet. How does that impact design? There are various reasons, including the following:
• Bandwidth over a WAN is limited.
• QoS and multicast are impossible over the open Internet.
• LAN-only solutions have a far greater array of data link and quality options.
Endpoints
Related to audience are the endpoints people will use to access streaming content. Your customer may need to stream data to a handful of overflow rooms, hundreds of desktop PCs, or thousands of smartphones. The number and type of endpoints have a direct impact on service requirements.
How many different endpoints does the customer need to stream to? With unicast transmissions, the bandwidth cost rises with each additional user. If the user needs to stream to a large or unknown number of users within the enterprise network, you need to consider using multicast transmission or reflecting servers to reduce bandwidth.
What kind of endpoints will people be using? Different endpoints support different resolutions, for example. If endpoints will be especially heterogeneous, you may want to implement a variable bit rate intelligent streaming solution. If most users will be using mobile devices, content must be optimized for delivery over Wi-Fi or 3G/4G cellular networks.
Content Sources
The type of content the customer will stream has a direct impact on the network, which in turn affects the streaming system design. Like other parts of the needs analysis, the content factors into decisions of bandwidth usage, latency targets, and class of service. Some basic questions to ask include the following:
• Do you need to stream audio, video, or both? Video requires far more bandwidth than audio. Codec options also differ based on type of media.
• How will content be generated? Video content generated by a computer graphics card may require more bandwidth than content captured by a camera. You also have different codec options for different sources.
• Will streaming images be full-motion or static? Still images, or relatively static images, require a lower frame rate than full-motion video.
• Will the customer be streaming copyrighted or DRM-protected material?
You will also need to consider how and where content will enter the network. This is often referred to as the place where content is ingested (or uploaded) and can be a computer, a server, a storage system, or a purpose-built network streaming “engine.” You should determine how many ingestion points there will be and ensure each has the bandwidth required for expedient uploading. In addition, how many concurrent streams, or “channels,” must be uploaded? The answer to this question should help establish how many video servers will be needed.
Moreover, can you exercise any control over the format, bandwidth, and other aspects of the content that will be ingested for streaming? If your customers are ingesting several different formats, they may need a transcoder, which automatically translates streams into formats that are compatible with the desired endpoints or are bandwidth friendly toward certain connections.
And when it comes to the streaming content itself, you may want to make recommendations on frame rates, resolutions, and other streaming media characteristics based on the network design you anticipate. For video, how much motion fidelity do users need to accomplish their tasks? Lower acceptable fidelity will allow you to use a lower frame rate. Higher fidelity will result in increased latency or higher bandwidth.
What level of image quality or resolution is required for the task? Again, the focus is on requirement, not desire. Use the answer to this question to help establish a business case: At what point will limiting the video resolution detract from the system’s ability to increase the client’s productivity, profitability, or competitiveness? How low can the video resolution be before the image is no longer usable?
Using Copyrighted Content
Your customers may wish to stream content that they didn’t create, such as clips from a media library or music from a satellite service. Unfortunately, such digital distribution can violate copyright laws.
Make sure customers are aware of the potential licensing issues related to the content they wish to stream. You may need to negotiate a bulk license with a content service provider, such as a cable or satellite television provider or a satellite music service.
If you fail to obtain the proper licenses to stream content, you aren’t just risking legal repercussions; you’re risking the system’s ability to function at all. Publishers and copyright owners use digital rights management (DRM) technology to control access to and use of digital data or hardware. DRM protocols within devices determine what content is even allowed to enter a piece of equipment. Copy protection such as the Content Scrambling System (CSS), used in DVD players, is a subset of DRM. Actual legal enforcement of DRM policies varies by country.
High-Bandwidth Digital Content Protection (HDCP) is a form of DRM developed by Intel to control digital audio and video content as it travels across DVI or HDMI connections. It prevents the transmission or interception of nonencrypted HD content. HDCP support is essential for the playback of protected HD content. Without the proper HDCP license, material will not play. It can be difficult—though possible—to stream to multiple DVI or HDMI outputs. All the equipment used to distribute the content must be licensed. When in doubt, always ask whether a device is HDCP-compliant.
Cheat Sheet: Streaming Needs Analysis Questions
Use the list of questions that follows to gather information from customers about streaming media applications. Consider how the users’ needs with respect to each item could affect the AV system’s design, cost, or impact on the network.
Tasks
• What task(s) will the system be used to perform?
• Do users need to respond or react immediately to the streamed content?
• Will any delay in content delivery undermine the usefulness of the content?
Audience
• Who is the intended audience?
• Where is the intended audience (on-site, within the LAN; off-site, within the company WAN; off-site, outside the company WAN; etc.)?
• What are the audience access control requirements?
Endpoints
• How many different endpoints (devices) do you need to stream to?
• What kind of endpoints will your end users be using to view content (desktops, mobile devices, large displays, etc.)?
Content
• What kind of content do you need to stream (e.g., full-motion video and audio, full-motion video only, audio only, still images only, still images and audio)?
• How will content be generated?
• Will you be streaming voice over IP (VoIP)?
• How will content be ingested into the network?
• For motion video, how much motion fidelity is required?
• What level of quality and/or image resolution do you require (SD, HD, best possible, adequate, etc.)?
• How many concurrent upload streams, or “channels,” do you require?
• How many concurrent download streams, or “channels,” do you require?
• What are the accessibility requirements, if any?
Storage
• Will content be available on demand?
• How long will content need to be stored?
• How quickly does content need to be propagated from storage?
• What are the backup and/or redundancy requirements?
Streaming Media and the Networking Environment
You’ve talked to users to find out what they need from a streaming media solution; now it’s time to visit the customer’s IT department. The network environment is as important to a streaming application as the physical environment is to a traditional AV system. You need to analyze the network as carefully as you would a physical room: explore its potential, discover its limitations, and recommend changes to improve system performance. Let’s get started.
Topology
In the needs analysis stage, you determined whether streaming users would be accessing content inside or outside a LAN. Remember that a LAN in this case is a single, openly routable location—until you’ve had to transverse a firewall, you’re still on a LAN.
If your streaming system will remain within a single LAN, you’re lucky. The system’s routing will be considerably less complex, multicasting will be far easier to implement, and bandwidth availability is unlikely to be a problem. If you’re streaming content over a WAN, however, you have several additional factors to consider:
• The physical location of streaming servers
• Bandwidth availability on every network segment
• The possible need for hybrid unicast/multicast implementation
• The addressing scheme of the organization
The addressing scheme will determine what information you need to gather for your ports and protocols document (see Chapter 9). It will also impact how access control and system control are managed. Can the system identify authorized users via DNS? Do you need to reserve a set of IP addresses for the streaming servers on the DHCP server?
Bandwidth: Matching Content to the Network
Bandwidth availability represents the single largest constraint on most networked AV systems. It will drive your choice of transmission method and codec for streaming applications. We cover these considerations later in this chapter.
Remember that the network is only as fast as its slowest link. The rated capacity of the network should be based on the bottlenecks—the lowest-bandwidth throughput link that data will have to traverse. Whatever the rated capacity of the network is, you can’t use all of it. That would be like mounting a display with bolts that can hold exactly the display’s weight; the first time someone bumps into the screen, it will tear right off the wall. How much of the network can you use?
Realistically, only 70 percent of rated network capacity is available. The remaining 30 percent should be reserved to accommodate peak data usage times and avoid packet collision. Some industry experts recommend reserving as much as 50 percent of the network for this purpose. Ask the network manager what network capacity is available for each customer.
In a converged network, of the 70 percent considered “available,” only a portion should be used for streaming media—about 30 percent of the available 70 percent; or, put another way, 21 percent of the rated network capacity. Otherwise, you won’t have enough bandwidth left for other network applications.
Your goal, then, is to design a streaming application that consumes no more than 30 percent of the available network capacity. You may also need to implement some form of bandwidth throttling to prevent the streaming application from overwhelming the network during peak usage, setting the limit at that 30 percent mark. Traffic shaping will introduce latency into the stream, causing it to buffer but preserving its quality. Traffic policing drops packets over the limit, which reduces video quality but avoids additional latency. What’s more important to your client: timeliness or quality? You will learn more about traffic shaping and policing in Chapter 14.
Depending on the importance of the streaming application, you may wish to reserve this bandwidth with Resource Reservation Protocol (RSVP). RSVP is a Transport Layer protocol used to reserve network resources for specific applications. The reservation is initiated by the host receiving the data and must be renewed periodically. RSVP is used in combination with differentiated service (DiffServ; see Chapter 5). At the very least, DiffServ quality of service (QoS) will be required for WAN streaming.
Talking Bandwidth Capacity
Based on the estimates that only 70 percent of the rated capacity is considered available, and only 30 percent of that available capacity is designated for streaming, you’re looking at 21 percent of a network’s rated capacity being available for streaming (pictured).
Whenever you’re discussing bandwidth capacity with a network administrator, be very clear about what you mean by capacity:
• Is the network administrator telling you how much bandwidth the whole network is rated for? You can use only 21 percent of that for streaming.
• Is she telling you the average bandwidth availability? You can use 30 percent of that for streaming.
• Is she telling you the availability during peak usage? This will help determine QoS and traffic shaping requirements.
Streaming and Quality of Service
The bandwidth required for streaming video makes QoS a virtual requirement for streaming across a WAN. If you’re adding a streaming application to an existing network, you need to find out
• Whether QoS has been implemented across the entire WAN. In order to provide any benefit, QoS must be implemented on every segment of the network across which the stream will travel.
• What differentiated service classes have already been defined for network-based QoS (NQoS). Every organization prioritizes data differently. You may think that AV data should always be assigned a high service class because it requires so much bandwidth and so little latency. However, a financial institution may value the timely delivery of stock quotes above streaming video. Where will the streaming application fit within the enterprise’s overall data priorities?
• Whether RSVP can be implemented to reserve bandwidth for the streaming application. RSVP must be implemented on every network segment in order to function—a very labor-intensive process. Start by finding out if RSVP is currently implemented on the network; whether or not you should use it is a separate question. Does the importance of the streaming application really merit reserving 21 percent of the network for its traffic at all times?
• What policy-based QoS rules are already in place, if any. Assigning QoS policies to particular user groups can be very helpful for networked AV applications. You may wish to place streaming traffic to and from the content ingestion points in a higher class of service than on the rest of the network, for instance. If remote users are accessing the system via IPsec, you may have to use policy-based QoS. The ports, protocols, and applications of IPsec traffic are hidden from the router.
• Whether traffic shaping can be used to manage bandwidth. Again, traffic shaping policies will have to be implemented on every router on the network. However, if your customer doesn’t mind the additional latency, traffic shaping can be a very effective way to prevent the network from being overwhelmed by streaming traffic. Of course, if traffic policing has been implemented, you need to know this too. Find out where bandwidth thresholds have or will be set for streaming traffic, and set expectations for dropped or delayed packets accordingly.
Latency
If your application will include live streaming, the amount of latency inherent to the network can be nearly as big a concern as bandwidth availability. What latency is present, and what causes it?
Find out if your customer has an internal speed test server. If they do, work with the network manager to determine the inherent latency of the network. You can use a WAN speed test to verify network upload and download bit rates, as well as latency inherent between IP addresses. If your customer does not have an internal speed test server, free WAN speed test tools are available from many sites, including www.speedtest.net, www.speakeasy.net, and www.dslreports.com.
Varying degrees of latency are acceptable, depending on your customer’s needs. Here are some examples:
• Videoconferencing: 200 milliseconds
• High-fidelity audio: 50 microseconds
• Streaming desktop video: 1 second
Eliminating latency entirely from streaming applications is impossible. The trick is to document in your SLA how much latency your customer can tolerate for the application. Keep in mind, if your customer has a transportation security requirement, more latency will be introduced into the network. Encryption and decryption take time.
Network Policies and Restrictions
Remember, what the network is capable of doing and what the network is permitted to do are two separate issues. You must determine not only whether bandwidth optimization and latency mitigation strategies, such as differentiated service, policy-based QoS, multicasting, and UDP transport, are possible, but whether or not they are permitted. Many of these strategies are extremely labor intensive to implement, and some, such as multicast and UDP transport, may represent significant security risks.
You should also always investigate what software and hardware the enterprise already has. You can bet that staying within an organization’s existing device families will ease the process of getting approval to connect devices to the network. For example, the software that users currently have (or are allowed to have) will determine what codecs are available on the end-user playback device, which in turn determines the encoder your system should use.
Cheat Sheet: Streaming Network Analysis Questions
Use the list of questions that follows to gather information from your customer’s IT department about supporting streaming media applications. Consider how network policies with respect to each item could affect the streaming system’s design, cost, and network impact. Some of the technical issues raised in the questions are covered in greater depth later in this chapter.
Topology
• Will content be streamed within a LAN, within a WAN, or over the open Internet?
• If content will be streamed over a WAN, what is the network topology?
• What is the addressing scheme (DNS, DHCP, static)?
Bandwidth Availability
• What is the network’s total available end-to-end upload bandwidth?
• What is the network’s total available end-to-end download bandwidth?
• What is the network’s typical available worst-case upload bandwidth?
• What is the network’s typical available worst-case download bandwidth?
• If content will be streamed to the Internet, what upload and download bandwidth is provided by the ISP?
• If traffic will be streamed over a WAN, has QoS been implemented? If so, what queue level will AV traffic occupy?
• If traffic will be streamed over a WAN, has traffic shaping been implemented?
• If traffic will be streamed within a LAN, has Independent Group Management Protocol been implemented? If so, what version?
• Is a hybrid solution required to preserve bandwidth? If so, is protocol-independent multicast available to transport?
• Do you need to relay multicast streams across domains?
Latency
• How much latency is inherent to the network?
• Will there be transport-level security requirements?
Network Policies
• Are multicast and UDP transport permitted?
• Are there restrictions on protocols allowed on the network?
• Are there restrictions on what software may be installed on the hosts?
• How is access control currently managed on the network?
• What video player software is currently installed on the hosts? What codecs does it include?
Digital Content Bandwidth
Now let’s get down to brass tacks. You’ve done your needs and network analyses. It’s time to design the streaming system. Let’s start our design by addressing the most important factor—bandwidth.
Remember the example of a “connect-the-dots” puzzle from Chapter 3? When digital media files are encoded for streaming across a network, the system is essentially creating digital dots to represent the analog signal. The dots are required to play back the signal with sharp detail and high resolution. That said, too many dots and the signal is larger than necessary, making it costly to store and transport. Too few dots and the playback quality suffers.
As we start in on the subject of AV streaming, go back to Chapter 3 and review some of the basic characteristics of a digital AV stream, including sampling rate and bit depth. These technology characteristics and how they’re achieved will determine how to design and implement a streaming system that meets your customer’s requirements. Streaming requires bandwidth, and good streaming requires the right amount of bandwidth.
Digital Audio Bandwidth
An unencoded audio signal’s bandwidth requirements are in direct relationship to the signal’s sampling rate (measured in Hz) and bit depth (measured in bits). The formula for the required data throughput of a single unencoded audio stream is
Sampling Rate × Bit Depth × Number of Channels = Bit Rate (bps)
This unencoded data can be streamed over a LAN, saved to a file (for archiving or editing), or compressed with an encoder to reduce the file size even more. It should be noted that compressing a smaller file takes less processing than compressing a larger file, easing the CPU load for other purposes. Note also that a 7.1 audio file will be significantly larger than a mono voice file. As always, the question is, “How good is good enough?” Is reducing bandwidth worth the quality trade-offs?
Let’s try it out. Use the digital audio bandwidth formula to answer the following questions. Refer to the common audio sampling rates given here to answer the audio bandwidth questions that follow.
• Telephone: 8 kHz
• Audio CD: 44.1 kHz
• DVD audio: 48 kHz
• Blu-ray: 96 or 192 kHz
• Super Audio CD (SACD): 2.8 MHz
Questions
1. Your customer wishes to stream CD-quality music at 16 bits—in stereo—to his lobby area. How much bandwidth will he require?
2. You need to stream ten channels of 96 kHz audio. You have 25 Mbps of bandwidth available. What is the highest bit depth you can use?
3. You currently have the bandwidth capacity to stream 30 channels of 48 kHz, 24-bit audio. How many channels could you stream if you upgraded to 96 kHz, 24-bit audio?
Answers
1. 1.411 Mbps
2. 26-bit
3. 15 channels
Digital Video Bandwidth
Audio and video streams are both digital representations of analog data, sound, and light. So why does video require so much more bandwidth than audio?
It’s because digitally representing video requires much more data. For video, each pixel has a bit depth—a number of possible states. The moving image has a sampling rate, represented as the number of frames per second. That total must be multiplied by the total number of pixels in the image to find the uncompressed bandwidth.
The formula for black-and-white, uncompressed digital video signal bandwidth is
Horizontal Pixels × Vertical Pixels × Bit Depth × Frames per Second = Bit Rate (bps)
The number of pixels is determined by the video format. For example, each frame of 720p digital video is 1280 pixels wide by 720 pixels high. That’s 921,600 total pixels in each frame. Tables 10-1, 10-2, and 10-3 list some common video pixel resolutions for your reference.
Table 10-1 High-Definition Format
Table 10-2 Common Intermediate Format (PAL)
Table 10-3 Standard Intermediate Format (NTSC)
Of course, when was the last time you streamed black-and-white video? Color video is not a single signal. It’s three: red, blue, and green. That means a color video stream requires even more data. The amount of bandwidth you need to stream color video depends on how that video is sampled. Here’s how to calculate the bandwidth (bps) for color video, depending on the sampling method used.
4:4:4 Sampling
4:4:4 sampling uses all three signals in equal proportion. A 4:4:4 color video signal requires three times the bandwidth of its black-and-white counterpart.
You may have seen the bit rate of digital video expressed as 24 or 32 bits. This is just a bit depth of 8 multiplied by the number of channels. The formula for three-channel, uncompressed digital video signal bandwidth is
Horizontal Pixels × Vertical Pixels × Bit Depth × Frames per Second × 3 = Bit Rate (bps)
NOTE Computers have a transparency layer, also called an alpha channel. It’s the same size as the red, green, or blue signals. When you set your computer resolution, you see choices for 24- or 32-bit color. 24-bit means 8 bits for red, 8 for green, and 8 for blue. Add the 8 bits for the alpha channel, and you get 32-bit color.
4:2:2 Sampling
Because human eyes can’t detect color information as well as black-and-white detail, you can get away with limiting the color information included in the digital sample. 4:2:2 sampling includes all the luminance information, but only half the red and blue channels. The drop in quality isn’t noticeable; 4:2:2 sampling is used for broadcast TV. Keep in mind, you can’t use this digital video compression method for computer graphics, because computers don’t have component output.
The formula for 4:2:2 digital video signal bandwidth is
Luminance + Red + Blue = Bit Rate (bps)
where
• Luminance = Frames per Second × Bit Depth × Horizontal Pixels × Vertical Pixels
• Red = Frames per Second × Bit Depth × 1/2 Horizontal Pixels × Vertical Pixels
• Blue = Frames per Second × Bit Depth × 1/2 Horizontal Pixels × Vertical Pixels
4:1:1 Sampling
Digital video and some MPEG video formats (see the upcoming section, “Content Compression and Encoding”) use 4:1:1 sampling, limiting the color information even further. The full luminance signal is still present, but only 1/4 of the color information is sampled.
The formula for 4:1:1 digital video signal bandwidth is
Luminance + Red + Blue = Bit Rate (bps)
where
• Luminance = Frames per Second × Bit Depth × Horizontal Pixels × Vertical Pixels
• Red = Frames per Second × Bit Depth × 1/4 Horizontal Pixels × Vertical Pixels
• Blue = Frames per Second × Bit Depth × 1/4 Horizontal Pixels × Vertical Pixels
NOTE 4:2:0 sampling is mathematically the same as 4:1:1 sampling in terms of required bandwidth.
Bandwidth: Total Program Size
When determining the total required bandwidth of an AV stream, it’s important to remember that reducing or increasing the video or audio information changes the total data transmission rate. Yes, video requires a lot of bandwidth, but sometimes people forget the audio. Audio can require a lot more bandwidth than you might think, especially for surround-sound applications. All those channels add up. Remember also to account for overhead—namely, the addressing and control information that must accompany AV packets.
When it comes to AV program bandwidth,
Video Bit Rate + Audio Bit Rate + Overhead = Total Required Bandwidth (bps)
Image Quality vs. Available Bandwidth
Working with the customer and IT, you must determine whether the amount of bandwidth allocated for streaming will be driven by current network availability or the end user’s quality expectations. It may be anathema to AV professionals, who pride themselves on high-quality experiences, but the customer may be willing to sacrifice quality in favor of network efficiency. In that case, it’s your job to ensure that the customer knows what she’s giving up and that the service-level agreement (see Chapter 14) reflects a balance between efficiency and quality that the customer can accept.
In general, streaming bandwidth will be driven by network availability when the customer is extremely cost-conscious and/or the streaming service is being added to an existing network that’s difficult to change. Streaming bandwidth will be driven by the user’s need for quality when high image resolution and frame rate are required to perform the tasks for which the streaming service will be used, or the tasks for which the streaming service will be used are mission critical. The need for quality also seems to get a boost when your customer audience is from the C-level suite.
What can you do when you discover that streaming requirements exceed available network resources? If quality takes precedence, either add bandwidth, optimize existing bandwidth, or assign streaming a high QoS class of service and/or reserve bandwidth using RSVP. If availability takes precedence, you may need to reduce image resolution, frame rate, or bit rate; cut the number of channels by implementing multicast streaming or cache servers; or implement intelligent streaming.
Content Compression and Encoding
A single stream of uncompressed 4:1:1 video with audio and overhead can easily exceed 21 percent of the rated capacity of anything short of a Gigabit LAN or optical fiber network. AV data must therefore be compressed and/or encoded before it can travel across an enterprise network.
Compression is the process of reducing the data size of video and audio information before sending it over a network. The information is then decompressed for playback when it reaches its destination. Compression may be “lossless” or “lossy,” which is a more important distinction for AV signals than it is for, say, email messages.
With lossless compression, the AV data is exactly the same after it’s been compressed and decompressed as it was originally. All the data remains intact. (In IT, lossless compression is important for maintaining the integrity of data such as financial records, text, and other non-AV information that would otherwise lose its meaning if any of it were altered.)
In AV, lossless compression schemes are important when the application demands perfect fidelity of AV data throughout its transmission, for example, in video security or command-and-control systems. Apple Lossless and Dolby TrueHD are examples of lossless audio compression; JPEG 2000 and H.264 offer lossless video compression.
Lossy compression techniques compress and discard “unneeded” data while still returning an acceptable-quality stream after decoding. The compression program examines a video or audio segment for detail that is less important or less noticeable. It then drops the data describing that detail from the stream. When the stream is re-created during decoding and playback, people are unlikely to notice the dropped information. For example, a video compression scheme might focus its work more on moving images in a stream than on static background images.
Lossy compression is common for AV applications such as streaming media and IP telephony. Advanced Audio Coding (AAC) and MP3 are examples of lossy audio compression; MPEG-2 and VC-1 offer lossy video compression. Some lossy schemes also implement lossless techniques to further decrease file sizes.
Codecs
The software or hardware that actually performs the lossless of lossy compression—as well as the decompression—is known as a codec, short for “enCOder/DECoder.” Codecs come in an almost bewildering variety: one-way and two-way, hardware- and software-based, compressed, and uncompressed, specialized videoconferencing, and so on. Deciding what type of codec to use for a streaming application requires considering several factors, including the following:
• IT policies—the playback software that users currently have (or are allowed to have) determines the codecs their playback devices use, which in turn determines the codec you need to encode streams
• Licensing fees associated with the codec
• The resolution and frame rate of the source material
• The desired resolution and frame rate of the stream
• The bandwidth required to achieve your desired streaming quality
When it comes to matching the bandwidth you need to a codec’s capabilities, you may not be able to find technical specifications to help you out. Some network testing may be in order.
Digital Audio Compression: MP3
MP3 is one of the more common audio encoding formats. It was defined as part of a group of audio and video coding standards designed by the Moving Picture Experts Group (MPEG). MP3 stands for MPEG-1 or MPEG-2 audio layer three. MP3 uses a lossy compression algorithm that reduces or discards the auditory details that most people can’t hear, drastically reducing overall file sizes.
When capturing and encoding MP3 audio, you can choose your bit depth and sampling rate. The MPEG-1 format includes bit rates ranging from 32 to 320 kbps, with available sampling rates of 32 kHz, 44.1 kHz, and 48 kHz. MPEG-2 ranges from 8 to 160 kbps, with available sampling rates of 16 kHz, 22.05 kHz, and 24 kHz.
MP3 encoding may be accomplished using constant bit rate (CBR) or variable bit rate (VBR) methods. You can predefine CBR encoding to match your bandwidth, especially where bandwidth is limited. VBR encoding uses a lower bit rate to encode portions of the audio that have less detail, such as silence, and a higher bit rate to encode more complex passages. CBR encoding results in more predictable file sizes, which helps in planning for bandwidth requirements. However, VBR can result in better perceived quality.
Digital AV Compression
Compressing a data stream that contains both audio and video is considerably more complex. Because video has more information than audio, the resulting files and streams are much larger. There are many AV compression formats, but they generally fall into two categories.
The first is intraframe compression, which compresses and sends each frame individually. Because it sends each individual frame, intraframe compression is preferable for editing video. Motion JPEG uses intra-frame compression. Not surprisingly, the resulting data files are very large.
Interframe compression, on the other hand, detects how much information has changed between frames and only sends a new frame if there are significant differences. Interframe compression requires less bandwidth to stream and results in smaller files. MPEG video algorithms use interframe compression; so do most videoconferencing codecs.
NOTE You may have heard it’s a bad idea to wear patterned clothes during a videoconference. It’s true! An interframe codec, common in videoconferencing systems, sends a new frame every time it sees the pattern shift, resulting in a far higher bandwidth stream.
When it comes to encoding and decoding a digital signal, video frames are formed into logical groups, known as groups of pictures (GoP), shown in Figure 10-1. A GoP is a set of video frames, which, when played in succession, and in line with other GoPs, creates the video stream. In a GoP there are three picture types:
Figure 10-1 A group of pictures (GoP).
• I-frames (intraframes), which are complete reference pictures. Every GoP starts with an I-frame.
• P-frames (predictive frames), which contain information about how the P-frame is different from the preceding I- or P-frame.
• B-frames (bidirectional frames), which contain information about how the B-frame is different from the preceding and following I- or P-frames.
Encoding software chooses which frames in a GoP to actually transmit in a video stream. Interframe encoding jumps from I-frame to I-frame, compressing several frames at a time.
Choosing a Codec
Because the file extension doesn’t reveal a stream’s codec, how do you determine which codec a particular stream is using, or which codecs you want the equipment you purchase to support?
Start by doing your homework. Fourcc.org is an excellent all-in-one resource for information on video codecs. It includes information on common codecs, applications for discovering codec versions, and links to download codecs.
When it comes to choosing a codec, your decision criteria fall into two major buckets: application and network considerations. Start by evaluating application requirements. Identify all the codecs your streaming hardware supports and then match the codec to the media you’ll be streaming—audio, video, or both. If video, the stream will be in either RGB or YUV color format; select a codec compatible with those formats. If the customer requires lossless compression, eliminate any codecs that are lossy (and vice versa). Plus, if the customer wants to edit media before streaming, select a codec that allows that capability (i.e., one that uses intraframe compression).
After considering codecs in the context of application requirements, you’ll want to evaluate them in light of the customer’s network environment. For starters, eliminate any codecs that are not compatible with the customer’s operating system. A codec should also be compatible with whatever player software the customer’s IT department allows users to install. Ultimately, the codec you choose needs to support your transport method and streaming protocol, and it should fit under whatever bandwidth restrictions you identify in cooperation with the customer and the IT staff.
High-Quality Streaming Video
The Moving Picture Experts Group defines the compression formats commonly used for streaming high-quality video: MPEG-1, MPEG-2, and MPEG-4. There used to be an MPEG-3 format, but it’s no longer used and shouldn’t be confused with the MP3 audio compression format.
All three major MPEG standards stream over User Datagram Protocol (UDP) (see Chapter 9 for a review). Today, MPEG-2 and MPEG-4 are the most prominent for networked AV systems, though MPEG-1 is also ubiquitous—MP3 audio is part of the MPEG-1 standard. For our purposes, we’ll explore further the flavors of MPEG you’re most likely to use for video streaming.
MPEG-2
MPEG-2, also known as H.222/H.262, is the most common digital AV compression format. It’s an international standard, defined in ISO/IEC 3818. MPEG-2 is used to encode AV data for everything from DVD players and digital cable to satellite TV and more. Notably, MPEG-2 allows text and other data, such as program guides for TV viewers, to be added to the video stream.
There are various ways to achieve different quality levels and file sizes using MPEG-2. In general, however, MPEG-2 streams are too large to travel on the public Internet. MPEG-2 streams have a minimum total bit rate of 300 kbps. Depending on the frame rate and aspect ratio of the video, as well as the bit rate of the accompanying audio, the total bit rate of an MPEG-2 stream can exceed 10 Mbps.
MPEG-4
MPEG-4 is designed to be a flexible, scalable compression format. It is defined in the standard ISO/IEC 14496. Unlike MPEG-2, MPEG-4 compresses audio, video, and other data as separate streams. For applications where audio detail is very important, such as videoconferencing, this is a major advantage. MPEG-4 is capable of lower data rates and smaller file sizes than MPEG-2, while also supporting very high-quality transmission. It’s commonly used for streaming video, especially over the Internet.
Within the MPEG-4 specification are levels and profiles. These subgroups let manufacturers concentrate on applications without getting bogged down in every aspect of the format. Profiles are quality groupings within a compression scheme. Levels are the specific image sizes and frame rates of a profile. This breakdown allows manufacturers to use only the part of the MPEG-4 standard they need while still being in compliance. Any two devices implementing the same MPEG-4 profiles and levels should be able to interoperate.
MPEG-4 Part 10 is the most commonly implemented part of the MPEG-4 standard for recording, streaming, or compressing high-definition audio and video. It is also known as H.264 Advanced Video Coding (AVC). AVC can transport the same quality (resolution, frame rate, bit depth, etc.) as MPEG-2 at far lower bit rates—typically half as low as MPEG-2. AVC profiles include but are not limited to
• Baseline Profile (BP), used for videoconferencing and mobile applications
• Main Profile (MP), used for standard-definition digital television
• Extended Profile (XP), used for streaming video with high compression capability
• High Profile (HiP), used for high-definition broadcast and recording, such as digital television and Blu-ray recording
AVC also includes intraframe compression profiles for files that might need to be edited—High 10 Intra Profile (Hi10P), High 4:2:2 Intra Profile (Hi422P), and High 4:4:4 Intra Profile (Hi444P).
Achieving High-Quality Compressed Images
Regardless of the method you choose to encode and compress AV content for streaming, there are ways you can optimize the content for best possible results:
• Start with a frame size that matches your output size If you capture video in the same size that you know users will be viewing it, the systems won’t have to spend CPU cycles scaling the video. Your streaming devices can concentrate on encoding and compressing the images. If in your needs analysis you identified a heterogeneous set of endpoints, match the captured frame size to the most common use case.
• Reduce image noise Encoders don’t know the difference between noise and detail. Composite video, for example, can include artifacts that look like detail information to a streaming encoder. Encoding S-video or component video will usually lead to improved image quality.
Good lighting techniques and better video cameras will reduce noise. Too much video noise can trick an encoder into detecting motion where there is none. For example, the background of a videoconference may be static (e.g., a wall), but if there is enough video noise, the encoder will think something is moving in the background and waste compression time on the wall instead of the presenter’s face.
• Select the proper audio quality If you’re streaming voice-quality audio, but you’re set up for 44.1 MHz stereo, you’re wasting bits that could be used for video or better audio compression.
• Select the proper codec As we’ve discussed, various codecs support differing streaming quality and data rates. Experiment with different codecs, settings, and applications to figure out which will deliver the experience the customer expects. For example, MPEG-4 is not the best choice for editing in most cases.
Transcoding and Intelligent Streaming
It’s possible—and sometimes desirable—to convert a streaming file from one type to another, even though doing so may introduce artifacts, distortions, and more. This process, called transcoding, usually only requires software, but it may also require a hardware device. Maintaining streaming in multiple formats allows you to support different viewers.
To avoid transcoding, you may wish to compress and encode raw media into multiple formats before ingesting content into the network. In addition, if, for instance, you’re using the WMV wrapper for a media file, you may also wish to create files in multiple resolutions. Again, keeping streams at many resolutions makes for a better streaming experience for end users as they can view the stream at a native resolution. In this case, streaming servers and WMV players with the intelligent streaming feature can optimize the transmission resolution. The server sends the best stream that the player is capable of receiving. The process is transparent to the user but must be defined by the file creator at the point where the data stream enters the network.
Designing the Streaming System
Most live video with low latency requirements is delivered via UDP transport. That’s because if a stream is time-sensitive, it’s generally preferable to drop a few packets than to wait for the source to confirm delivery and have to resend dropped packets.
Multicast transmissions are always delivered via UDP. UDP packets include very little data, however, because they’re designed to deliver data as efficiently as possible. For more on UDP, review Chapter 9.
Real-Time Transport Protocol (RTP) is a Transport Layer protocol commonly used with UDP to provide a better AV streaming experience. (RTP also works with TCP, but the latter is more concerned with reliability than speed of transmission.) In addition to a data payload, RTP packets include other information, such as sequence and timing. RTP helps prevent jitter and detects when video packets arrive out of sequence. It also supports one-to-many (multicast) video delivery.
RTP is often deployed in conjunction with the Real-Time Transport Control Protocol (RTCP), a Session Layer protocol for monitoring quality of service for AV streams. RTCP periodically reports on packet loss, latency, and other delivery statistics so that a streaming application can improve its performance, perhaps by lowering the bit rate of the stream or using a different codec. RTCP does not carry any multimedia data or provide any encryption or authorization methods. In most cases, RTP data is sent over an even-numbered UDP port, while RTCP is sent over the next higher odd-numbered port.
Other Streaming Protocols
In addition to transport protocols, you should also consider streaming protocols when setting up a streaming system. Streaming-specific protocols serve different functions and are based largely on the types of endpoints customers use to view content.
Real-Time Streaming Protocol (RTSP) comes in handy if all endpoints are desktop computer clients. This is because RTSP supports RTCP, whereas MPEG transport stream, for example, does not. RTSP is a control protocol that communicates with a streaming server to allow users to play, pause, or otherwise control a stream. For its part, RTCP sends back user data, allowing the streaming device to dynamically adjust the stream to improve performance.
If any of the endpoints are set-top boxes or similar devices (maybe a streaming box behind a screen in a restaurant), you’ll probably use MPEG transport stream (MPEG-TS). The frequency of some displays used with set-top-style boxes can sometimes cause a perceived lag between audio and video. MPEG delivery prevents this from happening by combining audio and video into a single stream. MPEG-TS is defined as part of MPEG-2, but it is the transport stream used to deliver MPEG-4 audio and video as well.
Session Description Protocol (SDP) is a standardized method of describing media streamed over the Internet. The information carried by SDP generally includes the session name, purpose, timing, information about the media being transported (though not the media itself), and contact information for session attendees. In short, SDP is used to kick off a streaming session—ensuring all invited devices are in contact and understand what’s coming next. The information contained in SDP can also be used by other protocols, such as RTP and RTSP, to initiate and maintain a streaming session.
Unicast and Multicast
As someone who’s probably watched a little TV in your time, you know what broadcasting means. To broadcast is to transmit data to anyone who can receive it at the same time. This doesn’t happen much in networking. When it comes to streaming, we talk in terms of unicast or multicast.
Unicast streaming (Figure 10-2) establishes one-to-one connections between the streaming server that sends the AV data and the client devices that receive it. Each client has a direct relationship with the server. The client sends a request to the server and the server sends the client a stream in response.
Figure 10-2 Unicast streaming.
Because the server is sending out a separate stream to each client, each additional client consumes more of the available bandwidth. Streaming media to three clients at 100 Kbps actually uses 300 Kbps of bandwidth. Unicast streams may use either UDP or TCP transport, although with TCP transport, you can assume there will always be some measure of buffering, or client devices waiting for parts of the stream to arrive before playing it. An encoder can typically produce only five or six unicast streams, depending on the streaming device’s available resources. If you need more than a handful of unicast streams, you’ll need a streaming or caching server to replicate and manage them.
That said, unicast is easier to implement than multicast, and it’s cheaper for small applications. Consider using unicast for point-to-point streaming and even point-to-point plus recording. If you’re unicasting to thousands of users, however, you’ll have to invest in streaming devices that sit at the network’s edge for handling the extra streams, which can be expensive.
Multicast streaming is a one-to-many transmission model. One server sends out a single stream that multiple clients can access. Multicast streams require UDP transport. They can only be sent over LANs or private networks, not over the open Internet. Class D IP addresses are set aside for multicast transmissions (see Chapter 7 for a review of addressing). The steps involved in multicast streaming look like this:
1. A server sends the stream to a designated Class D IP address, called the host address.
2. Clients subscribe to the host address.
3. Routers send the stream to all clients subscribing to the host address.
Subscribing to an active multicast host address is like tuning into a radio station: all the users receive the same transmission and none of them can control the playback. There is no direct connection between the server and the clients. Because the server is sending only one stream, the transmission should theoretically take up the same amount of bandwidth no matter how many clients subscribe. Sounds efficient, right?
However, not all networks are capable of passing multicast streams. In order for multicast to work, every router in the network must be configured to understand multicast protocols and Class D addressing. If the router doesn’t recognize the Class D IP address as a multicast host address, the clients have no way to access the stream. As a result, multicasting can be very labor intensive to implement. Only small portions of the Internet are multicast enabled, so it’s usually not possible to multicast over the open Internet. If you want the customer’s IT department to allow multicast, you’d better make a good case.
How do you choose whether to stream using unicast or multicast? The decision should be based on your streaming needs and network capabilities.
In many cases, you won’t have the option to use multicast streaming, particularly if the network you’re working with isn’t multicast enabled. Managed switches must be capable of multicasting. Internet Group Management Protocol (IGMP) should be implemented on the router, and if you want to send multicast streams over a wide area network, you have to set up a PIM (protocol-independent multicast) relay, which forwards only the unicast streams that are in use. (We cover IGMP, PIM, and more in the next section.) All the routers in the network have to support this functionality.
If the network isn’t ready for multicasting, use unicast streaming. Moreover, as long as the projected number of clients and the bit rate of the streams won’t exceed the network’s bandwidth capacity, stick with unicast, because it’s much easier to implement. And if you’re implementing video on demand, you want to use unicast so users can control playback.
On the other hand, when you need to stream to a large number of client devices on an enterprise network, multicast can help limit your bandwidth usage. For example, streaming a live lecture to all the student desktops on a campus might benefit from multicasting. Multicasting is typically used for IPTV systems, with each channel sent to multiple hosts.
Compromise between unicast and multicast is possible. For example, using a caching or reflecting server, you can convert a multicast stream to a unicast stream in order to pass it over a network segment that cannot accept multicast transmissions. This hybrid approach is the most common approach for WAN implementations.
Implementing Multicast
To review, if you need to send a large number of streams or you need to stream to many users over a LAN, you’ll probably use multicast. It is a great preserver of bandwidth, but it takes an enormous amount of configuration to implement. For starters, every router on the network must be configured to understand what are called group management protocol requests. These requests allow a host to inform its neighboring routers that it wants to start or stop receiving multicast transmissions. Without group management protocols, which differ depending on the Internet Protocol version a network uses, multicast traffic is broadcast to every client device on a network segment, impeding other network traffic and overtaxing devices.
Internet Group Management Protocol (IGMP) is the IPv4 group management protocol. It has gone through a few revisions. IGMPv1 allowed individual clients to subscribe to a multicast channel. IGMPv2 and IGMPv3 added the ability to unsubscribe from a multicast channel.
Multicast Listener Discovery (MLD) is the IPv6 group management protocol. IPv6 natively supports multicasting, which means any IPv6 router will support MLD. MLDv1 performs roughly the same functions as IGMPv2, and MLDv2 supports roughly the same functions as IGMPv3. IGMPv3 and MLDv2 also support source-specific multicast (SSM). SSM allows clients to specify the sources from which they will accept multicast content. This has the dual benefit of reducing demands on the network while improving network security. Any device that has the host address can try to send traffic to the multicast group, but only content from a specified source will be forwarded to the group. This is in contrast to any-source multicast (ASM), which sends all multicast traffic sent to the host address to all subscribed clients.
Protocol-Independent Multicast
With the amount of configuration required to implement multicast streaming, many IT managers are hesitant to implement it beyond a single LAN. Multicast routing beyond the LAN is made possible by protocol-independent multicast (PIM). PIM can also support SSM.
PIM allows multicast routing over LANs, WANs, or even, theoretically, the open Internet. Rather than routing information on their own, PIM protocols use the routing information supplied by whatever routing protocol the network is already using, hence protocol-independent.
PIM is generally divided into two categories: dense mode and sparse mode. Dense mode sends multicast traffic to every router on the network and then prunes any routers that aren’t actually using the stream. By default, dense mode refloods the network every three minutes. PIM-DM is easier to implement than sparse mode but scales poorly. It’s only suitable for applications where the majority of users will join each multicast group. Sparse mode sends multicast traffic only to those routers that explicitly request it. This is the fastest and most scalable multicast implementation for wide area networks. Let’s examine it further.
PIM Sparse Mode
PIM sparse mode (PIM-SM) sends multicast feeds only to routers that specifically request the feed, using a PIM join message. The multicast source sends its stream to an adjacent router. That router must be configured to send the multicast traffic to a specialized multicast router called a rendezvous point (RP). There can be only one RP per multicast group, although there can be several multicast groups per RP.
Here’s how it works (see Figure 10-3):
Figure 10-3 Using PIM sparse mode.
1. The destination host sends a join message toward the multicast source or toward the rendezvous point.
2. The join message is forwarded until it reaches a router receiving a copy of the multicast stream—all the way back to the source if necessary.
3. The router sends a copy of the stream back to the host.
4. When the host is ready to leave the multicast stream, it sends a prune message to its adjacent router.
5. The router receiving the prune message checks to see whether it still needs to send the multicast stream to any other hosts. If it doesn’t, it sends its own prune message to the next router.
Packets are only sent to the network segments that need them. If only certain users will access the multicast stream, or if many multicast streams will be broadcast at once, sparse mode is the most efficient use of network resources. IPTV, for example, is typically implemented using PIM-SM.
However, PIM-SM also requires the most configuration. All routers on the network must be aware of the multicast rendezvous points. Routers should also be configured with access lists so that only designated users will have access to the multicast group. RPs themselves must be configured with a traffic threshold. Once the threshold is exceeded, join messages will bypass the RP and go directly to the source. This threshold is usually set to zero automatically, which means the RP will direct all join requests to the source by default. It can also be lifted entirely. The decision depends on how much multicast traffic each network segment can bear.
Multicast Addressing
You can’t use just any IP address as a multicast host address. The Internet Assigned Numbers Authority (IANA), the same organization responsible for assigning port numbers, has divided the Class D IP address range into a series of address blocks allocated to different types of multicast messaging. See Table 10-4.
Table 10-4 IANA Multicast Address Assignments
Each block in the Class D address assignment table serves a different function.
• The local network control block, or link-local block, is used for network protocols that remain within the same subnet. Control or announcement messages that must be sent to all the routers in a subnet are addressed to destinations in this range.
• The internetwork control block is used to send multicast control messages beyond the local network segment. For example, in PIM sparse mode, rendezvous point information may be communicated across broadcast domains using an address in this range.
• Ad hoc addresses are assigned by IANA to multicast control protocols that don’t fit clearly into the first two blocks. However, much of the ad hoc block was assigned prior to the existence of usage guidelines, so many addresses in this range are simply reserved for commercial uses.
• The SAP/SDP block is reserved for applications that send session announcements.
• The source-specific multicast block provides multicast host addresses for SSM applications.
• The GLOP block provides multicast host addresses for commercial content providers.
• The unassigned address ranges remain so for experimental or future uses.
• The administratively scoped block is reserved for private multicast domains. These addresses will never be assigned by IANA to any specific multicast technology or content provider. You’re free to use these as multicast host addresses within the enterprise network, but they can’t be used to send multicast content over the Internet.
Any multicast host address used by a private enterprise (other than a commercial content provider, such as an ISP or television network) comes from either the SSM or the administratively scoped block.
NOTE GLOP is not an acronym. It turns out the original authors of this RFC needed to refer to this mechanism by something other than “that address allocation method where you put your Autonomous System in the middle two octets.” Lacking anything better to call it, one of the authors simply began to refer to this as “GLOP” addressing, and the name stuck.
Video on Demand
If the customer plans to record content and make it available on demand, system considerations change. With a video-on-demand (VOD) system, each user receives his own on-demand stream, so multicasting is not an option.
Configuring the network to accept VOD traffic is practically a nonissue. VOD is HTTP-based streaming over TCP port 80, so it’s usually not true streaming. Because VOD content can be allowed to buffer, network resource usage on the destination side is not much of a factor. But that doesn’t mean VOD is a no-brainer.
As part of the needs assessment for a VOD application, you should establish how users plan to search for content. As content is saved to the server, customers will need some way to “tag” it with defining characteristics so that they can find it later. The content server’s management interface may have some preconfigured data fields, such as title, subject, date, and so on. Depending on the complexity of your customer’s VOD needs, these preconfigured fields may be enough. If they make only a handful of videos available on demand, searching by title may be sufficient. As the volume of on-demand content increases, the need for more sophisticated search capabilities arises.
In many cases, the AV professional will be responsible for defining the metadata tags for on-demand content. These tags could include information about
• Title
• Subject or topic
• Date
• Department
• People involved
• Language
• Accessibility compliance
• Playlist
• Access community
The possibilities for metadata tagging are endless. Your goal is to provide useful metadata fields that aren’t so onerous the end user fails to actually use them. Many of these fields, such as date, can be configured to populate automatically. Some content management software even includes speech analytics that can automatically populate subject and topic fields.
VOD content storage—particularly reliable content storage—can get expensive. Furthermore, traffic to and from the content storage will likely be quite high. Think carefully about content storage and its location on the network.
The amount of storage you need will be determined by three factors:
• File sizes
• How long files will be retained
• Redundancy/backup requirements
The location on the network should be based on use case, network topology, and security requirements. Because traffic to the content server will be high, the server should be located wherever it will see the heaviest use. If consumers of on-demand traffic are localized, the content server should be on their LAN. If consumers are dispersed, the content server will have to sit somewhere on the WAN. You may wish to lease server space from an ISP or contract with a cloud service to host content. Cloud services provide excellent remote access capabilities, but customers may be hesitant to entrust their content to a third party. If your customer is sensitive to security risks, you may simply need to locate the content server on-site and pay to upgrade the bandwidth to that location.
Technologies for Delivery of Streaming Media
After you’ve done your analysis and detailed your design, including all the formats and protocols that your streaming media system will require, it’s time to build. In this section, you’ll learn about the technologies used to deliver an AV stream, including the various hardware and software components, and network configuration strategies used to encode, distribute, access, and store streaming media.
Encoders
We explored codecs earlier in this chapter, so we won’t spend much additional time on this technology decision. In a nutshell, your customer can choose to encode all their streaming content in software or hardware.
Encoding using PC-based software has several advantages and disadvantages. Software-based encoding is typically less expensive than hardware-based encoding, especially if the user is able to leverage existing computer resources. Still, if the user chooses to encode content on an existing system, the processor must divide its time between encoding and its other PC duties.
Some codecs, particularly those that use intraframe compression, are very processor intensive. As a result, the hardware requirements for PCs performing software-based encoding are greater than those of typical office PCs. Moreover, using a PC as the ingestion point for streaming content may also raise concerns about security and virus attacks.
If your customer has a conservative security posture or a high volume of content to encode, a hardware encoder may be a better choice. A hardware encoder is a dedicated piece of equipment just for encoding audio and video. It’s more efficient than a software encoder because it can devote all of its processing power to the application. Because it has no non-AV duties, the hardware encoder can be placed on a virtual LAN, insulating it from outside attacks. Such added security and capability comes at a cost, however; hardware encoders are typically more expensive than software-based encoding solutions.
Decoders
Once an encoded stream reaches its destination, it must be decoded. Assuming a blank slate at the endpoint, software decoding is usually simple, as long as the device is connected to the Internet. Most software codecs can be easily downloaded, but some codecs may be unavailable without an Internet connection. The IT staff can also arrange to install the necessary codecs on endpoints in order to decode the proper streams.
The endpoint’s available processing and memory are important factors in the smooth playback of computer-based decoding. You won’t have much control over these factors, so set expectations accordingly.
As in the case of encoding, hardware decoders are stand-alone devices that can play back media streams. Hardware-based decoding results in more reliable quality than PC-based decoding because the decoder doesn’t have to share processing resources with other applications. Hardware decoders are common in network AV systems with a dedicated streaming function, such as conferencing or digital signage. And, clearly, hardware streaming devices are common in homes, such as the Apple TV or Roku streaming players.
In general, software decoding happens when media is streamed to users’ computers or other smart devices; hardware decoding makes sense when streaming content straight to a display or other AV endpoint.
Streaming Servers
In order to stream live video at any sort of scale, you will need to select a streaming media server. The server may be a stand-alone piece of hardware or a software package installed on an existing web server.
Some organizations may find it more efficient to use a hosted streaming service than to own and operate their own servers. Especially in the case of common-carrier topologies or streaming systems with a dispersed audience, a hosted solution may represent the most efficient use of network resources.
When you’re specifying a streaming server or hosted solution, always take into consideration the following factors:
• Supported protocols
• Supported clients
• Encoding capabilities
• Transcoding capabilities
• Supported file formats
• Applications capabilities
• System requirements
• Ease of use
Caching Servers
In many situations, you will not be able to use multicast to manage streaming bandwidth. The routers on the existing network may not understand multicast requests. Or users may be streaming video on demand, which must be unicast in order to enable playback control. Or you may be streaming over the open Internet, which typically makes multicast impossible. In such cases, you can use caching servers to ease the burden on network resources posed by streaming services.
A caching server is a type of proxy server that saves local copies of frequently or recently requested network resources. Caching servers offer two benefits: they reduce latency by decreasing the response time to repeated requests, and they limit wide area bandwidth usage by keeping traffic within the LAN.
Normally, when a host requests a unicast stream from a source outside the LAN, the router forwards that request directly to the source and sends the resulting stream directly to the host’s switch. If more than one host requests the same stream, the router requests and receives a copy, which doubles the wide area bandwidth usage.
If, however, there is a caching server in place, the sequence of events looks like this:
1. The host sends a request for a unicast stream.
2. The router forwards that request to the source and receives the requested stream in return.
3. The router forwards the stream to the host and the caching server.
4. If another host requests the same stream, the router retrieves the stream from the caching server instead of the WAN. See Figure 10-4.
Figure 10-4 How a caching server works.
This approach reduces latency and confines traffic to the higher-bandwidth LAN. A reflecting server is a type of caching server. A reflecting server takes in a unicast stream and broadcasts out a multicast stream. It is often used for live data streams.
NOTE A content delivery network (CDN) is a distributed network of caching servers that can provide hosted unicast distribution of media for an organization. They are most often utilized by organizations whose content is in high demand.
Endpoint Interface
Once you’re successfully sending content across a network, end users need some means to access it. Neither the AV designer nor the IT service provider is typically responsible for creating the streaming end-user interface. However, you may be responsible for either purchasing one from a manufacturer or having one developed by a designer of custom user interfaces.
From the end users’ standpoint, the interface should be simple to the point of transparency—they click on something and a video plays. That “something” may be an email with a link to a multicast stream, a static web page with links to permanent on-demand content, an on-demand video portal, or a middleware interface such as YouTube, Cisco Show and Share, or VBrick. As usual, your selection depends on the complexity of your customer’s streaming needs.
Determine what user interfaces are included with the components you’ve already selected for your streaming system, such as the encoder or streaming server. Often, the included interfaces will be adequate for your needs. Then determine whether available interfaces are compatible with the codecs and middleware you’ve chosen to employ. If not, consider selecting a separate middleware user interface. You may have to go to a different manufacturer than your encoder or streaming server to get the codec you need.
NOTE Digital rights management (DRM) is not an issue with audio. Some digital audio files have DRM, but it’s in the software, not the signal stream. Therefore, DRM is addressed at the source and the receiver instead of in the transmission stream.
Chapter Review
Streaming AV is a foundational part of networked AV systems. The technologies and best practices you learned in this chapter will help you design related AV solutions. Now that you’ve completed this chapter, you should be able to
• Identify the impact of bandwidth restrictions and network policies on the design of a streaming application
• Identify the impact of inherent network latency on the design of a streaming application
• Calculate the required bandwidth for uncompressed digital AV streams
• Describe common compression methods and select proper codecs
• Identify the appropriate transport and distribution protocols for a streaming application
• Identify the major components of a streaming AV system
Remember, streaming AV consumes network resources—perhaps more resources than a network manager has anticipated. Document everything, from the needs analysis, to network restrictions, to the technical specifications of your proposed solution. If you can make the case that your streaming system meets the customer’s needs and you’ve created a design that respects the requirements of the larger enterprise network, you will be successful.
Review Questions
1. In a streaming AV system, what happens at the point of ingestion?
A. A media stream is encoded into a format that users can view.
B. A media stream is transcoded from one format to another.
C. A media stream is uploaded to a network for delivery.
D. A user views a media stream on a device of his or her choosing.
2. If a streaming AV system will send content over a WAN, which of the following is not a consideration?
A. The physical location of streaming servers
B. Bandwidth availability on every network segment
C. The addressing scheme of the organization
D. Whether the stream is generated by a computer or a camera
3. In a converged network, where 70 percent of the bandwidth capacity is available and 30 percent of the available capacity is designated for streaming, what percentage of the network’s rated capacity is available for streaming?
A. 21 percent
B. 30 percent
C. 50 percent
D. 70 percent
4. What might be considered acceptable latency for streaming desktop video?
A. 50 microseconds
B. 30 milliseconds
C. 200 milliseconds
D. 1 second
5. _______ compression is common for networked AV applications, such as streaming media and IP telephony.
A. Lossless
B. Lossy
C. Intraframe
D. Apple QuickTime
6. Which of the following protocols might you use in a streaming AV system? Select all that apply.
A. User Datagram Protocol
B. Real-Time Transport Protocol
C. Real-Time Transport Control Protocol
D. MPEG
7. Which of the following statements apply to unicast streaming? Select all that apply.
A. The more people who need to view the stream, the more bandwidth it consumes.
B. It uses group management protocols to control streaming channels.
C. It requires special routers called rendezvous points.
D. It makes use of special IP addresses assigned by the Internet Assigned Numbers Authority.
8. If your multicast streaming AV system runs on an IPv6-based network, the group management protocol to use is called ____ ____.
A. Internet Group Management Protocol
B. Multicast Listener Discovery
C. Source-specific multicast
D. Protocol-independent multicast
9. A distributed network of caching servers that can provide hosted unicast streaming is called a ____ ____.
A. content distribution network
B. content delivery network
C. cached distribution node
D. video-on-demand system
10. If your streaming AV system does not support High-Bandwidth Digital Content Protection (HDCP), it’s likely the system _______.
A. won’t be able to play high-definition video content
B. won’t be able to play standard-definition video content
C. won’t be able to play live video streams
D. won’t be able to play protected audio streams
Answers
1. C. In a streaming AV system, a media stream is uploaded to a network for delivery at the point of ingestion.
2. D. If a streaming AV system will send content over a WAN, you should consider the physical location of streaming servers, the bandwidth availability on every network segment, and the organization’s addressing scheme. It doesn’t matter how the stream is generated.
3. A. In a converged network, where 70 percent of the bandwidth capacity is available and 30 percent of the available capacity is designated for streaming, 21 percent of the network’s rated capacity is available for streaming.
4. D. In general, streaming desktop video can tolerate 1 second of latency.
5. B. Lossy compression is common for networked AV applications, such as streaming media and IP telephony.
6. A, B, C. When designing a streaming AV system, you might use User Datagram, Real-Time Transport, and Real-Time Transport Control protocols.
7. A. With unicast, the more people who need to view the stream, the more bandwidth it consumes. The other three statements apply to multicast.
8. B. If your multicast streaming AV system runs on an IPv6-based network, the group management protocol to use is called Multicast Listener Discovery.
9. B. A distributed network of caching servers that can provide hosted unicast streaming is called a content delivery network.
10. A. If your streaming AV system does not support High-Bandwidth Digital Content Protection (HDCP), it’s likely the system won’t be able to play high-definition video content.