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. |
13th May 2016, 17:36 | #3701 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,736
|
Quote:
MultiCoreWare could presumably use a lot of feedback on the results here. |
|
13th May 2016, 19:24 | #3703 | Link |
Registered User
Join Date: Oct 2014
Posts: 23
|
I've tested --no-recursion-skip on a short sample that was posted on devel list (https://mailman.videolan.org/piperma...ay/010350.html) and the results are good.
Encode gets 50% slower. |
14th May 2016, 09:32 | #3706 | Link |
Registered User
Join Date: May 2015
Posts: 185
|
@littlepox: Would you say it is safe and a quality benefit/visual benefit to use your custom parameters you cooked us since 1.9+1 with the newest --no-recursion-skip feature/tweak they added in 1.9+167?
Something along the lines of: --preset veryslow --ctu 32 --max-tu-size 16 --crf 18 --no-recursion-skip --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2 Edit: Typo, I meant 1.9+167 not 1.9+197. Last edited by pingfr; 15th May 2016 at 03:34. Reason: Edit: Typo, I meant 1.9+167 not 1.9+197. :p |
14th May 2016, 10:27 | #3707 | Link | |
Registered User
Join Date: Nov 2012
Posts: 218
|
Quote:
|
|
14th May 2016, 14:04 | #3708 | Link |
Registered User
Join Date: May 2015
Posts: 185
|
@littlepox: Alrighty, that makes sense. Let's wait on newer visually optimzed 1080p and 720p custom profiles from you for 1.9+167++ then.
Edit: Typo, I meant 1.9+167 not 1.9+197. Last edited by pingfr; 15th May 2016 at 03:35. Reason: Edit: Typo, I meant 1.9+167 not 1.9+197. :p |
14th May 2016, 20:12 | #3709 | Link |
Registered User
Join Date: Feb 2010
Location: Spain
Posts: 549
|
Bug report:
x265 builds 1.9.150 and newer crashes if filenames have accentuated characters on Spanish Windows (CMD with codepage 850 Multilingual Latin I). Probably the problem occurs with other languages as well. Example: With build 1.9.169 crashes: Same command line with build 1.9.149 works fine: Problem exist from this commit: https://bitbucket.org/multicoreware/...d7a09f2cb244bf Thanks! |
14th May 2016, 21:11 | #3710 | Link | |
Registered User
Join Date: Feb 2015
Posts: 326
|
Quote:
----------------- Patch file for '--qpfile' and '--csv' attached. ----------------- There are 2 problems with '--qpfile' -- now it doesn't support Unicode filenames and if you specify nonexistent file GCC build of x265 hangs, VS 2015 build of x265 exits with wired error messages. So in patch 13370 Unicode filenames are working with '--qpfile' and '--csv' options and if you specify nonexistent file in '--qpfile' option, x265 displays error message and encode without hangs. For tests I've compiled multilib version of x265 1.9+169 + 13370 + 13312 patches -- http://www.msystem.waw.pl/x265/x265-...+qpfile+csv.7z Last edited by Ma; 15th May 2016 at 09:43. |
|
16th May 2016, 16:28 | #3712 | Link | |
Registered User
Join Date: Mar 2016
Posts: 16
|
Quote:
Last edited by Grojm; 17th May 2016 at 17:17. |
|
16th May 2016, 17:03 | #3713 | Link |
Registered User
Join Date: Nov 2012
Posts: 218
|
As clear as I remember, x264 used to have all the same blames: slow, blurry, banding/blocking, motion artifacts... It took years to mature, not over a single night.
It shall be same for x265, which is mostly a brand new encoder whose internal logic has changed almost completely. Do not expect miracles out of it to be an immediate, all-round upgrade for x264. I'm always emphasizing that currently we prefer x264 over x265, NOT because x265 is poor, but x264 is just incredibly good. Do you blame Korean/Japanese/Singaporean table tennis players for their losing to Chinese in competitions? If you ever compare x265 to all other encoders like Adobe H264, Quicktime, libvpx... You'll realize that it's far outstanding. Thanks again for all the great work of the developers; keep it up. |
16th May 2016, 17:19 | #3714 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,736
|
Quote:
For something as far along as x265, having any single new feature that offers an obvious visual quality improvement is a huge accomplishment. x264 hasn't had one of those since, sheesh, mbtree? Most codec development is about squeezing out a bunch of discreet <<1% compression efficiency gains. |
|
16th May 2016, 17:24 | #3715 | Link | |
Registered User
Join Date: Nov 2012
Posts: 218
|
Quote:
|
|
16th May 2016, 17:48 | #3716 | Link | |
Registered User
Join Date: Jan 2007
Posts: 729
|
Quote:
(Sorry for off-topic.) |
|
16th May 2016, 17:54 | #3717 | Link | |
Registered User
Join Date: Nov 2012
Posts: 218
|
Quote:
Not so sure for your case; it's possible aq=1 is still relatively better. try strength=0.7? |
|
17th May 2016, 08:26 | #3718 | Link | |
Registered User
Join Date: Dec 2014
Posts: 240
|
Quote:
points 1,2 and 4 are correct. but don't know where you get 1/3 bitrate saving. encoded 2 movies, and have only about 130kbps save on the same settings and crf. |
|
17th May 2016, 11:34 | #3719 | Link | |
Registered User
Join Date: May 2009
Posts: 184
|
Quote:
|
|
17th May 2016, 12:43 | #3720 | Link | |
Registered User
Join Date: Nov 2012
Posts: 218
|
Quote:
The truth is aq3 is well suited in x264 but ill suited in x265. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|