Bug #6228
openh264_vaapi parameter 'quality' is not used properly
0%
Description
Reviewing the code related to vaapi I think I found a parameter that is mapped wrong.
The problem is in src/transcoding/codec/codecs/lib/vaapi.c
Based on description from tvh webpage (and form source code) 'quality' is an integer value between 0 and 8 that is used for Quality vs. Speed trade-off. See attachment for details.
If I understand the code, this value is passed to ffmpeg on line: 229 as "quality INT"
AV_DICT_SET_INT(opts, "quality", self->quality, 0);
Looking add ffmpeg documentation I see some conflict information:
https://ffmpeg.org/ffmpeg-codecs.html
9.14.8 Options
-compression_level integer
For lossy, this is a quality/speed tradeoff. Higher values give better quality for a given size at the cost of increased encoding time. For lossless, this is a size/speed tradeoff. Higher values give smaller size at the cost of increased encoding time. More specifically, it controls the number of extra algorithms and compression tools used, and varies the combination of these tools. This maps to the method option in libwebp. The valid range is 0 to 6. Default is 4.
-quality float
For lossy encoding, this controls image quality. For lossless encoding, this controls the effort and time spent in compression. Range is 0 to 100. Default is 75.
another source of info:
https://trac.ffmpeg.org/wiki/Hardware/VAAPI
There is no complete analogue of the -preset option. The -compression_level option controls the local speed/quality tradeoff in the encoder (that is, the amount of effort expended on trying to get the best results from local choices like motion estimation and mode decision), using a nebulous per-device scale. The argument is a small integer, from 1 up to some limit dependent on the device (not more than 7) - higher values are faster / lower stream quality. Separately, some hardware (Intel gen9) supports a low-power mode with more restricted features. It is accessible via the -low_power option.
Problems:
1. I think the ffmpeg parameter is compression_level (not quality)
2. Higher value is higher quality or lower quality? is not clear for me.
3. Valid range is 0 to 6 in one document and 1 to 7 in the other ... anyway is different from the source code (0 to 8). What should be the right range?
Files