Loss of details compared to x264

Issue #122 new
Former user created an issue

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)

  1. Steve Borho

    --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.

  2. SI

    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.

  3. SI

    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.

  4. Deepthi Nandakumar

    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.

  5. Log in to comment