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? _______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
