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. |
26th August 2019, 08:11 | #4842 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Thanks, not intentional, fixed.
__________________
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 ??? |
26th August 2019, 08:51 | #4843 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Classic Avisynth caches these 60 frames:
Code:
a = clp.Trim(20,-30)+clp.Trim(2000,-30) AVS+ seems to read from the source every time in this scenario.
__________________
Groucho's Avisynth Stuff |
26th August 2019, 16:18 | #4844 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
For historical reasons Trim - along with other filters - is declared internally as a NonCachedGenericVideoFilter.
Changing that back to GenericVideoFilter yields significant speed increase. Such filters are: Trim, FreezeFrame, DeleteFrame, DuplicateFrame, Reverse and Loop |
26th August 2019, 17:06 | #4845 | Link | |
Banana User
Join Date: Sep 2008
Posts: 989
|
Quote:
|
|
26th August 2019, 18:09 | #4847 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
I'm sure pylorak had a good reason for that commit, if I recall correctly it was related to MT functionality.
__________________
Groucho's Avisynth Stuff |
26th August 2019, 18:26 | #4848 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,555
|
Quote:
What you've done here is implement the video scripting equivalent of an extremely inefficient algorithm. I personally view this like someone implementing bubble sort and then complaining about poor performance. Avisynth is a programming language and nobody can protect you from your own shortcomings. It's similar to how Matlab is really slow unless you figure out a way to express things as matrix operations. You have to work with the programming language, NOT AGAINST IT.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
|
26th August 2019, 19:30 | #4849 | Link |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
maybe as compromise and neutral Solution, trim can has cache parameter (false by default) if FrameCache() or RequestLinear() can't fix the slowdown
__________________
See My Avisynth Stuff |
26th August 2019, 20:08 | #4851 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Quote:
I mean, the other thing to point out is that the tests are being run single-threaded, and some of that syntax is wonky (probably minuscule in any possible performance detriment, but whatever). Actually using MT shows how artificial this test is in the first place, because it scales with # of cores in virtually 1:1 fashion. Script (with the cruft trimmed out and clarified): Code:
clp = FFVideoSource("test.avi").ConvertToRGB24() a = clp.Trim(20,-30)+clp.Trim(2000,-30) a1 = a+a+a+a+a+a+a+a+a+a a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1+a1 Prefetch(4) Code:
>avsmeter test.avs AVSMeter 2.9.6 (x86) - Copyright (c) 2012-2019, Groucho2004 AviSynth+ 0.1 (r2883, MT, i386) (0.1.0.0) Number of frames: 12000 Length (hh:mm:ss.ms): 00:08:20.500 Frame width: 196 Frame height: 88 Framerate: 23.976 (24000/1001) Colorspace: RGB24 Frames processed: 12000 (0 - 11999) FPS (min | max | average): 381.3 | 2361 | 1977 Process memory usage (max): 44 MiB Thread count: 16 CPU usage (average): 35.7% Time (elapsed): 00:00:06.070 Code:
>avsmeter test.avs AVSMeter 2.9.6 (x86) - Copyright (c) 2012-2019, Groucho2004 AviSynth+ 0.1 (r2883, MT, i386) (0.1.0.0) Number of frames: 12000 Length (hh:mm:ss.ms): 00:08:20.500 Frame width: 196 Frame height: 88 Framerate: 23.976 (24000/1001) Colorspace: RGB24 Frames processed: 12000 (0 - 11999) FPS (min | max | average): 2164 | 12104 | 10044 Process memory usage (max): 51 MiB Thread count: 20 CPU usage (average): 57.5% Time (elapsed): 00:00:01.195 Without Prefetch: Code:
>avsmeter64 test.avs AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004 AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0) Number of frames: 12000 Length (hh:mm:ss.ms): 00:08:20.500 Frame width: 196 Frame height: 88 Framerate: 23.976 (24000/1001) Colorspace: RGB24 Frames processed: 12000 (0 - 11999) FPS (min | max | average): 948.1 | 2770 | 2303 Process memory usage (max): 25 MiB Thread count: 16 CPU usage (average): 39.1% Time (elapsed): 00:00:05.211 Code:
>avsmeter64 test.avs AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004 AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0) Number of frames: 12000 Length (hh:mm:ss.ms): 00:08:20.500 Frame width: 196 Frame height: 88 Framerate: 23.976 (24000/1001) Colorspace: RGB24 Frames processed: 12000 (0 - 11999) FPS (min | max | average): 1767 | 13659 | 11223 Process memory usage (max): 32 MiB Thread count: 20 CPU usage (average): 55.7% Time (elapsed): 00:00:01.069 Code:
>avsmeter64 test.avs AVSMeter 2.9.6 (x64) - Copyright (c) 2012-2019, Groucho2004 AviSynth+ 0.1 (r2883, MT, x86_64) (0.1.0.0) Number of frames: 12000 Length (hh:mm:ss.ms): 00:08:20.500 Frame width: 196 Frame height: 88 Framerate: 23.976 (24000/1001) Colorspace: RGB24 Frames processed: 12000 (0 - 11999) FPS (min | max | average): 1692 | 139899 | 23581 Process memory usage (max): 33 MiB Thread count: 21 CPU usage (average): 34.1% Time (elapsed): 00:00:00.509 Last edited by qyot27; 26th August 2019 at 20:13. |
|
26th August 2019, 21:26 | #4852 | Link | |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
Quote:
2) And then I don't know why pinterf wrote ""historical" reasons" instead of giving a straight-to-the-point answer like yours. Perhaps that was a misplaced joke or/and his "sense of humor" is broken...... P.S.: 3) I am not VoodooFX alright Last edited by filler56789; 26th August 2019 at 21:40. |
|
26th August 2019, 23:35 | #4853 | Link | |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
Quote:
|
|
27th August 2019, 18:20 | #4854 | Link | |
Banana User
Join Date: Sep 2008
Posts: 989
|
Quote:
Code:
2s - AVS Standard 2.6 61s - AVS+ 304s - AVS+ with Prefetch(4) Code:
41s - AVS Standard 2.6 46s - AVS+ 247s - AVS+ with Prefetch(4) Last edited by VoodooFX; 29th August 2019 at 13:44. |
|
27th August 2019, 19:36 | #4855 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Setting the non-caching behaviour for zero-op filters in general seemed to be a good idea at that time in 2014, but as this use case shows the idea does not work for Trim and the probably for the other functions mentioned above. In the past few years I have already put back some deleted invoking of InternalCache to Avisynth+ since some real world (and not synthetic) scripts were slow in specific scenarios. Non-caching Trim probably has no penalty only when it appears alone and right after a source filter (? this has to be tested).
|
28th August 2019, 23:09 | #4857 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Bug?
I don't know if this is supposed to be "expected behavior", but at least I didn't expect anything like this. When a resizer is fed cropping coordinates from outside of the picure, what exactly is supposed to happen? I expected it to simply repeat the last line of the image, but that doesn't seem to be the case. Code:
function blackborder(clip c,int pix) { return c.crop(0,pix,0,-pix).addborders(0,pix,0,pix) } blankclip(width=100, height=100, length=20, pixel_type="y8", color=$ffffff) animate(0,19,"blackborder", 0, 19) lanczos4resize(width,height, 0, -height/2, width, height*2) histogram On frame 0, the expected behavior happens, where it just repeats the white border indefinitely and the zoomed-out image is also 100% white. On frame 1 and onwards, I was expecting it to treat the outside world as being black, however that's not what happens. Depending on how thick the black border is and what resizer is used, the outside color oscillates around gray/black, mimicking the wave-like nature and the sampling area of the resizer. For complete blackness, a 6 pixel border is needed for spline36, 2 for bilinear, etc. Last edited by ajp_anton; 28th August 2019 at 23:11. |
29th August 2019, 06:45 | #4858 | Link |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
ConvertBits(8,dither=1)
doesn't seem to work for 8-bit sources. Wiki says: "Dithering is allowed only for 10-16bit (not 32bit float) sources." You can dither from 16bits to 16bits so why not from 8bits to 8bits? I'm assuming those will just pass through the video untouched anyway. Life gets easier when I can just slap on a convert to 8bits at the end without worrying about what the input bitdepth is. |
29th August 2019, 07:25 | #4859 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Dithering is a technique to spread quality loss while reducing the precision. Converting from 8 bits per color component to 8 bits, there is no reduction, thus no loss to be spread.
|
29th August 2019, 07:48 | #4860 | Link | |
Registered User
Join Date: Aug 2006
Location: Stockholm/Helsinki
Posts: 805
|
Quote:
edit: I'm not saying 16b->16b actually does anything. I'm just confused over the fact that it's allowed, while 8b->8b isn't. I'm advocating for allowing also 8b->8b for when you can just add it to the end of a script or a function, without adding a check to see if it's allowed... (I feel like I'm repeating myself here, everything is already in the original post). Last edited by ajp_anton; 29th August 2019 at 07:50. |
|
|
|