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 April 2020, 15:27 | #5383 | Link |
Registered User
Join Date: May 2009
Location: Belgium
Posts: 1,743
|
Houston, we have a problem
Since I re-installed AVS+ (AviSynthPlus-3.5.1_20200402.exe), I get lots of error messages ("can't open avs file", "function does not exist" ...) : I installed all 64 bit dlls in the plugins64+ directory, but Avisynth is installed in C:\Program Files (x86), is that the problem ? It was the proposed directory during installation. With the function version(), I see "r3106, 3.5, i386". I'm a little bit lost now , how to install 64 bit version correctly, and which plugin folder to use ? Does it depend on the functions (32 bit in plugins+ and 64 bit in plugins64+) ? And if it's a 32 bit only version, why are there plugins64 folders ? Last edited by Music Fan; 5th April 2020 at 15:42. |
6th April 2020, 01:07 | #5384 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,493
|
A long time ago, I pointed out a bug in bicubicresize - well, not so much bicubicresize, but resizing code in general, although by default it only exhibits with bicubicresize.
The problem is that bicubicresize, with its default parameters of b=1/3, c=1/3, is not a "nulll filter" when no resize/shift takes place - it actually blurs the image, because it has non-zero lobes even when the offset is 0. That's bad already to me, since to me a good resizer should have a null effect if no resize or shift is taking place - and indeed it does, but only because Avisynth tests for and skips resampling in such cases. But it shouldn't, and I seem to remember this skip was removed when I pointed out the problem (I can't remember if pinterf was running the show at the time), which is that doing this skip results in a discontinuity when using bicubicresize. However it seems that this fix has been reverted somewhere along the way, resulting, once again, in this: This is a very slow scroll of an image by animating the src_top and src_left parameters of bicubicresize. Hopefully you can spot the "jump" when those parameters reach 0,0 and resampling is skipped. Long story short: resampling should never be skipped - in either direction - just because there is no offset and the scale factor is 1. Not just because bicubicresize has silly default parameters (I know, I know, backwards compatibility...) but because you never know what parameters people may be using with resizers. Actually it may be that Gaussresize is the only other filter currently affected because of its p parameter, but I think it would be good practice to skip this premature optimisation anyway, to protect any future changes. Last edited by wonkey_monkey; 6th April 2020 at 01:15. |
6th April 2020, 07:30 | #5385 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
Long Time Ago Wonkey Thread:- https://forum.doom9.org/showthread.php?p=1849699
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? Last edited by StainlessS; 6th April 2020 at 07:51. |
|
6th April 2020, 10:17 | #5386 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
Code:
20181218 r2768 - Resizers: don't use crop at special edge cases to avoid inconsistent results across different parameters/color spaces Horizontal and vertical cases are decided separately. https://github.com/AviSynth/AviSynth...mple.cpp#L2464 |
|
9th April 2020, 13:33 | #5387 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
https://github.com/pinterf/AddGrainC/releases/tag/v1.8 Version resource and simd optimizations were lost during vs port, I have put them back. |
|
9th April 2020, 15:50 | #5388 | Link |
結城有紀
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
|
Do you guys have a list of tools+functions+parameters path combination that you think are critical (widely used by various of scripts) but lack AVX optimization or internal parallelism that I should start looking soon?
I'm thinking about mvtools and mask tools, but then I wonder if there are hot paths that I should focus on first because they are pretty huge. |
9th April 2020, 15:59 | #5389 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,795
|
The only filters I can think of right now would be removegrain + nnedi3, maybe also dfttest.
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database |
9th April 2020, 16:06 | #5391 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
9th April 2020, 16:42 | #5393 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Well, you could try mvtools2.
- replace existing internal mt of mvtools which is not portable (possible linux build in mind) and requires an external avstp dll. It was probably written well before that any standard mutex or threading concept appeared in C++ standards. Supported functions have a bool "mt" parameter, search for them in mvtools2.html in the documentation. - (portability) where dct 1..4 is used in the analysis, there fftw library is used (except for 8 bit 8x8 blocks which case is using integer fft) I have done smaller and larger cleanups in the past, even succeeded to build the source with clang just this week. |
9th April 2020, 16:48 | #5394 | Link | |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
Quote:
I updated the wiki also, I know you always do it but your time is too valuable to be doing those things. **** Edit: I think the syntax for AddGrain() you be kept as it originally was for compatibility with some older scripts (one example: MCSpuds). I don't there are many that use AddGrain(). The VS version was ported and just stuck with the syntax of AddGrainC but without the C. VS started from scratch so it was not a problem since all of the scripts had to be re-written anyways. Last edited by Reel.Deel; 9th April 2020 at 17:00. |
|
9th April 2020, 17:10 | #5395 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
I've allready added AVX and AVX2 on nnedi3, and it always had internal multi-threading since the begining, even before i work on it.
__________________
My github. Last edited by jpsdr; 9th April 2020 at 17:13. |
9th April 2020, 17:11 | #5396 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
Quote:
"Support Avisynth+ high bit depth" however when I try to use it with 10bit planar or 16bit planar, it reports an access violation. This is a pretty silly test, however it makes it crash: Code:
ColorBars(width=848, height=480, pixel_type="YV24") ConvertBits(10) AddGrainC(var=5.0, uvar=0.0, constant=true) so does this: Code:
ColorBars(width=848, height=480, pixel_type="YV24") ConvertBits(16) AddGrainC(var=5.0, uvar=0.0, constant=true) while the 8bit planar one works like a charm: Code:
ColorBars(width=848, height=480, pixel_type="YV24") AddGrainC(var=5.0, uvar=0.0, constant=true) I thought the culprit was the fact that it was 4:4:4, but even specifying 4:2:0 doesn't help with high bit depth: Code:
ColorBars(width=848, height=480, pixel_type="YV12") ConvertBits(16) AddGrainC(var=5.0, uvar=0.0, constant=true) however if I use the default values, it works: Code:
ColorBarsHD(width=704, height=396, pixel_type="YV24") ConvertBits(16) AddGrainC() Is there something I should be aware of when I use the parameters with high bit depth? Like they don't scale automatically and cause some kind of error or something? Last edited by FranceBB; 9th April 2020 at 17:19. |
|
9th April 2020, 17:47 | #5399 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
|
|
9th April 2020, 18:09 | #5400 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Next test please
https://github.com/pinterf/AddGrainC...ses/tag/v1.8.1 Original parameters restored, simd noise blocks use now unaligned load (possible solution to FranceBB's crash?) |
Thread Tools | Search this Thread |
Display Modes | |
|
|