You do have PlayReady 3.0 Support., as this is what Windows 10 uses for HDR and WCG.
(which is great if you're Display also supports the DTB Standard for HDR/WCG, as opposed to just Natively providing such... there's another thread about this on the Radeon Pro Series GPU... the issue with such is Half AMD and Half Microsoft fault., which given neither of them seem to talk to each other directly is infuriating, to say the least)
As noted the issue at play here, essentially comes down to Netflix using the Intel and NVIDIA Encoder APIs... but not AMD's AMF API.
It's not uncommon for this to happen either.
In a way, I don't blame a lot of Studios for not supporting AMD SDKs...
AMD isn't really doing much in the way to get more of their Hardware IN to Development Studios.
Sure, they have their Workstation (Radeon Pro) Hardware ... but they don't really have any Prosumer Hardware., not unless you count the Radeon VII, which is in such short supply it might as well be Faery Dust.
GPU Open, while it was a good step in the right Direction when it was launched., but has become so infrequently updated with the UX being honestly very bare bones.
Look at it this way, Navigation is "Pretty" but not very Intuitive... there's a basic Blog-Style Comments Section, but no real way to properly discuss with other Developers outside of coming on the forums (which again aren't exactly intuitive) or discussing directly on GitHub.
Then there's the fact that basically, each Article is little more than a Brief Description with GitHub Links., there's no MSDN Style Reference System.
Intel and NVIDIA both have these... I mean they're bare bones, unlike Microsofts' which are frankly the Gold Standard for such; but AMD literally has NONE. You get the Source Code, and maybe a few Samples; beyond that, well it's basically "Figure it out on your own"., which is fine for Developers like myself who are going to extensively use and alter the source in order to have a fully-custom variant of their Open Source API / Libraries in our Projects; but for those who just want to "Plug-and-Play" Support., yeah; that's a BAD approach.
Getting back to how infrequently said Update appear., well again the issue here is that there's basically no reason for Developers to keep it bookmarked or keep coming back to the site (which is as a note NO LONGER listed in the Developer.AMD.com area of their Website, so now it just looks like AMD simply no longer have any GPU SDK / Libraries / Tools, heck all of the things listed on the Developer area of their Website are basically Linux SDK / Buildchain Tools for the AMD64 Platform; that's basically it).
Where-as what you want are Developers constantly coming back, not just for Regular SDK / Library / Tool Updates; but also for Whitepapers, Blog Posts on "Best Practises", etc. You want a community to engage with your Products, well you HAVE to engage with that Community to showcase that you haven't abandoned them... it's a two-way street.
And I mean ... a great example of this was we saw from various AAA Developers that AMD was working with them on Tress FX 4.0 for almost 12 months BEFORE Tress FX 3.1 was replaced with it.
What we should've seen instead was the Tress FX 4.0 (Alpha) and (Beta) available along-side the 3.1 (Release).
The same was true in regards to how, they've STILL not updated their Entire Litany of Tools / Libraries / API to use DirectX 12., let alone any Vulkan versions... yet all of the "Optimisation" Blogs they've put out have been focused on Vulkan, none for DirectX 12 (yes, I know they're basically very similar; but it doesn't hurt to list it as DirectX 12 / Vulkan with little nodes to the differences); and well we're also talking about their GCN Architecture being better suited to the Low-Level APUs., so WHY?! wasn't everything DirectX 12 to begin with, THEN later supporting DirectX 11.2/11.3/11.4?
Intel / NVIDIA / AMD... none of them have Full DirectX 12 / Vulkan SDK., nor does AMD have quite the same range of Plug-and-Play Tools; with many like for example PlayReady 3.0 Supoprt., basically being little more than a Bullet Point for the AMF ... but you can only get away with that IF said API is an established Industry Standard; which the AMD API just aren't.
