Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 5th August 2020, 13:12   #7741  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by LeXXuz View Post
Wait. You mean you set prefetch() to 24 in Avisynth?
Or are we talking about different things here?
Yes. Prefetch(24, 24) works best for me as I have a 12c/24t CPU.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 5th August 2020, 14:17   #7742  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Hm. My encodes never gained any speed increase beyond prefetch(4). On the contrary, I had much more ram and cpu utilisization (naturally) but no fps increase. That's why I stayed with just 4.

Last edited by LeXXuz; 5th August 2020 at 16:47.
LeXXuz is offline   Reply With Quote
Old 5th August 2020, 15:07   #7743  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Did you increase the maximum cache size? When I switched back to Avisynth+, I noticed that I had to increase it to over 10GB for UHD things, otherwise everything would just stall. I think I now have it at 16GB just in case. Also the new caching method in Avs+ 3.6.1 helped me.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 8th August 2020, 10:46   #7744  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Quote:
Originally Posted by K.i.N.G View Post
After a quick test adding these parameters to the encode improved the quality in parts with motion "--rskip 2 --max-merge 2 --rd-refine" with about the same bitrate.
The artifacts are still there but far less (and much less perceptible when playing the video).
I'll see if i can experiment some more with the settings later, maybe it can be improved even more.

Thanks to everyone for the usefull input and suggestions!
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 (the default) fixed it.
I'm not sure if this reintroduces the original problem i was having of 'smeared' fast motion. I will need to (re)test some more later to see.

Last edited by K.i.N.G; 8th August 2020 at 11:01.
K.i.N.G is offline   Reply With Quote
Old 8th August 2020, 11:02   #7745  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by K.i.N.G View Post
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...

Last edited by Boulder; 8th August 2020 at 11:04.
Boulder is offline   Reply With Quote
Old 8th August 2020, 13:20   #7746  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
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...

Quote:
Originally Posted by Boulder View Post
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

Last edited by K.i.N.G; 8th August 2020 at 13:26.
K.i.N.G is offline   Reply With Quote
Old 8th August 2020, 15:38   #7747  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Do lavf builds allow passing options to ffmpeg for instance to enable vpy reading, hw decoding or other useful ffmpeg functionality?
stax76 is offline   Reply With Quote
Old 10th August 2020, 09:48   #7748  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Quote:
Originally Posted by Boulder View Post
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...


.

Last edited by K.i.N.G; 10th August 2020 at 10:27.
K.i.N.G is offline   Reply With Quote
Old 10th August 2020, 12:02   #7749  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by K.i.N.G View Post
*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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 12th August 2020, 12:59   #7750  |  Link
alex1399
Registered User
 
Join Date: Jun 2018
Posts: 56
Does I miss something, the x265 last commit stopped at 73ca1d7 which is on 2020/05/30.
alex1399 is offline   Reply With Quote
Old 12th August 2020, 13:34   #7751  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.

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

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 12th August 2020, 20:37   #7752  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Quote:
Originally Posted by LigH View Post
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.
nakTT is offline   Reply With Quote
Old 13th August 2020, 01:34   #7753  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by nakTT View Post
Why did they abandoned it?
Because BitBucket decided to drop Mercurial -_-
filler56789 is offline   Reply With Quote
Old 13th August 2020, 07:16   #7754  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
It was announced half a year ago so we all could adapt in time.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 14th August 2020, 07:35   #7755  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Quote:
Originally Posted by Boulder View Post
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.
K.i.N.G is offline   Reply With Quote
Old 16th August 2020, 17:37   #7756  |  Link
nakTT
Registered User
 
Join Date: Dec 2008
Posts: 415
Quote:
Originally Posted by filler56789 View Post
Because BitBucket decided to drop Mercurial -_-
Quote:
Originally Posted by LigH View Post
It was announced half a year ago so we all could adapt in time.
I see. Thank for the clarification.
nakTT is offline   Reply With Quote
Old 19th August 2020, 22:11   #7757  |  Link
fauxreaper
Registered User
 
Join Date: Oct 2014
Posts: 23
https://bitbucket.org/multicoreware/x265/issues is gone and https://bitbucket.org/multicoreware/x265_git don't have an issue tracker.
fauxreaper is offline   Reply With Quote
Old 19th August 2020, 22:19   #7758  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
even latest x265 still encodes few frames less with hdr10+ metadata..
__________________
AMD Ryzen 9 5950X, 32GB DDR4-3200 CL16, RTX 3060, 2TB NVMe PCIE4.0, NAS with 8x16TB HDD
jlpsvk is offline   Reply With Quote
Old 19th August 2020, 22:40   #7759  |  Link
onekmilesbehind
Registered User
 
Join Date: Mar 2019
Posts: 14
@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.
onekmilesbehind is offline   Reply With Quote
Old 19th August 2020, 23:32   #7760  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v3.4+15-g45f1d01f8 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/master
Barough is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:22.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.