Low keyframe quality when using CRF encoding and 48 frames (1.92 sec) fixed GOP with 25 fps content
I have recently discovered (with some high quality content in high bitrate H.264 or ProRes) that I get quite low quality on the IDR key frames generated, not all but some which is quite visible. This is when using both ffmpeg 5 and 6 with x264 core 164. when I change to use 50 frames GOP instead that seems to not generate the same visual (blocky/degraded) quality issue. Could this be some sort of potential bug when using x264? Had a similar issue with x265 but there it helped changing to ffmpeg6 version (not 100% sure why yet). For most content we handle I have not seen this to often but in some cases and with some content and it feels like there is some quality calculation that goes bad giving the low quality result. Another workaround seem to be using CBR which also does not have a problem with 1.92 sec (48 frames) GOPs. So related to CRF only as far as I can tell.
Reason for using 48 frames GOP, actually 1.92 seconds (instead of using 2 sec) is to have the audio and video aligned. Calculator can be found here: https://anton.lindstrom.io/gop-size-calculator/ Great presentation by Will Law (Akamai) here about player optimizations: https://youtu.be/_S0z4vAm98c?t=1508
Encoding settings/info according to media info: Writing library: x264 core 164 Encoding settings: cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=34 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=48 / keyint_min=25 / scenecut=0 / intra_refresh=0 / rc_lookahead=48 / rc=crf / mbtree=1 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=8000 / vbv_bufsize=4000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Have anyone else seen this behavior and might know if there is a workaround?
Thanks, Andreas