[FFmpeg-trac] #10389(undetermined:new): av1_amf ignores most quality/bitrate settings except for b:v
FFmpeg
trac at avcodec.org
Mon May 29 19:32:43 EEST 2023
#10389: av1_amf ignores most quality/bitrate settings except for b:v
-------------------------------------+-------------------------------------
Reporter: alraz | Type: defect
Status: new | Priority: normal
Component: | Version:
undetermined | unspecified
Keywords: av1_amf, | Blocked By:
av1, amd |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
hello everyone
I'm new here. This is my first bug report, so, please bear with me if I
missed anything here :)
Trying my best.
Summary of the bug:
Been trying to re-encode a bunch of existing mkv files I have that I
created with OBS using H.264 VBR settings to AV1 using AMD's hardware
encoder.
The encoder seems to ignore all of the following settings:
{{{
-cq
-qp
-crf
-qscale
-minrate
-maxrate
}}}
No matter which combination of the above settings I use, the codec will
always use a bitrate of about 2 mbps and the console will always show a
"q" value of "-0.0". I tried using all the settings on their own as wall a
several possible combinations of only a few of them, most of them, etc. as
well as different quality values for each of them, but nothing seems to
make any difference.
Example:
{{{
ffmpeg -i "2023-05-27_17-53-42.mkv" -map 0 -c:v av1_amf -preset 0
-bufsize 192M -cq 17 -qp 17 -crf 17 -qscale 17 -minrate 15000k -maxrate
35000k -f mp4 -y "h265/2023-05-27_17-53-42.mp4"
[...]
frame= 495 fps= 54 q=-0.0 Lsize= 2480kB time=00:00:08.36
bitrate=2429.2kbits/s speed=0.919x
}}}
However, if I specify a target bitrate with "b:v", then the encoder will
ignore all other settings and encode using only that target bitrate.
Example:
{{{
ffmpeg -i "2023-05-27_17-53-42.mkv" -map 0 -c:v av1_amf -b:v 15000k
-preset 0 -qp 17 -minrate 15000k -maxrate 35000k -f mp4 -y
"h265/2023-05-27_17-53-42.mp4"
[...]
frame= 677 fps= 65 q=-0.0 Lsize= 20876kB time=00:00:11.41
bitrate=14983.7kbits/s speed= 1.1x
}}}
More interestingly, the resulting file will be the exact same size
regardless of what combination of settings I use. The only thing that
seems to matter is whether or not I use "b:v".
This does not happen when I use another codec that doesn't use AMD
hardware. Example:
{{{
ffmpeg -i "2023-05-27_17-53-42.mkv" -map 0 -c:v libx264 -preset 0
-bufsize 192M -cq 17 -qp 17 -crf 17 -qscale 17 -minrate 15000k -maxrate
35000k -f mp4 -y "h265/2023-05-27_17-53-42.mp4"
[...]
frame= 401 fps= 52 q=23.0 size= 33792kB time=00:00:07.87
bitrate=35165.7kbits/s speed=1.03x
}}}
Notice that the "q" value is positive (though not exactly what I
specified) and the bitrate is somewhat between the range specified.
If it helps: I noticed that the "-quality" setting DOES seem to be
considered by the encoder: with higher settings, it is significantly
slower and the resulting file is slightly bigger. I have not been able to
evaluate if the video quality is actually any better, but I have no reason
to assume it is not given the symptoms are what's expected for this
setting.
My ffmpeg version:
{{{
B:\capture>ffmpeg -version
ffmpeg version N-110789-g8d662adcc9-20230527 Copyright (c) 2000-2023 the
FFmpeg developers
built with gcc 12.2.0 (crosstool-NG 1.25.0.152_89671bf)
configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-
config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64
--target-os=mingw32 --enable-gpl --enable-version3 --disable-debug
--disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2
--enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp
--enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl
--disable-libpulse --enable-libvmaf --disable-libxcb --disable-xlib
--enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth
--enable-chromaprint --enable-libdav1d --enable-libdavs2 --disable-libfdk-
aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme
--enable-libkvazaar --enable-libass --enable-libbluray --enable-libjxl
--enable-libmp3lame --enable-libopus --enable-librist --enable-libssh
--enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2
--disable-libmfx --enable-libvpl --enable-openal --enable-libopencore-
amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg
--enable-libopenmpt --enable-librav1e --enable-librubberband --enable-
schannel --enable-sdl2 --enable-libsoxr --enable-libsrt --enable-libsvtav1
--enable-libtwolame --enable-libuavs3d --disable-libdrm --disable-vaapi
--enable-libvidstab --enable-vulkan --enable-libshaderc --enable-
libplacebo --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-
libxvid --enable-libzimg --enable-libzvbi --extra-
cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pthread
--extra-ldexeflags= --extra-libs=-lgomp --extra-version=20230527
libavutil 58. 9.100 / 58. 9.100
libavcodec 60. 14.101 / 60. 14.101
libavformat 60. 5.100 / 60. 5.100
libavdevice 60. 2.100 / 60. 2.100
libavfilter 9. 8.101 / 9. 8.101
libswscale 7. 2.100 / 7. 2.100
libswresample 4. 11.100 / 4. 11.100
libpostproc 57. 2.100 / 57. 2.100
}}}
Patches should be submitted to the ffmpeg-devel mailing list and not this
bug tracker (leaving this note here because it came as part of the
template).
--
Ticket URL: <https://trac.ffmpeg.org/ticket/10389>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list