Understanding the multi-bit rate solution

The goal of dynamically switching the stream to a different bandwidth during playback is to provide a better user experience for viewing large video files—including videos with extended length, large dimension, or very high quality—when the end user is in a network environment experiencing bandwidth fluctuations. If this scenario is not handled, the end user might experience a situation where video content can play for only a few seconds before it has to rebuffer. They may also end up watching a poorer quality video instead of the higher quality version available if more bandwidth had been freed.

Implementing a dynamic bandwidth switching process can enhance the end user's experience in two ways. First, it will initially calculate the bandwidth available between the server and the end user's machine and deliver the appropriate bandwidth initial stream. Additionally, it will continually monitor the stream and bandwidth and make adjustments on the fly, as needed. This method can effectively improve the video viewing experience without interrupting playback to an end user at any point.

One of the most difficult aspects of such a solution is making the switch between streams as seamless as possible. This may sound complicated, and it can be in varying bandwidth scenarios, as I'll discuss later in this article. Another primary concern in dynamically switching mid-stream to a different bandwidth is that if it is done too often, it can hurt playback more than it helps. After following along with this article you'll learn how this can be addressed and understand the challenges involved in determining factors such as the end user's average bandwidth over time in a streaming environment.

The challenge

More video is being streamed on commercial websites these days, and consumers have grown accustomed to seeing video-based content on the web. They associate these rich experiences with website and product quality. Additionally, the functionality available to share video-based content on the web has empowered a wider audience to become video contributors to the Internet. As a result, there is a lot of video content, and much of it is being delivered via Flash.

With this ubiquity of video—especially high-quality video—on the Internet, bandwidth consumption can be very high, even within standard use cases. Coupled with creative executions that specify, and server hardware that allows, streaming high-definition and full-screen content via the web, the incidence of an end user consuming their network connection's maximum bandwidth allowance is more common than ever. This issue can be intensified with standard network fluctuations that, if not handled properly, cause the end user to experience repetitive buffering of video content.

Requiring an end user to select a target bandwidth and associated video quality as the decision point for choosing which video bit rate to stream is not preferable, especially when this detection can be performed by Flash Media Server 3. Forcing the end user to make a choice not only results in poor user experience, but it is also likely that the end user's assessment will not accurately reflect the actual bandwidth available. Another major benefit of using the information you can determine about the connection between the client and the server is that you can also determine the state of the server. For example, even if the end user has an abundance of bandwidth, the server may be in a peak tasked capacity state, making the matching bandwidth on the server unavailable to deliver to the end user.

Monitoring bandwidth capabilities in a two-way scenario (server and client) is an important concept in stream management. Key factors in bandwidth fluctuation that can cause continual interrupted playback can generally be divided into three categories: server-side issues, connection provider (ISP) issues, and client-side issues.

Server-side issues

These issues can involve your Flash Media Server configuration, maximum server bandwidth or performance load exceeded, or content delivery network load balance or distribution issues.

Flash Media Server configuration
If your installation of Flash Media Server is not configured appropriately for the maximum simultaneous load, or if it has any specific application limitations that restrict the number of connections and/or allocated bandwidth, these factors could adversely affect user experience and could lead to bottlenecking connections. In general, if the maximum capacity has been reached at the server to deliver the appropriate experience to each connected end user, the server should not allow any additional connections until a previous user has disconnected. This configuration ensures a quality experience for the already connected users.

Maximum server bandwidth or performance load exceeded
Similar to the issue described above, it is recommended that the number of connections be limited so that a high-quality experience is maintained for existing users. Setting a limit on the number of connections is optimal, compared to letting an unlimited number of users connect to the server. This setting will be based upon your specific application requirements. You can avoid playback issues by performing proper load planning calculations and monitoring actual server usage.

CDN load balance or distribution issues
If you are using a content delivery network (CDN) to deliver your streaming content, any balance or distribution errors on the CDN's network will result in issues for your users. Bandwidth allocations and connection limitations are generally part of your agreement with a CDN vendor. Be sure appropriate planning is applied to handle peak and burst scenarios in order to achieve the best end user results.

Connection provider (ISP) issues

These issues can involve dynamic bandwidth throttling or networks affected during peak user times.

Dynamic bandwidth throttling
Some Internet Service Providers (ISPs), as well as some more advanced network management scenarios such as educational, government facilities, or corporate network environments will integrate a dynamic bandwidth throttling network infrastructure. The purpose of the dynamic throttling is to attempt to provide all users with a high-quality experience by limiting those with high session consumption rates over time. The end result for these users is a fast initial connection with plenty of bandwidth available; however, the bandwidth allocation for users consuming great quantities of bandwidth for extended periods (such as streaming longer video content or downloading files from a peer-to-peer network) is continuously decreased to allow new connections to access more initial burst bandwidth and to generally discourage extended use. Dynamic throttling can be difficult to manage in normal scenarios, especially when streaming HD video.

Peak user time affecting network
Some types of network/Internet connections are greatly affected by the gross number of concurrent users on a large network at the same time. This issue occurs most frequently on cable Internet connections. If a significant number of end users are connected simultaneously, you may notice greater fluctuations and decrements to the available bandwidth during the course of a connection.

Client-side issues

These issues can involve shared connectivity, network hardware issues, or client hardware limitations.

Shared connectivity
Users in a shared connectivity environment—such as a household, Internet café, WiFi hot spot, airport, or small office—share the relatively limited bandwidth among the other simultaneously connected users. When many concurrent users connect to a small network, it is likely that the experience for any one end user will fluctuate a great deal. In addition, if there are any "power users" on the network who are consuming a relatively large amount of data for a single end user, (such as multitasking, watching videos, uploading content, using an online collaborative application, talking on VoIP, or using a web cam) the shared bandwidth across the network can become increasingly slow.

Network hardware issues
Although generally less common, client-side hardware issues with routers, hubs, or network interface devices, or other problems such as driver conflicts can also lead to bandwidth issues for end users.

Client hardware limitations
On the client side, it's important to consider the limitations caused by the user's hardware, such as their video card. If their video card can't process the incoming information fast enough or if the system's resources are otherwise occupied, the stream's buffer may empty. In addition to hardware limitations, standard fluctuations in connections should be expected. These fluctuations can have adverse affects on the playback of video content. This issue is especially encountered when streaming HD content, especially in the full-screen aspect. In such cases, users typically have the vast majority of their bandwidth committed to sustaining the stream, which leaves little margin for correcting any other factors such as normal bandwidth fluctuation. Videos with shorter duration, smaller file size, and smaller dimensions generally are not as susceptible to bandwidth issues and fluctuation. Therefore, determine if the video content you are streaming warrants the implementation of the tactics outlined below. If you are not streaming HD content, some of these strategies may not be necessary.

Later in this article I'll discuss bandwidth-limiting issues further and describe best practices for handling them directly. You will learn how to take the solutions further and customize them to suit your specific needs.

The recommended solution

Dynamic bandwidth stream switching can be implemented in many ways. Each approach has its own benefits and consequences. The single solution provided here is a direct and viable one that provides high accuracy and minimizes end user disruption. Remember that it is important to consider the requirements of your particular video distribution system before implementing any of these solutions. The following questions can help you determine the best approach to take:

• Is stream switching really needed? Will implementing stream switching help more than it hurts? For videos with short duration or small size, dynamic bandwidth stream switching is probably not necessary. When delivering HD video and longer length video content, stream switching is most likely a good option to improve playback. Also, it's critical to understand your user base. Standard home users are more susceptible to the adverse situations that require dynamic bandwidth switching compared to large, corporate user bases.
• Be careful not to over-architect a solution. Sometimes there isn't a perfect solution currently available for your scenario. The solutions available for optimizing bandwidth and video playback do not cover all situations. Before applying any solution, analyze your scenario to identify which bandwidth-limiting issues are likely to affect your users. Based on your findings, determine the best solution/implementation.
• Understand the benefits and the drawbacks of any implementation. As with any changes in server or client flow management, factors such as server load, management, and capabilities should be considered before continuing.

After analyzing your system and identifying a need to implement a dynamic bandwidth switching solution for your application, you can research how the solution will work and how to implement it. The diagram below illustrates the flow of the recommended solution (see Figure 1).

Figure 1. Flow chart of the dynamic stream switching solution

The flow of the dynamic stream switching solution can be described as follows:

1. The application initializes. It accesses a collection of video files and their matching bit rates.
2. Once the connection to Flash Media Server is complete, perform a bandwidth detection test.
3. Based on the results from the bandwidth test, start the appropriate stream from the collection.
4. Start playing the video with a small, quick start buffer.
5. Once the quick start buffer is full, set the buffer to a standard size,
6. Start listening for bandwidth issues and the need to step-down the bit rate by monitoring the buffer empty events and their count versus the threshold.
7. Once the standard buffer size is full and there have been no issues, start a timer to check that playback is uninterrupted and smooth for a reasonable duration (approximately 20–30 seconds) before starting the upscale test. If any buffer issues are triggered during the standard extension test, start over by returning to step five.
8. If the standard play test was successful, track the current size of the filled buffer, and also track the current time in the application (not the video). Set the buffer time to 2–3 times its current filled length (be sure to use its current length which includes the buffer overrun value—rather than the original buffer length).

9. Wait for the new extended buffer to be filled. Once it is full, calculate the available bit rate using these formulas:

   [buffer amount loaded in test] = [target extended buffer] – [tracked start buffer time]

   [time to complete test] = [current time of application] – [tracked start time of test] (convert to seconds)

   [total bytes loaded in test] = [current stream bit rate] × [buffer amount loaded in test]

   [available bit rate] = [total bytes loaded in test] ÷ [time to complete test in seconds]

10. If the available bit rate is enough to upscale to the next stream, swap to that stream and restart the process from Step 4.

Page 2 of 7

Previous Page

Next Page