Updated (Grainy Source): x264 vs x265 vs NVENC H.265 vs QSV H.265 [2-pass @ 5000kbps]

[tonemapped]

Originally Posted by Boulder

Since your x265 don't have "regular" settings (--tune grain or --no-cutree are not very common), I cannot say anything about those QPs. They are rather high but that's probably because both encodes disable the cu-tree.

How about with something like this: --preset slower --deblock -1:-1 --no-sao --merange 58 --rskip 2 --rskip-edge-threshold 2 --rd-refine --max-merge 2 --ref 4 --bframes 10 --limit-refs 0 ?

Happy to try that out, but it'll be 2-pass 5mbps to match the other encodes for comparison. I should have perhaps reserved two or three posts so I could add them all in one continuous go, or maybe create a new thread with five post reserved due to the post image limit. Not sure if moderators would be happy with that.

One of the two x265 encodes is default --tune grain (with a couple of modifications such as deblock -3/-3, but nothing major) and the other is Ben Waggoner's suggestion higher up the thread.

[tonemapped]

Originally Posted by Boulder

Since your x265 don't have "regular" settings (--tune grain or --no-cutree are not very common), I cannot say anything about those QPs. They are rather high but that's probably because both encodes disable the cu-tree.

How about with something like this: --preset slower --deblock -1:-1 --no-sao --merange 58 --rskip 2 --rskip-edge-threshold 2 --rd-refine --max-merge 2 --ref 4 --bframes 10 --limit-refs 0 ?

Done. Added to the bottom of http://forum.doom9.net/showthread.ph...62#post1947762

For just over four hours of encoding time for four minutes of video, the results were not as good as hoped. The video seems to 'smear' grain into other grain.

[Boulder]

The difference between x264 and x265 is that the former creates blocking and the latter blurs when it's bitrate-starved and usually blocking doesn't seem as distracting. The QPs look quite high so the encode definitely is lacking bits. The encoding process is definitely very slow, so probably you're better off with x264 anyway.

[tonemapped]

Originally Posted by Boulder

The difference between x264 and x265 is that the former creates blocking and the latter blurs when it's bitrate-starved and usually blocking doesn't seem as distracting. The QPs look quite high so the encode definitely is lacking bits. The encoding process is definitely very slow, so probably you're better off with x264 anyway.

That may be the case, but to my eyes some of the hardware-encoded (Intel) look better than software-encoded. This shouldn't be the case. Even with x264, it is possible to produce a visually appealing grainy encode with a relatively low bitrate (e.g. 3500kbps @ 720p). Is it perfect? No. But that's not the point.

x265 is meant to bring improvements in size:compression/efficiency, amongst other features, and it's mature enough by now that grain retention should match that of x264's. x265 seems good for content with very, very light grain and content without grain. This is the most bizarre part to me. Even the --grain preset produces poor results.

Again, the entire point of doing a 2-pass encode at 5mbps is to compare different codecs and encoding methods at the same bitrate using the same source. If the newest one loses to hardware encoding and its predecessor, that shows a problem. I do use crf for encoding the vast majority of content for storage, but that's not the point of this test.

[Boulder]

Unfortunately x265 is not tuned for grain retention. We have fought that issue for years but the devs have never considered it a high priority thing. The tunings are not revised at all, and the first three AQ modes were mostly just ported directly from x264 and then left as they are.

The biggest issue with x265 is is that the most capable people left a long time ago and even patch validation has had issues with features getting worse with development.

[tonemapped]

Originally Posted by Boulder

Unfortunately x265 is not tuned for grain retention. We have fought that issue for years but the devs have never considered it a high priority thing. The tunings are not revised at all, and the first three AQ modes were mostly just ported directly from x264 and then left as they are.

The biggest issue with x265 is is that the most capable people left a long time ago and even patch validation has had issues with features getting worse with development.

Grain retention is great at ~9mbps, or even light grain at 3.5mbps for 1080p content. It's just high grain (as with the example) for low bitrate.

For example, I recently encoded a few episodes of Charmed from Blu-ray using CRF 21 with only a few changes (no-sao, etc.) and the result is great and only ~1.2GB per episode instead of ~7GB. A little bit of quality is lost in dark areas, but that's less of a concern for me. Overall, I would say it's 90% of the quality for 1/7 of the size. x264 would have severely struggled to output a reasonable file with the same bitrate/CRF constraints, so there's definitely a use for it.

[Boulder]

I still wouldn't call that grain, it's much more like quantization noise to me. That is more difficult to encode in a nice way than true film grain as it gets ugly quite easily like you have proven here.

[Sulik]

Why no B-frames in the NVENC and QSV encodes ?

[tonemapped]

Originally Posted by Sulik

Why no B-frames in the NVENC and QSV encodes ?

Not entirely sure. There was a message about b-frames not being supported on 'Gen 9.5' hardware (UHD 605, API 1.3x). On NVENC, I have no idea why b-frames weren't used. Either way, NVENC still produced some of the worst with over 20 tests of the same clip, compared to even QSV.

[benwaggoner]

IIIRC NVidia added support for B-frames with the RTX series.

[tonemapped]

Originally Posted by benwaggoner

IIIRC NVidia added support for B-frames with the RTX series.

That was done on a Turing card, so should have support. I must have made a mistake. The rest of the encodes are of more importance, as NVENC smears grain/noise.