x265 HEVC Encoder

[Boulder]

Originally Posted by K.i.N.G

Just a quick update:
So, after some more testing I've found that setting --rskip 2 causes a lot of flickering macro blocks.. setting this to 1 fixed it.
I'm not sure if this reintroduces the original problem i was having of 'smeared' fast motion. I will need to test some more to see.

Could you post the rest of your settings? I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

[K.i.N.G]

Well, it looks like I jumped to conclusions a bit too fast...
appearantly its not completely gone with rskip 1... just a lot less.
So I'll try rskip 0 now...

Originally Posted by Boulder

Could you post the rest of your settings? I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

settings:
x265.exe --crf 18 --preset veryslow --profile main10 --level-idc 4 --output-depth 10 --limit-refs 0 --psy-rdoq 1.5 --rskip-edge-threshold 4 --cu-lossless --subme 6 --merange 64 --max-merge 2 --keyint 480 --no-hdr10 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --deblock -2:-2 --selective-sao 0 --no-sao --high-tier --no-strong-intra-smoothing --rd-refine

Just standard HD (no HDR).

Will try CTU 32 and limit-tu 0 aswell.
*edit: as I'm using the very slow preset as a base limit-tu was already set at 0

[stax76]

Do lavf builds allow passing options to ffmpeg for instance to enable vpy reading, hw decoding or other useful ffmpeg functionality?

[K.i.N.G]

Originally Posted by Boulder

I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

Setting --rskip 2 with --ctu 32 it still caused flickering macroblocks.
Setting --rskip 1 with --ctu 32 seems to have fixed it. I'll have to try with some other problematic sources later to be sure.

setting --rskip 2 wit a low --rskip-edge-threshold also seemed to give better results but I got tired of testing so I just went with rskip 1.


Yes, its very frustrating how easily things just break apart with x265. Quite a lot of issues which I dont seem to remember having encountered with older versions of x265?!


*edit: Nope, nevermind, still not fixed by adding --rskip 1 with --ctu 32, its still there in darker parts... Turning off rskip now...


.

[Boulder]

Originally Posted by K.i.N.G

*edit:[/U][/B] Nope, nevermind, still not fixed by adding --rskip 1 with --ctu 32, its still there in darker parts... Turning off rskip now...
.

rskip off is probably worse. I think that --rskip 2 causes less recursion skips than --rskip 1 so in that sense, totally disabling skips would cause more issues.

You are probably using the default aq-mode (2), which is worse in my opinion. It sometimes caused the ugly floating macroblocks in flat areas, and I cannot stand those so I'd test also --aq-mode 1 to make sure it's not the issue there.

I also suggest removing --no-strong-intra-smoothing, there were some tests showing that the details are retained better that way.

[alex1399]

Does I miss something, the x265 last commit stopped at 73ca1d7 which is on 2020/05/30.

[LigH]

https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.

https://bitbucket.org/multicoreware/x265_git/commits/ = current git repository. Use only now.

[nakTT]

Originally Posted by LigH

https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.

https://bitbucket.org/multicoreware/x265_git/commits/ = current git repository. Use only now.

Why did they abandoned it?

Btw, thanks for the info. No wonder there was no updates since 30th of May.

[filler56789]

Originally Posted by nakTT

Why did they abandoned it?

Because BitBucket decided to drop Mercurial -_-

[LigH]

It was announced half a year ago so we all could adapt in time.

[K.i.N.G]

Originally Posted by Boulder

rskip off is probably worse. I think that --rskip 2 causes less recursion skips than --rskip 1 so in that sense, totally disabling skips would cause more issues.

You are probably using the default aq-mode (2), which is worse in my opinion. It sometimes caused the ugly floating macroblocks in flat areas, and I cannot stand those so I'd test also --aq-mode 1 to make sure it's not the issue there.

I also suggest removing --no-strong-intra-smoothing, there were some tests showing that the details are retained better that way.

Lower rskip values actually improved the results (at least with this issue/artifact).

Setting --aq-mode 1 also helps quite a bit!

So now I'm testing with aq-mode 1, rskip 2 with rskip-edge-threshold 0.03 and re-enabled strong-intra-smoothing.

So far its looking promessing... Thank you for these suggestions!
I have several problematic sources to re-encode and that's going to take a few weeks(!). So, it will take quite some time before I can tell for sure that it fixed the issue, but its looking good so far.

[nakTT]

Originally Posted by filler56789

Because BitBucket decided to drop Mercurial -_-

Originally Posted by LigH

It was announced half a year ago so we all could adapt in time.

I see. Thank for the clarification.

[fauxreaper]

https://bitbucket.org/multicoreware/x265/issues is gone and https://bitbucket.org/multicoreware/x265_git don't have an issue tracker.

[jlpsvk]

even latest x265 still encodes few frames less with hdr10+ metadata..

[onekmilesbehind]

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

[Barough]

x265 v3.4+15-g45f1d01f8 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[BobbyBoberton]

Originally Posted by K.i.N.G

Lower rskip values actually improved the results (at least with this issue/artifact).

Setting --aq-mode 1 also helps quite a bit!

So now I'm testing with aq-mode 1, rskip 2 with rskip-edge-threshold 0.03 and re-enabled strong-intra-smoothing.

So far its looking promessing... Thank you for these suggestions!
I have several problematic sources to re-encode and that's going to take a few weeks(!). So, it will take quite some time before I can tell for sure that it fixed the issue, but its looking good so far.

I find rskip 2 with hevc-aq mode enabled and rskip-edge-skip-threshold 5 to give very good results for me for both SDR and HDR content.

Just my experience

[LigH]

Originally Posted by fauxreaper

https://bitbucket.org/multicoreware/x265/issues is gone and https://bitbucket.org/multicoreware/x265_git don't have an issue tracker.

All that remains seems to be the mailing list: x265-devel@videolan.org

[Boulder]

Originally Posted by LigH

All that remains seems to be the mailing list: x265-devel@videolan.org

Easy to get rid of the silly users reporting errors by not using an issue tracker

[jlpsvk]

Originally Posted by onekmilesbehind

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

will give it a try. but it's not a problem, that hdr10+ encoding is not working... it just does not throw out the same number of frames, as source..