Video Encode API: Ability to specify input Color Profile and Color Range

[Xaymar]

Right now, there seems to be no way to tell AMF/VCE what the input color profile and range actually is. This leads to darker recordings with colors that don't match the input.

Video Converter seems to already have a parameter to define the profile called 'AMF_VIDEO_CONVERTER_COLOR_PROFILE'.

Edit: The default now seems to be Partial .701 instead of Partial .609.

[MikhailAMD]

Encoder run the same video converter for convenience only. Converter default profile is based on resolution. You can use the converter separately if you want to customize profile. AMD

[Xaymar]

If I understood you correctly then in order to get true color output I need to have a Video Converter component executed before the Video Encode component?

[MikhailAMD]

Yes, if you want to control all settings of video converter you will have to create it and run separately. You will have to initialize encoder with NV12. Performance will be the same. You don't need threading for the converter. Just call: converter->SubmitInput() converter->QueryOutput() encoder->SubmitInput() Good luck, AMD

[Xaymar]

Hey @MikhailAMD, is there any possibility that we get to decide what the output format, color profile and color range is?
Right now it's locked to YUV 4:2:0 with Partial Color Range and unknown Color Profile (most likely .609).

[MikhailAMD]

The encoder works on 4:2:0 - there is no point to submit anything else. Color profile: Encoder has built-in AMF Video Converter component called if needed inside SubmitInput(). The default behaviour of the encoder is to enable 601 profile for SD resolution and 709 for HD resolution (height>=780). If you want full control please create instance of AMF Video Converter, program it accordingly and initialize Encoder with NV12 input. There is no need to put the converter in threads. converter->SubmitInput() converter->QueryOutput() encoder->SubmitInput()

[Xaymar]

What about Color Range? Right now it's locked at Partial, which makes stealth/sneaking games like Thief look awful.

[MikhailAMD]

Could you please be more specific? Currently converter does RGB 0-256 to YUV 4:2:0 conversion according to this: https://en.wikipedia.org/wiki/YUV 601 or 709

[Xaymar]

Could you please be more specific?

Of course. Shadows and Highlights are currently murdered by the encoder, since it for whatever reason decides to fully control everything by itself instead of leaving that up to the user. Here is an example: http://imgur.com/a/OdZd7 . Note that about 60% of the time in that game you'll be in the dark.

The encoder works on 4:2:0 - there is no point to submit anything else.

This here I find a strange decision. What about the people wanting the full color range? High Quality Recording? Near-Lossless? You just single-handedly shut everyone down that would have been interested in using the encoder for this. Especially for YouTube, lossless or near-lossless is the best that you can have - and that usually requires YUV 4:2:2, YUV 4:4:4 or straight up RGB output.

Encoder has built-in AMF Video Converter component called if needed inside SubmitInput(). The default behaviour of the encoder is to enable 601 profile for SD resolution and 709 for HD resolution (height>=780). If you want full control please create instance of AMF Video Converter, program it accordingly and initialize Encoder with NV12 input. There is no need to put the converter in threads.

I tried that but I still had no way to Control the Color Range. See the example above for what the encoder does to footage at the moment. Edit: I tried the RGBA to NV12 path, but nothing changed. The currently shipped runtime seems to not respect the proper colors.

[MikhailAMD]

I understand that image lost some details. But consider this:

1. VCE Hardware supports 4:2:0 only so there is no point to ask anything else from SDK
2. Original H.264 standard has 4:2:0. Extension 4:2:2 and 4:4:4were added later for extended resolution. They increase size of UV plane in pixels. They do not extend any color range. The conversion formula from RGB to YUV will be exactly the same.
3. Color space conversion formula from RGB to YUV does cut range of black and white colors by definition. from RGB 0-255 to 706 HD: luma (Y) range16-235 and chroma (UV) range - 16-240 . As you can see 16 grades of black and 20 grades of white will be lost.
4. Since H.264 is YUV loss codec not sure why we are talking about RGB and lossless output.
5. HEVC codec will provide more capabilities including HDR color space like 2020 which is probably what you are looking for.

[Xaymar]

1. Alright, I wasn't aware that the hardware didn't support more.
2. I'm fully aware of that. They still offer higher quality per pixel than what is currently offered, but see your first answer.
3. That is exactly what is called Color Range, the one AMF currently used is the Partial/TV range. There is also the Full Color Range, which is much preferred and almost standard today. Since YUV can represent all RGB values from 0 to 2^24 properly, could we get this here too? NVENC supports it for HEVC (not sure about h264), so could we get this for HEVC and hopefully h264 too? This alone would already help quality a lot.
4. Encoded footage is usually used either for streaming, further editing or uploading to videos sites, such as YouTube and Vimeo. Having near-lossless output would be preferred here.
5. Indeed, HEVC is what I'm more interested in for the future, including the Two Pass Encoding we will hopefully get before Vega hits the market.

[MikhailAMD]

All right, we are on the same page. I will consider adding more color space conversion options for the next release since there more variants then 601 and 706. HEVC encoder is available in Polaris, stay tuned for the AMF SDK. Near lossless variant of codec would be entirely different one from supported H.264 or HEVC or you can try to force I-frame on each frame and / or maximize bit rate.

[Keridos]

Would it not be possible to hardware accelerate just a part of the x264 and do the rest on cpu to get the color formats like rgb in the output?

[Xaymar]

I have a question concerning the Wikipedia page you linked me to in #18, @MikhailAMD. It states that starting with VCE 2.0 YUV 4:4:4 I-Frames are supported. Is there any way I can force this behavior or is it just something that happens automatically/at random?

[MikhailAMD]

This line in Wiki is inaccurate. Currently VCE does not support 4:4:4 and I don't see how it is possible to do just for I-frames because it should be a different profile.

[Xaymar]

I will close this for tracking purposes as I forgot to do so earlier. Thanks for your time, the question has been answered.

[Selur]

Does the current API support signaling HDR for HEVC? If not, will this come in the future?

[MikhailAMD]

HEVC API was not published yet. Will be done as soon as we fix one bug in the driver. Then we can discuss features.