Cloudflare Stream: ClientBandwidthHint doesn't work as expected — possible bug?


Expected behavior
According to the documentation, clientBandwidthHint query parameter works like this:

  • Require all video representations in the manifest have a bitrate at least the provided Mbps. This can be used to enforce a minimum level of quality at the expense of users on slower connections.

From this passage, it seems like clientBandwidthHint can be used to filter out the low-resolution streams, allowing you to form a manifest with multiple streams that have bandwidth higher than the provided value

Actual behavior
When clientBandwidthHint is provided the manifest always contains a single stream, even if the requested video is available in higher resolutions than the provided value

This thread describes that very same issue but was closed due to inactivity

1 Like

You’ll probably get more eyes on the topic if you edit the title so you can categorize it under Developers → Stream.

1 Like

Thanks for the hint!

Thanks for the hint @sdayman! I will figure out which one is the intended behavior and fix the docs or the implementation (likely the docs).

What’s your use case for clientBandwidthHint? I believe we implemented this feature in order to bypass certain video players’ bad bandwidth estimation algorithms when the app that plays back the video knows exactly what the bandwidth available is. Maybe what you need is a different solution.

1 Like

Hello @renan! Thanks for the heads-up

Our use case is very much in line with the current documentation: we wanted to use clientBandwidthHint to prevent Apple’s AVPlayer from using some of the low-resolution streams and only have something like 480 or 720 as the lowest possible resolution

There are other similar use cases. When playing back on large screen devices you might want to start with a high resolution rendition (while you wait for the automatic bitrate selection to kick in), and similarly you might have a scenario where starting with a low resolution version is preferred (for example, where you know that users are more likely to be using a low bandwidth connection). You might want the top bitrate renditions removed from a variant manifest, only exposing a “high quality” option through user selection or as a value-add for subscribers. Historically there have been devices which handled adaptive streams very badly, so just giving them a single bitrate to playback was desirable.

My expectation of a “bandwidth hint” is to set the default rendition. In parallel with that, there is probably a need for an upper and lower bound on the renditions returned. Perhaps even named sets of renditions (similar to the variant names for Cloudflare Images).

1 Like

Is there an update on this? The documentation and the implementation still seem to differ.

Any updates on this?

Hey @matt50 — thanks for flagging this. Our docs are indeed misleading here. We’re working on both clarifying our docs on this and considering what additional query params might be helpful here, to support the use-cases people have noted in both this thread and the original one that it links back to.

I’ll post an update here once we have more to share.

Any further update on this? I see you have fixed the documentation, but we still require the behaviour the documentation used to describe to get non-awful quality for our typical users.


Also looking for this feature asap… The default lowest quality provides a really bad user experience for us. This is one of the most important features surely.