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. |
7th October 2016, 23:02 | #4301 | Link |
Registered User
Join Date: Oct 2009
Posts: 930
|
Here are examples of aliasing I saw with x265 encodes:
https://drive.google.com/open?id=0By...UdidHRRenMyQlE https://drive.google.com/open?id=0By...k5IakRzZDd0eVk Does anyone have a clue why it happens? |
8th October 2016, 16:48 | #4303 | Link | |
Guest
Posts: n/a
|
Quote:
|
|
9th October 2016, 14:20 | #4304 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)
I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU). VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...393b_vs15p5.7z (it works, no need to test) AVX-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-..._vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU) AVX2-CPU VS "15" preview 5 clean builds: http://www.msystem.waw.pl/x265/x265-...vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU) |
9th October 2016, 18:20 | #4305 | Link | |
Registered User
Join Date: Sep 2012
Posts: 47
|
Quote:
I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K. |
|
9th October 2016, 18:43 | #4306 | Link | |
Registered User
Join Date: Feb 2015
Posts: 326
|
Quote:
It looks like newest M$ compilers emit AVX2 only instruction with /arch:AVX option. I will try to report this bug. |
|
10th October 2016, 20:46 | #4307 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v2.1+20-c64393b415ad (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)
|
11th October 2016, 14:18 | #4308 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
x265 2.1+20-c64393b415ad (GCC 5.3.0)
x265 2.1+20-c64393b415ad (GCC 6.2.0) CLI changes since v2.1+2: Code:
+ --limit-tu <integer> Enable early exit from TU recursion for inter coded blocks. Default 0 - --discard-sei Discard SEI packets in bitstream. Default disabled - --discard-vui Discard optional VUI information from the bistream. Default disabled + --[no]-vui-timing-info Discard optional VUI timing information from the bistream. Default enabled + --[no]-vui-hrd-info Discard optional HRD timing information from the bistream. Default enabled The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality. __ P.S.: Don't try --limit-tu >2. Code:
Invalid limit-tu option, limit-TU must be 0, 1 or 2 Last edited by LigH; 11th October 2016 at 14:40. |
11th October 2016, 17:15 | #4310 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,771
|
Quote:
|
|
11th October 2016, 17:37 | #4311 | Link |
Registered User
Join Date: Jun 2016
Posts: 116
|
--limit-tu
@x265_project
Thank you guys so much! I've been wishing for a option like this for some time. A few quick tests show a performance drop of ~.5% with a file size ~2% smaller. This is comparing inter 1 vs inter 4 + limit tu 1. Without limit tu, inter 4 is ~ 20% slower. So far I see no visible quality difference. Great job!!! Could you explain the differences between limit tu 1 + 2 a bit more in depth, please? |
11th October 2016, 18:08 | #4312 | Link | |
Registered User
Join Date: Jan 2002
Posts: 332
|
Quote:
it seems there is no significant loss of quality for a good gain of speed with slower presets |
|
12th October 2016, 07:35 | #4313 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,784
|
This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".
slower = 2 veryslow = 3 placebo = 4 They are all no choice for a CPU without AVX support, I fear... |
13th October 2016, 13:33 | #4314 | Link |
Registered User
Join Date: Aug 2016
Location: Noord-Brabant, Netherlands
Posts: 3
|
Hi all,
I noticed a speed decrease between today's x265 and an earlier version of it. Using builds from builds.x265.eu I narrowed the change I'm talking about down to be between the following versions: 1.9+217-626fcbac7ffb 1.9+223-17c0c875f27d Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217. File size and visual quality of the output are virtually the SAME. These commits can currently be found at the fourth page of the commits list on Bitbucket. I also attached a screenshot of the 6 commits that could have caused this slowdown. The new recursion skip a.k.a. --rskip seems like something big that could have caused the different encoding time, so I tried --no-rskip, but that (logically) only further increased the encoding time. Could some other people perhaps test if they see a significant slow down between these versions too? Thanks in advance Last edited by stevendj; 13th October 2016 at 14:02. |
13th October 2016, 15:51 | #4316 | Link | |
Registered User
Join Date: Jan 2010
Posts: 709
|
Quote:
also as the doc says Code:
--limit-tu <0|1|2> Enables early exit from TU depth recursion, for inter coded blocks. Level 1 - decides to recurse to next higher depth based on cost comparison of full size TU and split TU. Level 2 - based on first split subTU's depth, limits recursion of other split subTUs. Default: 0
__________________
powered by Google Translator Last edited by Motenai Yoda; 13th October 2016 at 15:58. |
|
13th October 2016, 17:15 | #4317 | Link | |
Registered User
Join Date: Jun 2016
Posts: 116
|
Quote:
http://forum.doom9.org/showpost.php?...postcount=4237 At least it should. |
|
13th October 2016, 18:00 | #4318 | Link |
Registered User
Join Date: Aug 2016
Location: Noord-Brabant, Netherlands
Posts: 3
|
I can reproduce the difference with just preset slower & crf 23.
I also tried preset medium, but the issue seems non-existent there. It seems especially reproducible when encoding animated content, less so with 'real-life footage'. Now that I've done some more testing, I do see a quality increase in the 'real-life footage' encodes (so good job x265 team!), but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable.. |
13th October 2016, 20:57 | #4320 | Link | |
Registered User
Join Date: Aug 2016
Location: Noord-Brabant, Netherlands
Posts: 3
|
Quote:
There is a small quality increase, but a ~30% slower encode by my testing. (I only ran 1 test with this higher crf, on animation) Dear x265 Team, if in the future you would want to optimise x265 for animated content, I guess you should also look into how --rskip behaves on animation. Edit: all you hard & good work is much appreciated, though! Last edited by stevendj; 13th October 2016 at 22:47. |
|
|
|