[1.6/2.0] Quality switching seems to not load higher qualities

[nickygerritsen]

Hi all,

I was trying to update the videojs-contrib-dash plugin to Dash 2.0 using the development branch and came across an issue.

If I load the BBC testcard video in the 1.5 reference player, I see it will load the highest quality pretty fast. I.e. it loads "rep index" 13 after a few seconds. This is what I expect, as I have enough internet speed and a big enough video player for 1080p to make sense.

However when I use the same content in the 1.6 reference player or in a locally built 2.0 reference player, it never ever loads a quality higher than 540p (rep index 11).

I'm not sure what changed and if this is expected behavior, but this seems odd to me.

[nickygerritsen]

Btw, dash.all.debug.js does not get created so the reference player is broken by default.

[davemevans]

I suspect this is due to limiting the representation used based on the size of the playback area, a feature which was added in 1.6 and is now also in 2.0.

To disable this, call MediaPlayer.setLimitBitrateByPortal(false).

The dash.all.debug.js problem has been spotted and fixed with #1026 which has not yet been merged.

[nickygerritsen]

Hmmm but I even tried going fullscreen on my laptop. Does it ignore Retina on Mac? Because then maybe it would make sense it does not use the 1080p.

[davemevans]

When I switch to full screen (1920x1080), once the existing buffered media at the previous representation has been exhausted (can be up to around sixty seconds), the resolution changes as I would expect. Switching back has the same effect.

[nickygerritsen]

Ok will try it on a 1080p monitor. However my laptop is >1080p but with retina, so maybe we should take the scale into account?

[nickygerritsen]

So what I mean is multiply by window.devicePixelRatio when calculating the portal size

[wilaw]

@bbcrddave - two questions for you on this subject:

1. What if my small screen device is connected via HDMI to a 4K TV.? Does the video window size show 2160p, or the max size of the device?
2. I gather that setLimitBitrateByPortal is currently true by default. This is somewhat of a non-intuitive feature and I can see this causing issue with new users who are wondering why their content has not switched up to the highest bitrate in their test players even though they have excellent bandwidth. Providers who want to implement this in their solutions can easily turn it on. What do you think about having it disabled by default?

[nickygerritsen]

@wilaw:

1. It uses the <video> element size, so that should not be a problem
2. I think normally you want the setting enabled (as it saves useless bandwidth usage), but maybe a toggle could be added to the reference player page?

[JibberJim]

I think it should be true by default, in fact, I think the support devicePixelRatio should be OFF by default, until we have a quality metric that switches down quality in response to device ability to play it back. We have found a lot of problems with devices simply failing to play back high quality representations due to processing power on the devices, rather than bandwidth. The ability to constrain representations by changing the window size at least helps some users get playback when it otherwise fails.

But of course it depends how quickly we can get a working droppedFrames / "can I actually play this" ABR rule implemented how much it really matters.

[nickygerritsen]

I think not using device pixel ratio because the machine might not be able to handle processing seems strange. These two are not really related and if I would attach a bigger screen the same problems would still arise.

I understand that processing power is a problem, but if that is really the case then we should fix that somehow? It seems strange to me to e.g. limit a MacbookPro output to 720p because there are some devices that can not handle 1080p but do have a 1080p screen.

Or am I saying strange things?

[davemevans]

It was resolved on the call to default setLimitBitrateByPortal to false.

[dsparacio]

I am setting this to false now with a commit that is related.

[dsparacio]

Fixed in PR #1047