Is there a sure-fire way right now to determine if someone is using a 4K capable Roku device? I know it’s the Roku 4+, but if in the future the model says Roku Ultra, or Roku 5, or Roku Streaming 4K Stick, etc… I’d have to account for that.
The getDisplayType() still shows HDTV as opposed to what one might think is UHDTV.
Any thoughts?
“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.
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:
if you own a building, you can put your name on it
many buildings have “Trump” on them
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:
if you own a building, you can put your name on it
many buildings have “Trump” on them
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.
“RokuKC” wrote:
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.
Oh i see. Did not realize you were exploiting a side effect.
That’s a real ugly kludge though. Do we have reasons to believe #3600 (new stick), #37xx (Espressos) and #42xx will not be getting the 1080 “graphics resolution”?
No need for complicated model number regex matching… that will be just be an approximation, as well as a ongoing maintenance commitment.
Aha! I see where your bias lies - you are thinking like a person which never had to go through the RokuCo’s “channel approval process”. You are thinking “it’s so trivial to change your code and publish new version right away”. That is not the case in reality though! The review process is slow, occasionally with bogus fix requests - and to top it off, sometimes the publishing at the end gets fracked up. I have experienced all 3 - and i bet you have experienced none of that, because you can just zip, upload and be done. We mere mortals can’t though. I have had to wait months for a mere bundle signature, before can even upload for review. Months!!
If you were to put yourself in my shoes - would you rather do a “maintenance commitment” to edit text file on a server when new model gets released - or would you rather go through the proper “channel publishing process” after new firmware unannouncedly breaks the check? As a reminder, the former will take 1 minute - the latter, between a week and months.
“EnTerr” wrote:
Do we have reasons to believe #3600 (new stick), #37xx (Espressos) and #42xx will not be getting the 1080 “graphics resolution”?
That is the case, as you can determine empirically.
Note that I can’t comment on anything future other than in a general sense, even if I knew about it.
I have had to wait months for a mere bundle signature, before can even upload for review. Months!!
I hear your painand you should definitely talk to the developer support staff and developer evangelists about this issue, if it is ongoing.
From what I’ve heard, there shouldn’t be any such delays (more than a few days at most) in modern times.
If that’s not the case, I will happily relay that feedback and try to find out the issue.
If you were to put yourself in my shoes - would you rather do a “maintenance commitment” to edit text file on a server when new model gets released - or would you rather go through the proper “channel publishing process” after new firmware unannouncedly breaks the check? As a reminder, the former will take 1 minute - the latter, between a week and months.
Again, while I understand your approach and commitment, it’s not what I would personally do or recommend for any general developers.
I expect you participate in the firmware beta release program, so in the (hopefully rare) cases where backward-incompatible changes are found, those can be reported and dealt with in a reasonable fashion.
Hey guys - i just ran into some example code by the Co on detecting UHD!
Guess where it’s strategically hidden? Right here
https://sdkdocs.roku.com/display/sdkdoc … eckExample
