Plyr: YouTube quality selector

[friday]

This was mentioned in #793 and #218, but I think it should have it's own issue for searchability and in order not to derail/hijack those issues any more than presently.

The problem with YouTube quality selection is that YouTube ignores it. The current implementation uses the documented YouTube API correctly, but they decided to stop supporting it. Seemingly, the only way to fix this would be some kind of a hack. I think the best option is to remove the current implementation not to confuse users, then document provider (HTML5 Audio, HTML5 Video, YouTube, Vimeo, Hls.js, Dash, Shaka Player) support for various features like captions and quality selection in the docs.

For details see https://github.com/sampotts/plyr/issues/793#issuecomment-371403917

[friday]

I have experimented with css and have been able to "trick" YouTube into thinking the device viewport size has changed, making it change the quality. The hack itself may blur the quality improvements gained by the higher quality though (hard to test this since YouTube tries to give you the optimal quality for your device pixel ratio to begin with). It also affects the youtube controls size, and I don't think we can use this, at least without further changes.

• Go to https://plyr.io/#youtube
• Start playing
• Open developer tools "console"
• Run player.embed.getPlaybackQuality() (says large on my laptop, but might differ if you have a larger screen)
• Run this:

Object.assign(document.querySelector('.plyr__video-wrapper iframe').style, {
    width: '400%',
    height: '400%',
    transform: 'scale(0.25)',
    transformOrigin: 'top left'
});

If you run player.embed.getPlaybackQuality() again, (wait a couple of seconds for the auto quality selector to pick up the change first) the output should be something different from before. In my case I got hd1440.

[Hi1307]

Will this "workaround" eventually be worked on? I think it'll be a massive QOL upgrade.

[friday]

Probably never. A workaround with side effects is worse than no workaround imo. Also probably violates their terms.

[sampotts]

As above. I’m really on the verge of going back to pure HTML5 and improving the support for streaming (and teaching myself about it). Constant issues with crap API, SDKs and UX with YouTube and Vimeo.

[Hi1307]

As above. I’m really on the verge of going back to pure HTML5 and improving the support for streaming (and teaching myself about it). Constant issues with crap API, SDKs and UX with YouTube and Vimeo.

Aw. But to sidetrack a bit, I do agree that the big players have had many issues, among which changing their API is one of them. YouTube recently did it, and now the video title displays every time.

[victorsaagbmediagroup]

I have experimented with css and have been able to "trick" YouTube into thinking the device viewport size has changed, making it change the quality. The hack itself may blur the quality improvements gained by the higher quality though (hard to test this since YouTube tries to give you the optimal quality for your device pixel ratio to begin with). It also affects the youtube controls size, and I don't think we can use this, at least without further changes.

• Go to https://plyr.io/#youtube
• Start playing
• Open developer tools "console"
• Run player.embed.getPlaybackQuality() (says large on my laptop, but might differ if you have a larger screen)
• Run this:

Object.assign(document.querySelector('.plyr__video-wrapper iframe').style, {
  width: '400%',
  height: '400%',
  transform: 'scale(0.25)',
  transformOrigin: 'top left'
});

If you run player.embed.getPlaybackQuality() again, (wait a couple of seconds for the auto quality selector to pick up the change first) the output should be something different from before. In my case I got hd1440.

At least to this date this is still working.

[friday]

It was an experimental css hack that I probably shouldn't have posted to begin with. While you can use it to change the source quality of the stream, it also makes the video controls (visible when paused) tiny. And if you go the other way they become huge, which is worse. I also didn't actually investigate that the quality at higher resolutions didn't get negatively affected. The CSS is zooming in and out with two different techniques, and things like this can cause quality loss.

So it's a dead end I'm afraid.