Distortion in IDR frame - Higher Ratefactor used

When encoding 4K 360 clips with CRF+VBV, in a few encodes, we see an increase in applied Ratefactor in one of the IDR frames, usually at the 16-17s mark. This results in blockiness in parts of the image - in the attached video, see the water body and the sand+bush just below and to the right of the water.

Command used is

ffmpeg -probesize 50M -analyzeduration 100M -i "Atmosphaeres-Dream-Beach-Mallorca-360-VR-Video-With-Music-Stereo-Audio-v6-15-15-Min-Cineform-MASTER-8K-FULL-MD1-Make-SAMPLE.mov" -map 0:0 -map 0:1 -c:a aac -ab 320k -disposition:a:0 default -strict -2 -async 1 -c:v libx265 -r 30000/1001 -s 4096x2048 -aspect 2:1 -pix_fmt yuv420p -movflags faststart -preset medium  -sws_flags lanczos -qmin 3 -qmax 51 -qdiff 4 -threads 8 -metadata creation_time=now -sn -x265-params crf=22:rd=2:rdoq-level=1:psy-rdoq=1.0:dynamic-rd=0:aq-mode=3:vbv-bufsize=25000:vbv-maxrate=18000 -vframes 550 -y "ref-cmd-local.mp4"

x265 version is 2.9+9-f74003e88622 used via ffmpeg master N-92538

The issue persists with various rd values, with or without psy-rd, with various aq modes. It almost disappears if we clamp qpmax (40) alongwith higher ip & pb ratios and it completely disappears if we just reduce frame-threads (to 2, in my tests). It also disappears if we increase VBV values by a lot but that defeats our requirements.

The VBV is used to limit the bitrate rather than satisfy playback requirements. But I notice that the resulting bitrate is already quite below the maxrate.

Here's a brief excerpt from the attached frame-level logging. Notice the i-Slice values.

Encode Order    Type    POC QP      Bits       RateFactor    BufferFill BufferFillFinal
495             b-SLICE 493 28.21   32088       24.271       18750000   25000000
496             b-SLICE 494 28.37   32312       24.271       18750000   25000000
497             b-SLICE 496 28.61   25528       24.271       18750000   25000000
498             i-SLICE 500 27.7    4560784     29.002       14789816   21039816
499             B-SLICE 499 26.24   84576       24.271       15305840   21555840
500             b-SLICE 498 28.4    32488       24.271       15873952   22123952
501             P-SLICE 505 26.62   2195744     27.869       14278808   20528808

Forcing closed GOP doesn't make a difference.

Why is this happening and what can be done to avoid these artifacts without increasing overall bitstream size and encode time? This only happens in a few of the clips.

8K CFHD source clip sample can be provided upon request (30s, MOV, 14GB).

Comments (8)