Testing device 4K capabilities

"johnmarsden" wrote:
Is there a sure-fire way right now to determine if someone is using a 4K capable Roku device?

It may not be the ideal solution, but I believe if you use roDeviceInfo.GetSupportedGraphicsResolutions() and look for an entry with name = "FHD" that corresponds to 4K video support.

Actually, "FHD" is 1080 and the 4k is "UHD" - no?

Just in case, here is hackie :twisted::

model_no = createObject("roDeviceInfo").getModel()   
' 44xx = roku 4, 46xx = Palmieres, 5xxx = HD RokuTV, 6xxx = UHD RokuTV '
i_can_haz_4k = model_no > "44" and left(model_no, 1) <> "5"

We have assumed any device that can support HEVC/VP9 will support 4K. If that is true, then this will work. Note you should wrap it with "FindMemberFunction".

if FindMemberFunction(device, "CanDecodeVideo") <> invalid then
    device = createObject("roDeviceInfo")
    supports4k = (device.CanDecodeVideo({codec: "hevc"}).result = true or device.CanDecodeVideo({codec: "vp9"}).result = true)
else
    ' fallback to model numbers since the current firmware doesn't support `CanDecodeVideo`
end if

You can also verify if the device is operating in 4k mode

device = createObject("roDeviceInfo")
is4k = (val(device.GetVideoMode()) = 2160)

Happy to know if there is a better way.

"EnTerr" wrote:
Actually, "FHD" is 1080 and the 4k is "UHD" - no?

Not in this case. Graphics resolution supporting FHD is synonymous with video resolution supporting 4K, at this time.

I don't recommend making tests based on model number, as that will not work right later if not sooner. 😉

"ljunkie" wrote:
We have assumed any device that can support HEVC/VP9 will support 4K.

That seems like a reasonable assumption.  You definitely need to make that as an 'OR' check though.

"RokuKC" wrote:

"EnTerr" wrote:
Actually, "FHD" is 1080 and the 4k is "UHD" - no?

Not in this case.  Graphics resolution supporting FHD is synonymous with video resolution supporting 4K, at this time.
I don't recommend making tests based on model number, as that will not work right later if not sooner.  :wink:

Um, wait... "everybody knows" that HD is 720, FHD is 1080 and UHD is 1920 vertically - are you saying that 3840x1920 gets mis-labeled as FHD?

If so, wouldn't checking for .height number be a better idea than the .name string? I mean, at least the number 1920 or 1080 should be correct, right?

And regarding checking by model# - no need to carve the recognized models in stone, could provision the app with a regex that decides based on model# (i.e. `createObject("roRegEx", is_4k_model_ptrn, "").isMatch(model_no)`). It requires some sophistication of periodic provisioning from central server - but for those who have done it for other reasons - okay, that's just another key for the JSON property bag and when the Co releases a new model, tweak a file on the server and stay merry. E.g. 

{..., is_4k_model: "^44", ... }
' oh noes, they released 4k model 6xxx, what we gonna do? ah okay: '
{..., is_4k_model: "^4[4-9]|^6", ... }

"EnTerr" wrote:
Actually, "FHD" is 1080 and the 4k is "UHD" - no?

Graphics resolution is separate than video resolution.
FHD UI support =~= 4K video support, at least until such time as a specific feature test will be provided (in addition to the roDeviceInfo CanDecodeVideo tests).

You can certainly check the other fields as you like, but checking name = "FHD" is sufficient for the foreseeable future.

No need for complicated model number regex matching... that will be just be an approximation, as well as a ongoing maintenance commitment.

"RokuKC" wrote:

"ljunkie" wrote:
We have assumed any device that can support HEVC/VP9 will support 4K.

That seems like a reasonable assumption.  You definitely need to make that as an 'OR' check though.

Yep, that's what I had in the quick code example.

if FindMemberFunction(device, "CanDecodeVideo") <> invalid then
    device = createObject("roDeviceInfo")
    supports4k = (device.CanDecodeVideo({codec: "hevc"}).result = true or device.CanDecodeVideo({codec: "vp9"}).result = true)
else
    ' fallback to model numbers since the current firmware doesn't support `CanDecodeVideo`
end if

And really, every 4k device should already support that function because they'd be on the new firmware, right!? 😉

"ljunkie" wrote:
And really, every 4k device should already support that function because they'd be on the new firmware, right!? 😉

Wait a minute, there is a problem in that line of thinking - 4k and HEVC are not equivalent? It's "falacy of the converse" along the lines of:

1. if you own a building, you can put your name on it


2. many buildings have "Trump" on them


3. therefore Trump owns all these buildings!

... which we know is not the case, since "Trump" is a brand licensed for a fee.

In the same way 4k player => H.265 (HEVC), sure.
Why do you assume HEVC => 4k ?
I would expect better compression methods would make it to FHD too. After all, from ergonomic point of view, 4k TVs are bogus (unlike HDR)...

"EnTerr" wrote:

"ljunkie" wrote:
And really, every 4k device should already support that function because they'd be on the new firmware, right!? 😉

Wait a minute, there is a problem in that line of thinking - 4k and HEVC are not equivalent? It's "falacy of the converse" along the lines of:

1. if you own a building, you can put your name on it


2. many buildings have "Trump" on them


3. therefore Trump owns all these buildings!

... which we know is not the case, since "Trump" is a brand licensed for a fee.

In the same way 4k player => H.265 (HEVC), sure.
Why do you assume HEVC => 4k ?
I would expect better compression methods would make it to FHD too. After all, from ergonomic point of view, 4k TVs are bogus (unlike HDR)...

Yeah, I understand your reasoning. This just goes to show there is no fool proof way to know if a device is 4k capable. The only way right now is to make an assumption that could be wrong in the future. Right now we know 4k requires HEVC/VP9 and the only Roku TVs/players that support HEVC/VP9 also support 4k. We also know (now) that any device supporting FHD also supports 4k.. but in reality that can all change with future devices. I'm not downplaying this at all - I hope we have a better method to obtain the capabilities.