[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