[Bug]: QVBR/HQVBR, quality and rate options seem ignored

[markg85]

Describe the bug
Setting bitrate options or even -qvbr_quality_level 51 (the worst possible quality) seems completely ignored.

To Reproduce
This is the ffmpeg git build!

LD_LIBRARY_PATH=/home/mark/pkgbuilds/ffmpeg/upstream/build/lib \
./ffmpeg -hwaccel amf -hwaccel_device /dev/dri/renderD128 -init_hw_device amf=/dev/dri/renderD128 \
    -y -i ~/Videos/eso1706c.avi \
    -c:v hevc_amf \
    -usage high_quality \
    -rc qvbr \
    -qvbr_quality_level 51 \
    -minrate 1M \
    -maxrate 10M \
    -quality quality \
    -preset quality \
    -profile:v main10 \
    -profile_tier high \
    -preanalysis 1 -enforce_hrd 1 -filler_data 1 \
    -pix_fmt nv12 \
    -b:v 5M \
    -f matroska test.mkv

The video i'm trying this on (warning 2GB, 4k)!: https://cdn.eso.org/videos/ultra_hd_h265/eso1706c.mp4

Setup (please complete the following information):

• OS: Linux
• Driver Version: Current Git of this repo
• GPU: 7900 XT
• Which component has the issue: Encoder
• Using ffmpeg Git (no custom patches)

Debug Log (please upload or paste):
No errors or warnings

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
N/A

Additional context
I tried various options to force bitrates. The -enforce_hrd 1 -filler_data 1 comes from another hint in another bug, it seems to not help at all.

Also, as an aside. Try the encoding line! Then look at the result. The video jumps back and forth! As this is a planetary illustration, it's easier to explain :) The planets jump back and forth in their orbit. That's not in the source! And that's not the case if you'd encode it with, say, vbr_peak. The rate issue is the one i'm reporting here but there is another issue hidden in this too.

[MikhailAMD]

We tried your video clip and found that "-qvbr_quality_level 51" produces highest quality and "-qvbr_quality_level 1" produces lowest quality. If you see the issue (no effect), please provide output clips to compare and the method you compare them.

[markg85]

Hi Mikhail,

That level is confusing. In other encoder settings higher is often worse not better. For example a crf of 51 is as bad as you can get while a crf of 1 is essentially lossless.

Anyhow, i uploaded two files here: https://limewire.com/d/1fce0ed7-de45-4597-829c-afd1840f5da4#SBJk45nsWOC6LdglDKOmqHhlwwT8Q2LvdOemixi2XKQ

• test_qvbr_1.mkv with -qvbr_quality_level 1
• test_qvbr_51.mkv with -qvbr_quality_level 51

The command is otherwise exactly the same as provided in my first post.

Observations:

• test_qvbr_1.mkv is bigger (143MB vs 138MB for test_qvbr_51.mkv) which makes no sense if 1 is bad and 51 is great quality
• Neither follows the bitrate limitations

While encoding, both did say:

  Stream #0:0: Video: hevc, nv12(tv, progressive), 3840x2160, q=2-31, 5000 kb/s, 25 fps, 1k tbn
    Metadata:
      encoder         : Lavc61.33.102 hevc_amf
[hevc_amf @ 0x5714996cd900] Data acquired but delayed SubmitInput returned AMF_INPUT_FULL- should not happen

Emphasis on the 5000 kb/s which isn't what i'm seeing in the resulting video (it would've been around 1MB if it had followed the bitrate limits).

I am playing the video with mpv (and ffplay). Both videos that i uploaded show the jumping effect too.

[markg85]

I debugged the bitrate part of the issue a little, it's puzzling.

I'm trying it with qvbr and vbr_peak (explicitly trying vbr_peak because it seems to follow contraints). Note that with vbr_peak i also disable preanalysis.

I do see the bitrate settings being applied in both modes into AMF. The relevant logging:

0125-01-20 17:06:31 A11FB6C0 [AMFEncoderCoreHevc]   Debug: SetProperty TL0.QL0.HevcPeakBitrate:10000000
[AVHWDeviceContext @ 0x75008d7e9300] AMFEncoderCoreHevc: 0125-01-20 17:06:31 A11FB6C0 [AMFEncoderCoreHevc]   Debug: SetProperty TL0.QL0.HevcPeakBitrate:10000000
0125-01-20 17:06:31 A11FB6C0 [AMFEncoderCoreHevc]   Debug: SetProperty TL0.QL0.HevcTargetBitrate:5000000
[AVHWDeviceContext @ 0x75008d7e9300] AMFEncoderCoreHevc: 0125-01-20 17:06:31 A11FB6C0 [AMFEncoderCoreHevc]   Debug: SetProperty TL0.QL0.HevcTargetBitrate:5000000
0125-01-20 17:06:31 A11FB6C0 [AMFEncoderCoreHevc]   Debug: SetProperty TL0.QL0.HevcVBVBufferSize:5000000
[AVHWDeviceContext @ 0x75008d7e9300] AMFEncoderCoreHevc: 0125-01-20 17:06:31 A11FB6C0 [AMFEncoderCoreHevc]   Debug: SetProperty TL0.QL0.HevcVBVBufferSize:5000000

Which leads me to think that the bitrate is set in both modes but something somewhere nullifies that setting with qvbr?...

[Sinfull-snake]

Hello @markg85 just another AMF user on the internet but I believe your uncontrollable bitrate issue stems from the AMF_VIDEO_ENCODER_PREENCODE_ENABLED setting that is set to True when using USAGE HIGH-QUALITY paired with any of the High Quality rate control methods (HQCBR, HQVBR and in your case QVBR.)

When AMF_VIDEO_ENCODER_PREENCODE_ENABLED is set to true for me in OBS with HQCBR the bitrate becomes uncontrollable even with FillerData and HRD set to true. So I would suggest using USAGE TRANSCODE instead to have AMF_VIDEO_ENCODER_PREENCODE_ENABLED set to False by default.

The HQ rate control methods and AMF_VIDEO_ENCODER_PREENCODE_ENABLED pairing have been a problem for a while but I hope this helps and maybe the AMF team can confirm or repro this issue.

[markg85]

Hi @Sinfull-snake! Thank you for your hints, that's much appreciated!

My case here is slightly different then OBS usage (i assume you use it for streaming?). For streaming VBR_PEAK seems to be awesome.

My case here in this issue is archive encoding. I know the results x265 can get but it's slow. So i'm now trying to approach those results on AMF as close as i can in terms of quality while remaining within the ballpark size of x265. QVBR probably isn't even the one i need here, based on the docs i think HQVBR is probably best but that just gives the same problem as reported.

In my case that 5Mbit is nonsense but it serves the purpose of demonstrating a bug.

[Feng-AMD]

1. Please refer to "https://github.com/GPUOpen-LibrariesAndSDKs/AMF/wiki/Rate%20Control%20Methods" for the explanation of of how AMF QVBR mode works - In QVBR mode, the file size is purely decided by the set quality level and the complexity of the video. In other word, any bitrate related values set by users will be ignored in QVBR mode.
2. AMF QVBR mode follows the common sense that the higher the quality level, the better the quality. This is different from CRF of x264/5.
3. The provided test video "https://cdn.eso.org/videos/ultra_hd_h265/eso1706c.mp4", is not the same as the one you used in your command line, "eso1706c.avi". If you could provide a link to that video, I can repeat your test to verify your result of Level 1 and Level 51.

Let me know and I am happy to help.

[markg85]

Hi @Feng-AMD

Interesting, i must have copied the wrong link.

Here is the correct link: https://cdn.eso.org/videos/ultra_hd_broadcast/eso1706c.avi and if that doesn't work as direct link, then go to it's page (here) and download the "4K Ultra HD Broadcast" one.

For clarity, the ffprobe on my local file:

❯ ffprobe ~/Videos/eso1706c.avi
ffprobe version n7.1 Copyright (c) 2007-2024 the FFmpeg developers
  built with gcc 14.2.1 (GCC) 20240910
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.100 / 61. 19.100
  libavformat    61.  7.100 / 61.  7.100
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  4.100 / 10.  4.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
Input #0, avi, from '/home/mark/Videos/eso1706c.avi':
  Metadata:
    date            : 2017-02-16T13:00:48.0036
    software        : Adobe After Effects CC 2017 (Windows)
  Duration: 00:00:26.24, start: 0.000000, bitrate: 648060 kb/s
  Stream #0:0: Video: hqx (CHQX / 0x58514843), yuv422p16le(10 bpc), 3840x2160, 649039 kb/s, 25 fps, 25 tbr, 25 tbn

And on that file i linked to:

❯ ffprobe https://cdn.eso.org/videos/ultra_hd_broadcast/eso1706c.avi
ffprobe version n7.1 Copyright (c) 2007-2024 the FFmpeg developers
  built with gcc 14.2.1 (GCC) 20240910
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable-shared --enable-vapoursynth --enable-version3 --enable-vulkan
  libavutil      59. 39.100 / 59. 39.100
  libavcodec     61. 19.100 / 61. 19.100
  libavformat    61.  7.100 / 61.  7.100
  libavdevice    61.  3.100 / 61.  3.100
  libavfilter    10.  4.100 / 10.  4.100
  libswscale      8.  3.100 /  8.  3.100
  libswresample   5.  3.100 /  5.  3.100
  libpostproc    58.  3.100 / 58.  3.100
Input #0, avi, from 'https://cdn.eso.org/videos/ultra_hd_broadcast/eso1706c.avi':
  Metadata:
    date            : 2017-02-16T13:00:48.0036
    software        : Adobe After Effects CC 2017 (Windows)
  Duration: 00:00:26.24, start: 0.000000, bitrate: 648060 kb/s
  Stream #0:0: Video: hqx (CHQX / 0x58514843), yuv422p16le(10 bpc), 3840x2160, 649039 kb/s, 25 fps, 25 tbr, 25 tbn

Thank you for pointing out that wiki page, that's very helpful! QVBR might indeed be the wrong testcase for me. But HQVBR does seem to be the proper one, as it's described as:

HQ-VBR aims at improving perceptual quality by producing the constant perceptual quality close to target bitrate. To guarantee the minimum perceptual quality, and to avoid wasting bit budget, the bitrate accuracy at extremely low/high target bitrate will be reduced.

I just tested that statement and i can, sadly, confirm that the bitrate is not adhered to in HQVBR either. The command is exactly the same as my initial command here only qvbr replaced with hqvbr.

[markg85]

Note that the wiki states (for HQVBR: its peak bitrate is constrained by PEAK_BITRATE).
Also note that my command includes a -maxrate 10M

Which in the ffmpeg amf codebase is, probably, is used:

    if (avctx->rc_max_rate) {
        AMF_ASSIGN_PROPERTY_INT64(res, ctx->encoder, AMF_VIDEO_ENCODER_HEVC_PEAK_BITRATE, avctx->rc_max_rate);
    } else if (ctx->rate_control_mode == AMF_VIDEO_ENCODER_HEVC_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VBR) {
        av_log(ctx, AV_LOG_DEBUG, "rate control mode is vbr_peak but max_rate is not set, default max_rate will be applied.\n");
    }

I say probably because i reverted to ffmpeg master which has amf logging disabled. It would crash in these modes where preanalysis is enabled, which is in hqvbr. So my verifying abilities are a bit reduced here.

[Feng-AMD]

As stated in the document "https://github.com/GPUOpen-LibrariesAndSDKs/AMF/wiki/Rate%20Control%20Methods", in HQVBR mode, "To guarantee the minimum perceptual quality, and to avoid wasting bit budget, the bitrate accuracy at extremely low/high target bitrate will be reduced."

In 4k video encoding, bitrate of 5Mbps is just too low to have a decent quality. That is why you can't get the target bitrate as you expect if rc is HQVBR.

If your app is sensitive to bitrate accuracy, I suggest that you choose PCVBR.

[markg85]

@Feng-AMD Could you be so kind to explain that?

The docs make you think that it's output can be controlled in terms of bitrate. If that isn't the case then it would be beyond super helpful to update the docs to reflect reality.

I also tried using 20Mbit, that is enough for 4k, still it AMF just seems to ignore it and shoot for around 40-60Mbit.

What use is there for QVBR and HQVBR at all if you can't steer it's output size in a certain direction. It certainly isn't good for archiving as AMF simply, objectively, isn't as good as x265 (it's advantage is speed, not quality). With x265 you would get both a higher quality and a much smaller size downside is that the encoding takes a few days...

Also, PCVBR doesn't exist in ffmpeg. Do you have a patch for me to try?