When changing the playbackRate in Chrome Mobile on Android (I tried on Android 6.0.1, Nexus 5), nothing happens. The playbackRate getter returns the selected rate correctly, but the actual rate of playback in the player doesn't change. Is this a bug in Video.js or in Chrome Mobile?
The controlbar shows the current playbackRate.
The media's playback rate changes accordingly.
Getting the playbackRate via the API returns the value set by the user.
The controlbar shows the current playbackRate.
The media's playback rate does not change.
Getting the playbackRate via the API returns the value set by the user.
No error(s).
Tested on a real device and in an emulator.
5.8.3
Chrome Mobile
Android 6.0.1
videojs-contrib-hls
I don't believe they implement playback rate in mobile clients. Maybe take a look at server side packager that can adjust playback rate: https://github.com/kaltura/nginx-vod-module
Thanks for that information.
What is confusing to me is that the API seems to be implemented in Chrome Mobile, but the behaviour isn't. Seems very odd to me. It breaks the feature detection in Video.js, causing the playback rate control to appear when it shouldn't.
If it really isn't supported on mobile but the API is present, I guess we should black list here it until it's implemented
It might be worth mentioning that I tested this on an iPad (hardware, iOS 9.2.1) as well and on there the playbackRate does work. So it looks to be just an Android problem, not mobile in general.
Chromium bug: playbackRate isn't implemented on Android
Anyone want to make a PR that blacklists Chrome for Android?
Also not support in Android Chrome 53.0.2785.121 version...
Is there a link where I can follow/vote the status of this feature for Android Chrome?
@beebase see @mister-ben's comment above.
on android 7.0 with latest chrome i have the problem, that the main div for the playbackrate gets set to hidden:
<div class="vjs-playback-rate vjs-menu-button vjs-menu-button-popup vjs-control vjs-button vjs-hidden" tabindex="0" role="menuitem" aria-live="polite" title="Playback Rate" aria-disabled="false" aria-expanded="false" aria-haspopup="true">
so why is vjs-hidden used here ? when i switch to desktop view, i see that button, and PlaybackRate is working.
thanks for any help!
It looks like Chrome quietly fixed this a while back and we could stop blacklisting playbackRate newer versions of Chrome for Android. The bug report suggests it was fixed in 52 but I've only been able to test in Chrome 58 (on Android 6.0.1)
I tested an HLS stream in Chrome 58 on a Nougat device and it still doesn't work 馃槙
Chrome's native HLS still does not support playbackRate, but using videojs-contrib-hls with the nativeOverride option works.
android chrome native HLS doesn't support playbackRate. I tested on version 71, going so far as to run document.getElementsByTagName("video")[0].playbackRate = 10 in the console. The playback speed did not change. (It did work on firefox).
I checked chrome 58 on app.crossbrowsertesting.com, and also found that the speed didn't work there, either.
I think this issue should be reopened?
Or is the official position from @mister-ben , that
Chrome's native HLS still does not support playbackRate, but using videojs-contrib-hls with the nativeOverride option works.
meaning chrome doesn't work, but it won't be blacklisted because we can use videojs-contrib-hls (or builtin to videojs v7 via http-streaming)
I came by this issue on an Android 9, Chrome 81.0.4044.138 and VideoJS 7.7.6.
Playback rate works on all desktop browsers and even on Firefox mobile, but still does not work on Chrome for Android. I am not using videojs-contrib-hls as it is supposed to be deprecated as of videojs 7.0.0.
Any ideas why the problem still persists?
I am not using videojs-contrib-hls as it is supposed to be deprecated as of videojs 7.0.0.
Sorry, I don't have time to research this now / test extensively, but @mister-ben's main point with
using videojs-contrib-hls with the nativeOverride option works.
is that when chrome handles hls itself, using it's own builtin code, it messes up playback rate.
But if we tell chrome not to even try, and all the hls support (parsing the m3u8 files, etc) is handled by videojs javascript, then videojs's JS will handle playback rate properly.
The exact method of getting to non-native hls support has changed, but the principle (that non-native hls support handles play back rate) remains.
So - in 2017, the way to get non-native hls support was with videojs-contrib-hls.
In 2020, you get non-native hls support with http-streaming, which comes packaged with videojs (unless you get the minimal build).
I don't know offhand the config to tell videojs to force non-native hls, but it's probably still nativeOverride, or easy enough to find in docs online.
Addendum
IMO, there's no real performance benefit to using native hls over JS hls. The real work is in parsing the raw media files, which is still being done native - hls is just an xml file which describes what media to use for given network conditions etc. Whatever theoretical performance benefits there might be to using native for parsing xml etc would be super not noticable, and nothing compared to the real work of actually playing a video file.
@yringler thank you for the detailed explanation.
This is the code snippet that fixes the issue -
videojsPlayer = videojs('my-player', {
controls: true,
preload: 'auto',
playbackRates: [0.50, 0.75, 1, 1.25, 1.5, 2],
aspectRatio: '16:9',
html5: {
hls: {
overrideNative: true
},
nativeVideoTracks: false,
nativeAudioTracks: false,
nativeTextTracks: false
}
});
Strangely, I couldn`t find the html5.hls overrideNative option in the documentation.
Most helpful comment
It looks like Chrome quietly fixed this a while back and we could stop blacklisting playbackRate newer versions of Chrome for Android. The bug report suggests it was fixed in 52 but I've only been able to test in Chrome 58 (on Android 6.0.1)