Opened 10 months ago

Last modified 3 months ago

#10444 new enhancement

Please implement VAAPI encoding enhancement for AMD / radeonsi (from MESA 22.3)

Reported by: Robert Horstmann Owned by:
Priority: wish Component: ffmpeg
Version: git-master Keywords: vaapi mesa encoding quality
Cc: Robert Horstmann Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Would you please check if those changes in MESA can be made usable in FFMPEG, to improve encoding quality for VAAPI on radeonsi:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17994

https://www.phoronix.com/news/AMD-VA-Quality-Mesa-22.3

Thank you !

Change History (17)

comment:1 by haihao, 9 months ago

You may use the standard libavcodec option compression_level to set quality level for VAAPI encoders, see https://github.com/FFmpeg/FFmpeg/blob/master/doc/encoders.texi#L3912-L3915

comment:2 by Robert Horstmann, 9 months ago

Hello haihao, thank you for the hint.

I tested it, doesn't work at all. Any compression value lower than 32 (valid range 0-32) produces completely garbled output.

A setting of 32 is working, but it's the worst possible value, and seems to the default, so no need to specify it anyway.

From my understanding, the options mentioned in the mesa commit should be passed as explicit parameters to the driver, like "-vbaq 1" or "-preset quality"

If I am not mistaken, AMD's AMF implementation in FFMpeg uses comparable parameters, too.
However, AMF requires using amdgpu-pro on my Ubuntu system, and I don't want to do that.

Got rid of my Nvidia card because of proprietary drivers, don't want to do the same with AMD now.

comment:3 by haihao, 9 months ago

@Robert, According to the description in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17994, the va encoding quality_level interface is used in the mesa vaapi driver. In FFmpeg, option compression_level is implemented via the va encoding quality_level interface, so you should check how the quality level is defined in the mesa vaapi driver.


how: use va encoding quality_level interface, and provide
default value and encoding quality adjustment options,
so that users can finetune encoding quality and performance
from va quality interface.

comment:4 by Robert Horstmann, 9 months ago

@haihao, I am sorry, but I am just a user of FFmpeg, and I have no idea how to proceed with "so you should check how the quality level is defined in the mesa vaapi driver."

Could you please provide further information?

comment:5 by haihao, 9 months ago

According to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17994/diffs#260e7df404e8d4d20838180e763f208163bff4a4_345_355,
the level should be (vbaq_mode << 27 | pre_encode_mode << 28 | preset_mode << 29)

comment:6 by Robert Horstmann, 9 months ago

@haihao, sorry to bother you once more, but do you mean that I should pass a level value of 27 or 28 or 29 to the compression_level parameter ?

If so, that doesn't work, values < 32 produce corrupted output.

Could you maybe give me a CLI example on how to pass the values to FFMpeg ?

Thx

comment:7 by haihao, 9 months ago

@Robert, Sorry I made a mistake here, the level for this driver should be (vbaq_mode << 4 | pre_encode_mode << 3 | preset_mode << 1).

for example:
If you want to set vbaq_mode to 1, you should set -compression_level 16

comment:8 by Robert Horstmann, 9 months ago

@haihao Thanks again !
Unfortunately, it does not work ... -setting "-compression_level 16" causes garbled, defective video in the output mkv.

My command line qith compression_level 16:
/usr/local/bin/ffmpeg -vaapi_device /dev/dri/renderD128 -i "FILE0165.MOV" -vf format=nv12,hwupload -c:v hevc_vaapi -compression_level 16 -global_quality 32 -c:a copy -threads 0 -y 32_16_hevc.mkv

This command line provides proper output:
/usr/local/bin/ffmpeg -vaapi_device /dev/dri/renderD128 -i "FILE0165.MOV" -vf format=nv12,hwupload -c:v hevc_vaapi -compression_level 32 -global_quality 32 -c:a copy -threads 0 -y 32_32_hevc.mkv

I could share more data if you would like to investigate / troubleshoot.

KR,
Robert

comment:9 by Robert Horstmann, 8 months ago

I did a little bit of "trial and error" testing.

-compression_level 15 produces proper output, and encoding is slower than usual.
Subjective visual quality is slighty better, so I guess it actually toggles the quality parameters when using vaapi

comment:10 by Snowfall, 3 months ago

Has anybody new information in how to use vbaq, pre-encode and quality mode independently or together on AMD hardware / VA-API?
This should definitely been documented under https://trac.ffmpeg.org/wiki/Hardware/VAAPI.

I tried "-compression_level 16", which worked for me with vbr, but there is no feedback when running in debug mode. So I can't just try out different values to achieve anything.

Maybe change ticket component to 'documentation' and priority to 'minor'?

comment:11 by Robert Horstmann, 3 months ago

I also found it very difficult to find out if the compression_level setting actually did something or not.

There was no usable debug output, so I tried different settings for compression_level for a specific video file and compared the "frames per second" during the encoding.

Assuming that turning those options on, magically, via compression_level causes a slowdown of the encoding process (as it should improve quality at the expense of speed), I saw that using"-compression_level 15" was slower than other values.

It was just trial and error, honestly, and I have no way to confirm for sure that "15" is a reasonable setting to activate vbaq etc.

We are flying blind here ;-)

Compared to NVENC or Quicksync, VAAPI on FFMpeg is rather disappointing, in terms of options and documentation :-(

And it seems to get little to no attention from the Devs, according to the number of recent commits.

comment:12 by Snowfall, 3 months ago

I have reached out to AMD and got good feedback back. See https://trac.ffmpeg.org/wiki/Hardware/VAAPI, last passage under 'AMD / MESA'.

They also told me that additional features like pre-analysis and high_motion_quality_boost are being evaluated and could be added in the future.
This could close the gap to AMF and reach near NVENC levels, IMHO.

comment:13 by Robert Horstmann, 3 months ago

Hey, thanks a lot, this looks great !

I experimented a little bit with the settings, and found out that my GPU (Ryzen 5 5600G, so Vega) doesn't seem to support VBAQ.

Any compression level that enables VBAQ produces corrupted output on my system.

Just asking, if you have contacts at AMD, could you ask them to update the Wiki with more examples ?
For example, which value would be "quality preset + pre-encoding without VBAQ" ?

In any case, again, thanks :-)

comment:14 by Snowfall, 3 months ago

As stated in the Wiki, you need VCN, but your APU only has UVD.
VCN is RDNA1 and newer, so Ryzen 6000+ with a few exceptions...

The whole feature combination thingy is binary math with a little twist at the end:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17994/diffs#21d3248ae81f9ef9bebc99e617fcdaea163a6229
Which comes down to:
VBAQ=16, pre-encode=8, quality-preset=4, balanced-preset=2, speed-preset=0
And at the end set the validity bit (bit0) to 1.

For quality + pre-encoding without VBAQ:
4 (quality) + 8 (pre-encode) + 1 (validity bit) = 13

comment:15 by Robert Horstmann, 3 months ago

Good morning from Germany.

Thanks again ! I thought it was binary, but I didn't know about the validity bit.

I always thought that the 5700G had the same GPU as the 4700G, which is labelled "renoir"

vainfo: Driver version: Mesa Gallium driver 23.3.4 - kisak-mesa PPA for AMD Radeon Graphics (radeonsi, renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-15-generic)
vainfo: Supported profile and entrypoints

And "renoir" should come with VCN 2.0

https://www.x.org/wiki/RadeonFeature/#index10h2

comment:16 by Snowfall, 3 months ago

Ok, my bad. Your APU should be supported, I guess.

There is an issue regarding VBAQ open:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/10020
Are you using CQP rate control?

comment:17 by Robert Horstmann, 3 months ago

Yupp, I am hitting exactly that open issue.

With VBR rate control, compression_level 29, which enable VBAQ, produces proper output.

Note: See TracTickets for help on using tickets.