Can we expect a SDK update with the ReLive driver release?

[Xaymar]

Basically what the title says. People have been asking for HEVC and Two Pass support for a while, and the ReLive driver launch seems to promise exactly that support - at least for the recording tool inside Radeon Settings.

[MikhailAMD]

Next hot fix. Unexpected problem that was not fixed in time for this release. :(

[Xaymar]

Aw, well we'll be waiting. If AMDs HEVC implementation is anywhere close to x265, then great days are coming.

[Xaymar]

Can I safely assume that we won't get the SDK update before 2017?

[MikhailAMD]

I cannot publish the sdk till the bug in the driver is fixed. I am pushing but yes 2016 is past now. Mikhail

[oscarbg]

Catalyst 16.12.2 has the needed fix?

[MikhailAMD]

The fix does not exist yet. Mikhail

[Roph]

Slightly related @MikhailAMD, have you tried A's Video Convertor (beta version) that's allowing early HEVC encoding with VCE? What do you make of it? Is it indicative of the best VCE can offer for HEVC, or can we expect more with the AMF HEVC SDK?

[MikhailAMD]

Hi,
We did not publish or provide C++ AMF HEVC encoder API to anyone yet. They may use it undocumented or they could use AMD HEVC encoder MFT that is provided with the driver and works according to Microsoft's spec for HEVC Encoder MFTs. you can find ICodecAPI parameters for it on MSDN.
Word of caution: the MFT uses the same AMF code and driver and may produce the same bugs. Also while it is possible to write an effective client application which uses MFTs it is a sizeable task which requires dealing with many quirks of Media Foundation. This is one of the main reasons why AMF does exist.

[Roph]

Is it likely that we can squeeze greater HEVC quality from VCE via AMF vs MFT? If you still occasionally lurk that videohelp thread, there's a lot of testing going on.

[MikhailAMD]

Quality does not depend on API to access HW. I've read the thread. It looks like they use undocumented access via AMF. Once SDK published we could use AMF TranscodeHW to play with parameters and compare quality and performance.

[Roph]

Sure, I was more meaning things like exposing extra parameters etc via AMF that may not be accessible (or just used) via MFT. Things like 2-pass, which I'm assuming isn't used by the MFT transcoder.

I was surprised to see kepler's NVENC (first generation) beating polaris at 5mbit/s H.264 on that 1080p50 sample, though with A's MFT convertor there is no way to enable 2-pass support; I'm assuming it's not utilized.

Just wondering if at this point without the new AMF / software using it, it may be misguided to make samples / comparisons etc.

[and this is a longshot; any tidbits on vega's VCE improvements? :) It's ~technically somewhat available already in the form of that workstation/compute card, no?]

[MikhailAMD]

2-pass - not full but pre-analysis was announced and is coming with the AMF update that was delayed due to the bug. It is a new feature and is not used in MFT.
Comparison between encoders is meaningless without knowing exact set of parameters used: not application parameters but API parameters. Xaymar and other developers spent a lot of time fine-tuning them for specific use cases. And different cases need different parameter set: synthetic vs natural scene, fast picture changes vs constant bitrate etc. etc.
To compare I would recommend to work on transcode scenario using AMF and NV/Intel native SDKs in a simple app or apps. For AMF it would be TranscodeHW. It will make sense to do after AMF release ( few changes in sample and HEVC will help).
VEGA - I am not authorized to comment non-released HW and / or SW, sorry.