When you stream a video through Mux, a lot is going on in the background. Videos are being transcoded into a range of qualities, segmented, and delivered back to the viewer, all leveraging a just-in-time architecture, allowing lightning-fast publishing times.
When we deliver that content, we use a segmented streaming format called HTTP Live Streaming (HLS). HLS uses a series of text files, commonly called manifests or playlists, to describe the available qualities of a video and the location of all the segments that comprise the video.
While our aim has always been to provide video infrastructure that works great out of the box, everyone's use cases are different. Sometimes the default decisions that we make for Mux customers as a whole might not be what best suits you or your viewers.
Over the years, we've introduced a couple ways for you to manipulate manifests, including adding support for the max_resolution parameter with the launch of resolution-based pricing. This parameter enables you to control the maximum resolution of video streamed on every view, giving you more control over the cost of delivering high-quality video.
Today, we're adding a few more ways for you to manipulate your manifest at playback time to help you tailor the experience your viewers have when streaming content. We call these tools "playback modifiers".
New playback modifiers available today
min_resolution
min_resolution lets you control the minimum resolution at which we deliver your content. For example, setting this to 720p would mean that a video is only delivered in qualities of 720p or above, taking into account the video's orientation. For videos ingested in 1080p, this would generally mean that you would see only the 720p and 1080p quality options available in the video player, as shown below.
You might want to use this feature when the visual quality of your content is critical to the delivery, such as in live streams with detailed screen share content, like a learning management system (LMS) or a technical conference live stream.
Like all playback modifiers, all you need to do is add min_resolution to your playback URL:
If you're using signed URLs, you'll need to embed "min_resolution" : "720p" into your JWT claims field. Full details can be found in the documentation here.
This level of control can come with downsides, however. By filtering out renditions below 720p, viewers with poorly performing internet connections (below around 2.5Mbps for 720p) will experience higher levels of rebuffering. We strongly recommend using Mux Data to monitor your playback experiences and run A/B tests where appropriate to measure the impact of filtering your renditions.
min_resolution can be set to the following common video size values:
- 480p
- 540p
- 720p
- 1080p
- 1440p
- 2160p
You don't need to think about the orientation of your content, we'll take that into account when we generate the manifest.
rendition_order
Most HLS video players will start playback with the first rendition that appears in a playlist for streaming video and will then leverage adaptive bitrate technology to adapt up or down based on a viewer's internet connection. Today, Mux uses internal logic to set which rendition is exposed as the first rendition. Generally, this means starting with 720p.
However, sometimes this isn't what's best for viewers. You may actually know more about your viewers’ network conditions and devices than we're able to know on a first manifest request. For example, if it's a smart TV or a set-top box where the user has a history of a great internet connection, it's usually safe to assume that the device won’t suddenly move to a mobile network and need to start at a lower resolution.
You can now manipulate that order by using the rendition_order=desc playback modifier to force Mux to order renditions descending by resolution, so the default playback experience will become the highest-quality video that's available. For example, if you ingest a video in 4K using our new 4K support, setting rendition_order=desc means that the 2160p (4K) rendition will be presented as the default to the player. Again, if you're using signed URLs, you need to embed rendition_order into your JWT claims.
Let's take a look at what the HLS manifest looks like before and after applying the rendition_order=desc parameter:
We can see that the 1080p rendition has now moved to the start of the manifest, which generally triggers players to prefer this rendition when starting playback.
Some disclaimers also apply here. By starting at a higher rendition, if the network environment isn't as good as you're expecting, you may cause viewers to experience longer startup times or more rebuffering early in their viewing session. Again, you can use A/B tests in Mux Data to measure and verify the impact on your viewers of leveraging this feature.
Combining playback modifiers to optimize viewer experiences
You can also combine multiple playback modifiers to build the right experience for your viewers. min_resolution is especially powerful when combined with the existing max_resolution playback modifier, as you can use it to build different experiences for different tiers of a streaming service.
Let's say I'm building a new streaming service, Dogs+, devoted to man's best friend.
For free viewers, I can use max_resolution=720p to make sure I can control the cost of streaming video openly.
For the basic tier of my subscription, I could offer videos capped at 1080p by using the max_resolution=1080p playback modifier.
And for the premium tier of viewers, in addition to offering exclusive content, I'd allow full 4K playback, so the video looks great in the living room on a smart TV. When I know these viewers are watching on a great connection, I'll also remove renditions below 720p from the manifest and make sure the videos always start at the highest quality by using a series of playback modifiers:
max_resolution=2160p could be added, but this is optional, as the default behavior is to include resolutions up to the max_resolution_tier of the asset. We should see something like this in our video player:
These aren't the first playback modifiers we've built. You can check out the full list of available playback modifiers in the documentation.
Have a playback modifier you really want to see in Mux? Let us know at info@mux.com, and it might just be the next one we build.