h264_amf encoder: target bitrate increase results in real bitrate decrease

[Marina]

Summary of the bug:

I performed convertations with different bitrates using AMF encoder (Radeon RX 560, 24.20.13017.1009 driver version)

% ffmpeg.exe -i <input_file> -b:v 30M -c:v h264_amf test_30.mp4
% ffmpeg.exe -i <input_file> -b:v 45M -c:v h264_amf test_45.mp4
% ffmpeg.exe -i <input_file> -b:v 72M -c:v h264_amf test_72.mp4

The bitrate in results files (from ffprobe output, mediainfo gives same values):
test_30.mp4 - bitrate: 29765 kb/s
test_45.mp4 - bitrate: 5474 kb/s - artifacts
test_72.mp4 - bitrate: 3693 kb/s - artifacts

Before 30 Mbps there is no problem. The boundary after that real bitrate decrease depends on frame resolution and FPS.

ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 8.2.1 (GCC) 20181017
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
libavutil      56. 22.100 / 56. 22.100
libavcodec     58. 35.100 / 58. 35.100
libavformat    58. 20.100 / 58. 20.100
libavdevice    58.  5.100 / 58.  5.100
libavfilter     7. 40.101 /  7. 40.101
libswscale      5.  3.100 /  5.  3.100
libswresample   3.  3.100 /  3.  3.100
libpostproc    55.  3.100 / 55.  3.100

Full ffprobe output for one of test files

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test_30.mp4':
Metadata:
  major_brand     : isom
  minor_version   : 512
  compatible_brands: isomiso2avc1mp41
  encoder         : Lavf58.20.100
Duration: 00:03:44.35, start: 0.000000, bitrate: 29765 kb/s
  Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv), 1280x720 [SAR 1:1 DAR 16:9], 29639 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)
  Metadata:
    handler_name    : ISO Media file produced by Google Inc. Created on: 02/08/2018.
  Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s (default)
  Metadata:
    handler_name    : ISO Media file produced by Google Inc. Created on: 02/08/2018.

[Marina]

There is no dependence on input file.
I used ​this

[Carl Eugen Hoyos]

Why do think there is an issue that can be fixed in FFmpeg?

[Marina]

Replying to cehoyos:

Why do think there is an issue that can be fixed in FFmpeg?

Why I should not think so? There can be mistake in amf API usage.

[Carl Eugen Hoyos]

Bugs are possible, I wonder if it is really more likely that AMD made a mistake using their api than a general amf bug.

Please test current FFmpeg git head to make this a valid ticket.