Bitrate issue when using Navi21 VCE in H265 mode.

[PMunkes]

As described in Handbrake #3447, the bitrate of an H.265 encoded video cannot be reduced below a certain Threshhold. This issue persists when building Handbrake with the newest AMF version.

[MikhailAMD]

It is hard to definitely answer but there is one possibility worth to explore: if content is unusually complex, there are situations when encoder cannot deliver the requested bitrate. For example, if one tries to encode frames with generated white noise, the bitrate would not be reached.

• To verify please use another clip with more simple data. The source bitrate doesn't matter, only complexity counts.
• Also you may want to share source and result clips - we can check the actual situation.
• Lastly, can you try to reproduce the problem with AMF TranscodeHW sample?

[PMunkes]

The source clip is a 17 second video from Minecraft, which is contained in this owncloud folder:
https://uni-muenster.sciebo.de/s/fVH52y7Fc54dFCw
The link is valid until Saturday, 06th of March.
This was shared with me by a Twitter user who first noticed the issue.
Besides the source clip source_500mbit_x264.m4v, there are two videos transcoded with VCE at 5MBit/s, one with h,264 and one with h.265. The file names should be self-explanatory.
VCE with H.264 will respect the target bit rate. I am well aware of the resulting poor quality of the H.264 clip, but this tradeoff should be left to the user.

I can try to test a different clip, but I would need to record it first.

I will test the AMF TranscodeHW sample, but I cannot promise to finish this test today.

[PMunkes]

I added some more samples, Relive-Sample-VCE265-5.5M.mp4 was directly recorded with Relive with H.265 at 5.5MBit/s.
So VCE H.265 can actually deal with this bandwidth at this visual complexity (again, the quality tradeoff should be left to the user, in my opinion).

[MikhailAMD]

I tried TranscodeHW AMF sample. It produces proper file sizes for HEVC and H264.

I tried ffmpeg 4.3.1: here is an issue: with simple command line I can reproduce the problem:

ffmpeg.exe -i source_500mbit_x264.m4v -c:v hevc_amf -quality speed -usage transcoding -rc vbr_peak -b:v 10M -bufsize 1M -maxrate 11M out_ffmpeg_hevc.mp4

But with this command line ffmpeg produces the correct file:

ffmpeg.exe -i source_500mbit_x264.m4v -c:v hevc_amf -quality speed -usage transcoding -rc vbr_peak -b:v 10M -bufsize 1M -maxrate 11M -min_qp_i 0 -min_qp_p 0 -max_qp_i 51 -max_qp_p 51 out_ffmpeg_hevc.mp4

In hevc_amf implementation QP values defaulted to 0-51.
The problem is that ffmpeg sets qmin = 2 and qmax=31 as defaults in options_table.h and hevc_amf picks them up if hevc_amf QPs are not set.

Common properties like qmin and qmax could be re-defaulted in hevc_amf but it is not good practice. Or handbrake should set them explicitly.

I will ask some people to look into ffmpeg.

[PMunkes]

Thanks for looking into this.
I will relay this to the handbrake team, so this specific issue might be resolvable on their end. But it would of course be preferable to fix this in ffmpeg to prevent others from running into the same issue.

[PMunkes]

I tested this and I have opened a pull request #3452 with the workaround you proposed. Feel free to close this issue at your convenience.

[MikhailAMD]

We will send a patch to ffmpeg and close this issue once the patch is accepted. Thank you for your help.

[MikhailAMD]

The fix has been applied to ffmpeg master. Handbrake change is still good thing to do.

[PMunkes]

Thanks, the Handbrake change has been merged.