To be clear my Z840 and I7-6700 machine at home can play 8K software decoded content :) So I think the standard MediaCaps approach for this is fine, I wouldn't recommend special casing this.

It can* play but can we mark this playback as "smooth" & "powerEfficient"?

re: comment 2, I would expect smooth = true, power_efficient = false.

Agree with Dale, the "learned" approach should work well here. 

We don't currently know what the HW decoder advertises. There are some OS APIs that we could call, but we still won't know the SW decoding capabilities until they try it. A while back I attempted to find some heuristics for guessing at what a CPU could do in SW (e.g. # of cores, clock speed), but these don't work well.

Closing per previous comments.

For my own knowledge, I thought "Video Acceleration Information" featured in about:gpu (introduced by https://chromium.googlesource.com/chromium/src/+/f4d324a8e8ed5f1c8f4d19431ebb14dea2acf983%5E%21/#F0) were giving HW limitations. Isn't that what it is?

Yes, you've got it right. I should narrow my previous claims from "we don't know" to "media capabilities doesn't know". 

That info is used when we select a a decoder during playback. Historically the claims of profile and resolution support have been a mix of what the OS APIs tell us alongside really broad hardcoded claims for the vpx codecs. I just took a peak at the latest state of things in dxva_video_decode_accelerator and it seems we're now calling some new APIs, so this is maybe more accurate today. 

Still we don't have much use for this in media capabilities because the limits of hw acceleration aren't a good heuristic for the limits of sw decode. 

We could use this to pre-populate some parts of the database (make some initial claims about what would be poewr-efficient), but _at this point_ it looks like a lot of plumbing code for not much return.