Loss of details compared to x264
I don't know if this should be reported as a bug or an enhancement request, but I'll file it under bugs anyway.
I found this issue while doing a comparison between the two codecs. x265 clearly removes a lot of details compared to x264. The issue is not apparent in I-frames but other ones are affected quite severely.
Video clips: x264 @ CRF 18.5 : https://drive.google.com/file/d/0Bze...ew?usp=sharing
x265 @ CRF 20.3 : https://drive.google.com/file/d/0Bze...ew?usp=sharing
Original sequence : https://drive.google.com/file/d/0BzeF_1syecQwakhsX3RuZGhWcjA/view?usp=sharing
Screenshots: x264 : https://drive.google.com/file/d/0Bze...ew?usp=sharing
x265 : https://drive.google.com/file/d/0Bze...ew?usp=sharing
Commandlines:
c:\x264\x264.exe --stdin y4m - --sar 1:1 --level 4.1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --tune film
--preset veryslow --crf 18.5 --output c:\x265\x264_crf18.5.h264
c:\x265\x265.exe --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slow --tune grain --crf 20.3 --output c:\x265\x265_crf20.3.h265
Using --rdoq-level 1 instead of --tune grain in x265 doesn't make a big difference.
Comments (5)
-
-
--tune grain is reducing AQ pretty heavily; it is not really trying to improve grain retention, it's main purpose is to smooth the grain evenly between I, P, and B frames to reduce strobing, and it's pretty heavy-handed.
-
As mentioned, I've also tried without --tune grain, replacing it with --rdoq-level 1 but it doesn't help.
I posted these screenshots to the Doom9 x265 thread, tried settings "--preset slow --rdoq-level 1 --qg-size 16 --merange 24 --rc-lookahead 125" for x265:
x264 : https://drive.google.com/open?id=0BzeF_1syecQwLWJnMjZ0VXhwVm8&authuser=0
x265 : https://drive.google.com/open?id=0BzeF_1syecQwUFgycndfTlRPUVU&authuser=0
I don't know which frames are the very smoothed ones in x265 but I suspect that they are B-frames. I can check that later with logging enabled.
-
Based on the logs, the large differences begin to appear in the third frame of the encode which is a P-slice.
0, I-SLICE, 0, 13.41, 1797320, -, -, -, -, -, -, -, -, 11128.0, 0.0, 1642.0, 0.0, 3705.0, 0.0, 3.261, 56
1, P-SLICE, 1, 16.66, 1272, -, -, -, -, -, -, 0, -, 11130.0, 1449.0, 180.0, 162.0, 82.0, 126.0, 1.967, 7
2, P-SLICE, 5, 16.38, 1113688, -, -, -, -, -, -, 1 0, -, 1.0, 0.0, 575.0, 0.0, 1305.0, 0.0, 3.111, 50
x264 [debug]: frame= 0 QP=26.41 NAL=3 Slice:I Poc:0 I:2640 P:0 SKIP:0 size=249549 bytes
x264 [debug]: frame= 1 QP=34.00 NAL=2 Slice:P Poc:2 I:0 P:0 SKIP:2640 size=33 bytes
x264 [debug]: frame= 2 QP=29.71 NAL=2 Slice:P Poc:10 I:295 P:2344 SKIP:1 size=122474 bytes
The first two frames of the encode look quite the same - there's no extra smoothing in the x265 version.
-
Hello,
We've heard this feedback before about x265 for specific clips, and as you can guess, there is no quick-fix solution. Just to let you know, we're working on this on priority basis.
We have your test case downloaded and added to our suite.
- Log in to comment
Corrected links:
Videos:
x264 : https://drive.google.com/open?id=0BzeF_1syecQwYzB0aFYtVFI5V2s&authuser=0
x265 : https://drive.google.com/open?id=0BzeF_1syecQwM2RUcWptdU1hZXM&authuser=0
Original clip : https://drive.google.com/open?id=0BzeF_1syecQwakhsX3RuZGhWcjA&authuser=0
Screenshots:
x264 : https://drive.google.com/open?id=0BzeF_1syecQwTXRDVXpkQ2lkUms&authuser=0
x265 : https://drive.google.com/open?id=0BzeF_1syecQwQS10RUtLclZHTzA&authuser=0