[x265] Poor encode quality with multiple slices
Dylan Yudaken
dylany at fb.com
Mon Jun 10 11:09:22 CEST 2019
It seems that when encoding multiple slices with frame parallelism the encode quality is very poor, especially when the slices are independent.
For repro:
(1) build a video with independent slices:
ffmpeg -i bus_cif.y4m -i akiyo_cif.y4m -filter_complex "nullsrc=size=352x576 [base];[0:v] setpts=PTS-STARTPTS, scale=352x288 [a]; [1:v] setpts=PTS-STARTPTS, scale=352x288 [b]; [base][a] overlay=shortest=1 [t_a];[t_a][b] overlay=shortest=1:y=288" -pix_fmt yuv422p merged.y4m
(2) (a) encode with 2 slices and threads:
$ ~/.../x265 --crf 20 --slices 2 -F 4 merged.y4m /dev/null > /dev/null
resulting in
encoded 125 frames in 2.27s (55.19 fps), 3149.60 kb/s, Avg QP:25.18
(2) (b) encode with 2 slices and no threads
$ ~/.../x265 --crf 20 --slices 2 -F 1 merged.y4m /dev/null > /dev/null
resulting in
encoded 125 frames in 2.30s (54.39 fps), 1531.36 kb/s, Avg QP:25.53
I ran this on latest trunk as of this morning.
Now I think the bug is somewhere around frameencoder.cpp:1425 (https://github.com/videolan/x265/blob/master/source/encoder/frameencoder.cpp#L1425)
I think the problem is that the max MV search range is a little too aggressive. For example if I remove the -1 term there the result seems to be a bit better. But I do not know what the actual semantics of that code is supposed to be, so I cannot be sure (or submit a patch).
Can someone with more experience take a look at this?
More information about the x265-devel
mailing list