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. |
5th August 2020, 14:17 | #7742 | Link |
21 years and counting...
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. |
5th August 2020, 15:07 | #7743 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,730
|
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... |
8th August 2020, 10:46 | #7744 | Link | |
Registered User
Join Date: Aug 2009
Posts: 90
|
Quote:
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. |
|
8th August 2020, 11:02 | #7745 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,730
|
Quote:
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. |
|
8th August 2020, 13:20 | #7746 | Link | |
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:
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. |
|
8th August 2020, 15:38 | #7747 | Link |
Registered User
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?
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
10th August 2020, 09:48 | #7748 | Link | |
Registered User
Join Date: Aug 2009
Posts: 90
|
Quote:
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. |
|
10th August 2020, 12:02 | #7749 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,730
|
Quote:
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... |
|
12th August 2020, 13:34 | #7751 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.
https://bitbucket.org/multicoreware/x265_git/commits/ = current git repository. Use only now. |
12th August 2020, 20:37 | #7752 | Link | |
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
Btw, thanks for the info. No wonder there was no updates since 30th of May. |
|
13th August 2020, 07:16 | #7754 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
It was announced half a year ago so we all could adapt in time.
|
14th August 2020, 07:35 | #7755 | Link | |
Registered User
Join Date: Aug 2009
Posts: 90
|
Quote:
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. |
|
16th August 2020, 17:37 | #7756 | Link | |
Registered User
Join Date: Dec 2008
Posts: 415
|
Quote:
|
|
19th August 2020, 22:11 | #7757 | Link |
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.
|
19th August 2020, 23:32 | #7760 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
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 |
Thread Tools | Search this Thread |
Display Modes | |
|
|