I watch a lot of streaming video. That’s probably not a big surprise - a lot of other people are, too. I also have a lot of devices I use to watch video. From the Roku TV in the living room, to the Fire TV stick in the bedroom, and my iPad mini for when I’m not near the TV. Not to mention the Chromecast for travel, which admittedly, is a less common occurrence these days.
Suffice it to say, I watch content across a lot of different devices and the quality can be markedly different across them. One of the important determining factors in the experience is the bitrate of the video that is played on a device.
If you would like a detailed description of bitrate, bitrate ladders, and how it impacts the video experience, please read Jon’s blog on how Mux Video per-title encoding works for more information.
The bitrate of the video that is delivered to a user can vary a lot based on the type of content, the quality of the network connection a viewer is on, the ISP and location where a user is accessing from, the type of device used, and more. Although the optimal bitrate for a video depends on a lot of different factors, in general, you want to deliver the highest bitrate available for the content that makes sense for a user’s device.
The bitrates available are specified in the manifest file of the video a viewer is watching. Each time a rendition is chosen by the player, the Mux SDK tracks the bitrate specified for the rendition in the manifest file - this is called the indicated bitrate. Mux Data now provides a few different ways to view bitrate data collected from viewer streams: Real-Time Current Bitrate, Weighted Average Bitrate, and the Video View Event Timeline.
Real-Time Current Bitrate
The Mux Real-Time Dashboard is the best way for teams to monitor the video experience and operational performance of their video platform. It shows the most important performance metrics, with a few seconds of latency from the player to the reporting dashboard.
In real-time, the dashboard tracks the Current Bitrate being served across your viewer population. The bitrate recorded for a view is the bitrate of the rendition that is being played at the start of the 5 second real-time reporting interval. The currently viewed bitrates for all of the viewers is aggregated as an average.
This metric allows you to report on the current bitrate levels served to users in different countries, on different ISPs, and for each video title. If your users are experiencing issues with slow networks or you have a player malfunction, you will often see a drop in the bitrate level and can identify the operational cause.
A customer was doing a live stream and noticed that the bitrate being delivered to viewers was a lot lower than normal. They used the real-time dashboard to see that the issue was specific to iOS devices. With a little diagnosis it became clear it was due to the ABR algorithm behavior on their native iOS app that had recently been released.
Weighted Average Bitrate
The current bitrate is helpful for tracking immediate drops in performance but long-term analysis often needs a different type of analysis. You need to consider all of the bitrates used throughout a view.
As each view finishes, the amount of time spent playing at each bitrate is used to calculate the view’s Weighted Average Bitrate. Each bitrate played during the view is multiplied by the percentage of time the video spent playing at that bitrate. For example, if a video was played at 1Mbps for one quarter of the view and 2Mbps for the rest the Weight Average Bitrate would be calculated as: 1Mbps * 25% + 2Mbps * 75% = 1.75Mbps.
The Weighted Average Bitrate is helpful for understanding the overall quality the user experienced during the whole video playback. If the viewer saw a high bitrate for most, although not all, of their view, the weighted average would have a higher bitrate to reflect what they saw for most of the view.
All of the views are aggregated together to an overall median or P95 metric. You can drill down into specific dimensions, to see how live stream performance compares to on-demand, and filter the results based on video metadata. You are able to investigate how players on less capable devices max out at lower bitrates or how occasionally titles are being encoded without the higher bitrate renditions.
For example, a Mux Data user found that they were delivering a lower bitrate to viewers than they expected. Their video is encoded at a bitrate up to 4.5 Mbps but their logs reported that their average delivered bitrate is much lower than that. They wanted to understand why and what could be done to improve. Very easily they isolated the players - specifically late model Fire TV (AFTM) and Fire TV Basic Edition (AFTT) - that were showing viewers lower bitrate videos. They can now make an educated trade-off about whether they should prioritize trying to increase quality for theses device or focus on other areas for improvement.
Video View Event Timeline
In addition, you are able to inspect the history of each view that occurs in order to understand more about the viewer’s individual experience watching the video. You are given all of the important metrics (such as Video Startup Time, Weighted Average Bitrate, Overall Experience Score, etc.) as well as the event timeline of events that occurred during the view.
The timeline now includes an event for each rendition change that occurred during the view. From here, you can see how often and when the video changed renditions during the view. You could, for example, see if the ABR algorithm for a player is switching renditions often when a view starts, possibly impacting the viewing experience.
Release
The bitrate metrics are now available to all customers and SDK support is being released over time. You will need a recent version of the iOS AVPlayer, ExoPlayer, mux-embed, or other SDKs to collect bitrate data. As of now, Current and Weighted Average Bitrate is supported on AVPlayer, ExoPlayer, hls.js, Dash.js, Video.js, Shaka Player, and JW Player web. Support will come to other players and platforms as well.
As always, please let us know if there are SDKs you are using that would be useful for us to support.
