Whenever we try to switch between different qualities in our videos, it can take upwards of 30 seconds for the change to actually take effect, which makes the player feel non-responsive, and can make the feature completely useless on some smaller videos(when changing from 360 to 1080, the video might be half over by the time the quality actually changes).
Is there any way to make the effect immediate, and rather have the player 're-buffer' with the new quality?
When the player is rendered in Flash and the quality is manually changed, the Flash player throws out whatever buffer it has built up and tries to immediately start loading the different quality, resulting in some buffering. When visiting your site, that buffering was only taking a few seconds, even whens witching from 360p to 1080p, but it would be understandable that people with lower speed connections would experience longer buffer times.
I would recommend trying to render the player and HLS stream in HTML5 wherever possible. As of right now, there is possible in Safari for Mac, Edge for Windows 10 and on Safari for iOS and Chrome for Android with no extra setting needed, as long as you are not explicitly telling the player to render in Flash.
As of JW Player 7.4, we have been able to render HLS streams in HTML5 in Chrome, but there is an extra setting needed to make this happen. If you’re using a single-line embed from your dashboard, you would just make sure the “Use HTML5 for HLS” checkbox in the player configuration is enabled (and the “Always Use Flash When Available” box would need to be unchecked). If embedding the content with .setup(), you would just need to add hlshtml: true to your setup.
In JW Player 7.6, the same functionality that allows us to render HLS streams in HTML5 in Chrome will be coming to Firefox (for Mac and Windows 8.1, or higher) and IE 11 (for Windows 8.1, or higher).
Please let me know if you need any more help or have any other questions.
We are primarily using the html player on our sites, and the problem I'm having is actually the opposite of what you mentioned; the player _doesn't_ immediately throw away the buffer and start loading the different quality. Instead, it continues to play the video at 360p for a while, before finally switching. I would prefer to have the behavior you mentioned, where the buffered content is thrown away.
And about the 'hlshtml:true', while that doesn't seem to fix this problem, it is probably nice to enable anyways :)
The expected behavior of the player in HTML5 would be for it to play whatever segments of the HLS stream it has already downloaded before requesting whatever quality selected in the HD menu. There is no built-in functionality of the player to immediately switch to the different quality. It’s important to note that the current behavior usually results in the best possible experience for the user as it eliminates the need for the player to stop playback while it buffers segments of the new quality. This is especially important for users on mobile devices and lower quality connections.
I have to say, though, that I find myself disagreeing quite a lot. As a user watching videos, I hate watching any of the video in lower quality than I am capable of running. So I much prefer what, say youtube, is doing, where it pauses the playback until it has buffered the new content. I can understand keeping the already buffered higher-quality video, when switching to a lower quality, but the opposite makes no sense. Also, If a person has lower quality connection, then they wouldn't be using the higher qualities anyways, no? Additionally, it makes the player feel unresponsive, as the user is not getting any feedback that the player is actually in the process of switching the quality(you press the button... and nothing happens). There should at least be a spinning wheel or something in the corner, until it is done successfully switching the quality...
So my final questions would be: If there is no built-in functionality for that, is there at least some workaround I could use to enforce the behavior? And if not, is this feature being considered, and maybe implemented sometime soon?
This is quite important to us, cause it's the only thing about jwplayer that we consider a flaw, as it makes the player feel unresponsive. And it's the only thing that makes us still consider looking for alternative video players.
I’m going to be completely honest with you here – while everyone has different opinions as to what their preferences are, I will say that the vast majority of the customers I speak with do want the content to begin playback as soon as possible and also want to see the playing stop and buffer as few times as possible.
As for the lower quality connections not needing higher qualities – you are right in some aspects but everyone starts at the lower quality for this exact reason. This allows everyone to start watching the playback as quickly as possible. After playback begins, if they are on a connection that allows them to watch a higher quality, they will see an upgrade in quality. If their connection doesn’t allow for the upgrade, they will stay at that lower quality. Also, if someone is on a lower quality connection at any point of time, it is not guaranteed that they will stay at that connection for even a minute. For example, if a family is on a road trip and someone starts watching a piece of content while in a place that doesn’t have good cellular coverage, they will be able to start playing the content quickly. Then, a mile down the road, they may enter a better cellular coverage area and their quality increases.
It’s also important to note that we have this behavior for rendering HLS in our player because it follows Apple’s specification. If you embed the HLS stream in a <video> element and view it in a browser that natively supports HLS, such as Safari or Edge, you will find that it will show the same behavior with starting with the lower quality. Actually, it won’t even give the viewer the ability to change the quality as it treats HLS as a purely adaptive format that will just change its quality based on network conditions.
There is a workaround if you want to force the player to play the stream at a certain quality and that would be to use the .setCurrentQuality() method in our JavaScript API. It should look something like this:
playerInstance.on("playlistItem", function() {
var availableQualities = playerInstance.getQualityLevels();
var highestQuality = availableQualities.length - 1;
playerInstance.setCurrentQuality(highestQuality);
});
Please let me know if you need any more help or have any other questions.
Thank you!
This question has received the maximum number of answers.
