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. |
21st March 2017, 17:20 | #5042 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,731
|
The latest commit seems to put --limit-tu 4 in the presets slower and veryslow. Previously it was mentioned that --limit-tu 3 would provide good subjective quality while increasing performance, so has there been some more testing regarding the option?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
21st March 2017, 18:34 | #5044 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
THAT said, devices don't make heavy use of MaxFALL and MaxCLL in practice, because knowing what the brightest frame and brightest pixel across an entire movie isn't that useful. Dynamic metadata ala Dolby Vision and SMPTE 2094-40 are much more useful for tone mapping. |
|
22nd March 2017, 00:07 | #5045 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
MaxFALL and MaxCLL play no role in Hardware protection or could they be used to save energy more efficient per frame improving overheating statistics and overall Hardware output efficiency ?
Though not sure for what that would help you need those data in realtime and some heat buffer that corrects the latency before you need to emergency shutdown, HDR is pretty interesting in those regards how smart (adaptive) the Display Hardware must react to not get damaged or MTBF rising heavily whiich in the end also defines the end result of what you gonna percept overall HDR + VFR overall seem also to have the potential to be very efficiently combined especially 1 compensating the others higher power output needs Especially Nvidia and AMD currently seem to be very interested in pushing this forward in their Labs currently HDR generates some interesting drawbacks in terms of energy output savings that have been done over the years in power consumption it lowers the output efficiency again or compensates some of the advantages done in the Mobile Power Saving space pretty rapidly. Power Supplier are surely pretty happy about this development
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 22nd March 2017 at 00:39. |
22nd March 2017, 13:51 | #5046 | Link |
Registered User
Join Date: Sep 2010
Posts: 2
|
I'm having problem with non English filename using StxRip on Windows 7 64, Codepage 1252/850.
Running avs2pipemod64.exe (version 1.1.1 - Aug 2016) it gives: Code:
avs2pipemod[error]: Import: couldn't open "B:\Programas\StaxRipTemp\S? corro_temp\S? corro.x265 - MKV - Super Low 26 - AAC - 22050 Hz.avs" I suspected avs2pipemod was the cause of problem, but it seems not. Greetings from me and Stax76. |
22nd March 2017, 15:28 | #5047 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v2.3+24-a0eee4b41185 (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)
x265 [info]: HEVC encoder version 2.3+24-a0eee4b41185 x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
23rd March 2017, 20:49 | #5049 | Link | |
Registered User
Join Date: Nov 2004
Posts: 227
|
Quote:
http://www.mediafire.com/file/4nsvdb...vs2017-AVX2.7z |
|
23rd March 2017, 20:50 | #5050 | Link | |
Registered User
Join Date: Feb 2015
Posts: 326
|
Quote:
|
|
23rd March 2017, 21:01 | #5051 | Link | |
Registered User
Join Date: Jun 2016
Posts: 116
|
Quote:
|
|
23rd March 2017, 22:49 | #5053 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
Why is that pingfr?
GCC compiles mite be slow for 10bit encodes but thats not the case for 8bit. Personally so am i not interested in 10bit due 2 that its not especially compatible with hardware. Sent from my Samsung Galaxy S7 edge via Tapatalk
__________________
Do NOT re-post any of my Mediafire links. Download & re-host the content(s) if you want to share it somewhere else. |
23rd March 2017, 23:09 | #5054 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.
With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks). At least, there is a certain advantage of the MSVC builds. Rather small yet reliable. Last edited by LigH; 23rd March 2017 at 23:12. |
23rd March 2017, 23:58 | #5055 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Has anyone tried doing profile-driven optimizations for x265? I don't know if it would help much given all the assembler, but 5% on veryslow with a different compiler suggests there may be some juice to squeeze out there still. |
|
24th March 2017, 00:03 | #5056 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
An analytic with a lot of spare time would probably check: Which features are only enabled in slower presets, and are they still in C code? Most probably, as I would assume they are not primitive operations, thus rather hard to implement in lower level languages.
|
24th March 2017, 00:42 | #5057 | Link | |
Registered User
Join Date: May 2015
Posts: 185
|
Quote:
Although it is missing the placebo preset. I just can't be bothered waiting 45 minutes to run each placebo encodes. Also note it is important to remind you these tests were ran using 2.3+23, it is worth mentioning the latest commit applies limit-tu to slower, veryslow presets for an up to 20% increase in FPS according to the commit, this most likely has skewed the presented data here, it has to be seen whether the delta remains and even there we're talking about 0.15 of 1 fps. |
|
24th March 2017, 10:15 | #5059 | Link | |
Registered User
Join Date: May 2015
Posts: 68
|
Quote:
What exactly is that ratio percent in the last row? In the first comparison, one encode is faster than the other by 0.83%, which you have called as a 100.83% ratio. So in all the comparisons, to know by how much one is faster than the other, you have to ignore the "100", and whatever remains is the percentage difference in speed. Isn't that the relevant metric? By what percent one is faster than the other? |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|