Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Dynamic streaming/Adaptive bitrate best practices and behavior questions

I have several inter-related questions about adaptive bitrate streaming through your player.

But first my context:
Configuration: JWPlayer 6.8, RTMP through Cloudfront/AWS, SMIL files, MP4.

I'm currently creating about 7 different versions of each streaming video for dynamic switching based on the user's bitrate. The bit rates of my files are unevenly spaced out (in terms of the difference in kbps between each file). I have a few HD-level versions close together (~200kbps apart), the rest of the files are spaced quite widely. I've had several different types of buffering issues that I mention below.

I don't currently have diagnostics to track which bitrates are being used the most, causing buffering the most, nor insight into how the dynamic switching algorithm works in JWPlayer. This info would really help me understand how best to adjust my setup to minimize buffering frequency and duration.
My questions are:

1. How does the "downshift" or "upshift" Auto mode work? Does the player jump right to the target data rate from the menu, or cycle through every version on the way to the destination data rate?
Just wondering if this could explain repeated buffering I've occasionally seen.

2. What do you recommend in terms of best practices for spacing out the bit rate sizes (to minimize buffering)? I chose my high end/low end rates according to best practices on other video websites, but not the intervals between them.

Even spacing, e.g. a certain bitrate distance apart (e.g 700kbps?) ? Is there a minimum “safe” distance between data rates to reduce chances of repeated buffering if the network fluctuates?
Ad hoc spacing, for instance to be able to offer more HD-versions at a particular bitrate spectrum (3000-3500kbps), and fewer, further between options for lower bandwidth connections.

I've wondered if having a few files close together in data rate has exacerbated buffering issues on my site.

3. What is the player's behavior for moving BACK to a higher data rate when the player has already moved to a much lower rate? If and when will it restore the better quality stream?

I've seen temporary network issues cause the player to auto-select a 300kbps file on a 24Mbps connection. Even when the network issue immediately resolved, the player did not restore the higher-rate video stream quickly, so I manually overrode the setting to get back to HD (which played fine). Re-enabling Auto caused it to jump back down to the low quality 300kbps stream.

4. Finally, Can you provide any recommendations about how to monitor which data rates are being used/not used, and conversely which rates are causing the most buffering? Cloudfront monitoring logs may show which files were streamed, but are unlikely to provide much insight into dynamic switching behavior, and it will be hard to decouple client-side actions (pauses) vs auto-buffering.


6 Community Answers


0 rated :

I'm having the same issues Valerie mention on point 3 using RTMP streaming. Once a lower end quality bit rate is chosen due to bandwidth, the player doesn't alternate back to a higher quality bit rate when the bandwidth improves, ever.

So I decided to try using HLS on Chrome and Firefox to avoid using RTMP, but there is clear shuttering every 10 seconds or so (it's like the .ts files are not frame accurate, which they are because the transitions work perfectly smooth in Safari). Russell reported the same issue on April 28.

I'm using version 6.8.4616

If you guys could fix at least one of the two issues as quick as possible our team would really appreciate it.


Ethan Feldman

JW Player Support Agent  
0 rated :

Do you guys have examples of where it is running and having the issues with stuttering? Regarding RTMP. it won’t change during the stream, only at the start, that is the nature of RTMP.


0 rated :

Hi Ethan,

'RTMP can do dynamic streaming, where the video quality automatically adjusts to changes in bandwidth'

That was written in this article:


Is there an email where I can send you a link? We are currently in development and I don't want to share the link to the public.

Ethan Feldman

JW Player Support Agent  
0 rated :

Sure – support [at] jwplayer [dot] com


3 rated :

Valerie, here's some answers. Hope they help!

1) Downshifting in Auto mode is triggered by a buffer underrun. Whenever the buffer runs low, JW Player will switch to the quality level that does fit in the then measured bandwidth (at a ratio of 2:3). Upshifting theoretically works the same, but in practice the RTMP protocol is notoriously bad at determining bandwidth vs actual sustained server>client datarate. This means in practice that upswitching occurs infrequently and unreliable. It's one of the reasons for us much preferring HTTP protocols like HLS.

2) In terms of best practices, I'd use 3 to 8 datarates, with 3 for low-volume longtail content and 8 for high-volume premium content. Spacing is best done at common bitrate multipliers vs fixed bitrate intervals. A good starting point is the technote Apple provides for its iOS devices:

3) The player switching logic for RTMP is described under (1). The HLS bitrate switching logic is executed at every single fragment load, making the protocol much more responsive to changing bandwidth conditions.

4) For both HLS and RTMP, we expose bandwidth info through the onMeta() API callback. Filter the data that returns from it on events that contain metadata.bandwidth. In addition to bandwidth, these events will contain the current quality level. A good (and cool) demo for this is our adaptive streaming one:


0 rated :

Rafael, your RTMP question should be answered above. This is really a protocol / player limitation.

Your HLS question sounds like a bug or actually still a keyframe alignment issue (Safari is very resilient around this). Please contact our support for this, so they can investigate your stream.

This question has received the maximum number of answers.