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. |
19th March 2018, 02:15 | #4001 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Dont know if below is bugged, or misleading error message, or both.
Code:
# OK Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").PointResize(256,256) # Resize: source image too small for this resize method. Width=1, Support=1. Blankclip(Length=1,Width=1,height=1,Pixel_type="YV24").BilinearResize(256,256) # Resize: source image too small for this resize method. Width=2, Support=2. Blankclip(Length=1,Width=4,height=4,Pixel_type="YV12").BicubicResize(256,256) # NOTE, YV12, Presumably error for chroma # Resize: source image too small for this resize method. Width=2, Support=2. Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").BicubicResize(256,256) # NOTE, YV24 # Resize: source image too small for this resize method. Width=4, Support=4. Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").Lanczos4Resize(256,256) # Resize: source image too small for this resize method. Width=4, Support=4. Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").GaussResize(256,256) # Resize: source image too small for this resize method. Width=4, Support=4. Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").BlackmanResize(256,256) # Resize: source image too small for this resize method. Width=3, Support=3. Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").LanczosResize(256,256) # Resize: source image too small for this resize method. Width=4, Support=4. Blankclip(Length=1,Width=4,height=4,Pixel_type="YV24").sincResize(256,256) # Resize: source image too small for this resize method. Width=2, Support=2. Blankclip(Length=1,Width=2,height=2,Pixel_type="YV24").Spline16Resize(256,256) # Resize: source image too small for this resize method. Width=3, Support=3. Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256) # Resize: source image too small for this resize method. Width=3, Support=3. Blankclip(Length=1,Width=3,height=3,Pixel_type="YV24").Spline36Resize(256,256) Return Last Think its been like this 4E4 (believe it exists as above in avs standard). EDIT: Presume similar on height, untried.
__________________
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; 19th March 2018 at 18:37. |
19th March 2018, 03:32 | #4002 | Link | ||||
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
>Dont know if below is bugged, or misleading error message, or both.
misleading I'd say Quote:
Quote:
Quote:
Quote:
Last edited by raffriff42; 19th March 2018 at 04:13. |
||||
19th March 2018, 14:08 | #4003 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
Maybe it's because I'm tired, but if a filter is supposed to support value X (as per filter_support in the code there), it shouldn't be erroring out when equal to the value of filter_support. It only should in the less than case. Unless filter_support is not actually the minimum supported value, but the maximum unsupported value (in which case it being named 'filter_support' in the code is also misleading or incorrect).
In other words, either the operator in the code is wrong (it should be just <, not <=) or the naming of both 'filter_support' and the 'Support' field in the error message are wrong. |
24th March 2018, 04:44 | #4004 | Link |
Retried Guesser
Join Date: Jun 2012
Posts: 1,373
|
I'm getting access violations when downsizing inside an Animate call. Maybe it's just my system.
It does not happen in AVS 2.6.1, and it does not happen when "z_" avsresize filters are substituted. Code:
ColorbarsHD(width=640, height=400) ## optional - these do not change the test result KillAudio ConvertToYV12 Trim(0, length=150) Animate(0, 120, "_MyBlur", 0.0, 60.0) ## optional - make the clip longer so AvsMeter can chew on it R=Reverse Last+Reverse Loop(100) return Last function _MyBlur(clip C, float rad) { ## ## HEART OF THE TEST: ## BilinearResize causes intermittent... ## | Exception 0xC0000005 [STATUS_ACCESS_VIOLATION] ## | Module: C:\Windows\system32\KERNELBASE.dll ## | Address: 0x00007FFF071D92FC ## (64-bit) ## or... ## | Exception 0xC0000005 [STATUS_ACCESS_VIOLATION] ## | Module: C:\Windows\SysWOW64\avisynth.DLL ## | Address: 0x618064ED ## (32-bit) ## but avsresize "z_BilinearResize" is OK ## return (rad<0.1) ? C \ : C.BilinearResize( \ m4(Float(C.Width)/(rad+1.0)), \ m4(FLoat(C.Height)/(rad+1.0))) \ .GaussResize( \ C.Width, C.Height, p=19) } ### MOD-4-and-at-least-16 helper function ## @ Didée function m4(float f) { (f<16) ? 16 : Int(Round(f/4.0)*4) } Last edited by raffriff42; 24th March 2018 at 04:46. |
24th March 2018, 05:01 | #4005 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Did not try z_lib resizers, but your script (as supplied, running for 3 mins) does OK on XP32 bit.
EDIT: OK after redo at 6 mins. Why this, (Round produces an Int already, you can answer for Didee if you like [did it change in more recent version of Avs]) Code:
(f<16) ? 16 : Int(Round(f/4.0)*4) Quote:
__________________
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; 24th March 2018 at 05:47. |
|
24th March 2018, 08:04 | #4006 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
EDIT: and fixed on git. Last edited by pinterf; 26th March 2018 at 08:26. Reason: fix ready |
|
26th March 2018, 01:49 | #4007 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
I'm curious, is it still best practice not to cache frames ever, for any purpose, as this post suggests? I'm still running into a few performance issues and I think they may be, at least in part, due to hammering the PCIe bus constantly when moving frames between the CPU and GPU.
|
27th March 2018, 01:17 | #4009 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Yoda, give some example for Pintef, please.
__________________
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 ??? |
28th March 2018, 00:04 | #4010 | Link |
Registered User
Join Date: Jan 2010
Posts: 709
|
Code:
convertbits(10) #12 or 14 merge(last,0.33) convertbits(8)
__________________
powered by Google Translator Last edited by Motenai Yoda; 28th March 2018 at 00:15. |
28th March 2018, 02:52 | #4011 | Link | |
Registered User
Join Date: Sep 2005
Posts: 178
|
Quote:
Code:
for(;;) malloc(1000000); Last edited by `Orum; 28th March 2018 at 03:03. |
|
28th March 2018, 09:35 | #4012 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
|
|
28th March 2018, 13:53 | #4013 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
That still doesn't explain why it would endlessly allocate memory until it couldn't any more.
Anyway, the point was that at the very least AvsP[mod] shouldn't be a test for memory leaks from AviSynth+. It should be tested with something a lot more stable, e.g. VirtualDub, avs2yuv, AVSmeter, etc. And even then, to make sure the leak is within AviSynth+ itself one should avoid external filters. Last edited by `Orum; 28th March 2018 at 13:56. |
28th March 2018, 20:33 | #4014 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
New build with important fixes and some minor tweaks. Thanks for the reports.
Download Avisynth+ r2664-MT In this changelog I left there intentionally some lines about a finally postponed modification. Read it as a preliminary info (32 bit float YUV chroma format). We could start a discussion about it. Code:
20180328 r2664 -------------- - Fix: YUY2 Sharpen overflow artifacts - e.g. Sharpen(0.6) - Fix: Levels: 32 bit float shift in luma - Fix: Merge sse2 for 10-14bits (regression) - Fix: AVX2 resizer possible access violation in extreme resizes (e.g. 600->20) - Fix: 32bit float PlanarRGB<->YUV conversion matrix - Fix: VfW: fix b64a output for OPT_Enable_b64a=true - Enhanced: VfW output P010 and P016 conversion to SSE2 (VfW output is used by VirtualDub for example) - Enhanced: ColorYUV: recalculate 8-16 bit LUT in GetFrame only when changed frame-by-frame (e.g. in autowhite) - Enhanced: ConvertBits 32->8 sse2/avx2 and 32->10..16 sse41/avx2 (8-15x speed) Not included, preliminary for the near future: - Big change: 32 bit float YUV formats, U and V are now zero based. Internally YUV 32 bit float chroma center became 0.0 (the neutral value which is 128 in the 8-bit world) Like in VapourSynth or in avsresizer using z.lib image library. 'Expr' changes are affecting built-in constants/operators when used in chroma plane of a 32bit clip. - 'cmin', 'cmax' return the zero-based shifted versions of the 16 and 240 (8 bit) values - For U and V planes, constant 'range_half' results in 0.0 instead of the old 0.5 - 'scaleb' will also give zero-based result when found in an expression for chroma plane (e.g. for a 32 bit float clip the '128 scaleb' will result in 0.0 instead of 128/255 for U and V planes) But 'scalef' when the target or source of the constant conversion is 32bits, remains independent from the plane type. - 'range_max' is 0.5 for 32 bit float chroma - new constant 'range_min', which is -0.5 for 32 bit float chroma, (0 otherwise) Additional warning: when you move 32bit float U or V plane to Y using CombinePlane, you have to be sure that your filters do not rely on this new Y plane being in 0..1 range. Or else convert it by using Expr("x 0.5 +") to the 0..1 range Similarly: ExtractU and ExtractV will simply return the unaltered chroma planes, which are now zero-centered |
29th March 2018, 15:23 | #4016 | Link |
Registered User
Join Date: Sep 2005
Posts: 178
|
Are variables not cached along with frames? For example (forgive the obvious assumptions made, it's just to illustrate the problem):
Code:
#define MAX_DELTA 1 for(int f = 0; f < 100; f++) { PVideoFrame vf = clip->GetFrame(f, env); strstream dbg; dbg << env->GetVarDef("FFPICT_TYPE", AVSValue('?')).AsInt() << ends; OutputDebugStringA(dbg.str()); dbg.freeze(false); for(int n = 1, n <= MAX_DELTA; n++) foo(vf, clip->GetFrame(f + n, env)); // What foo() does isn't really relevant here, just know that it doesn't request any frames } Edit: I can write my own filter in order to rule out (or in) FFVideoSource() as the problem if you'd like. Last edited by `Orum; 29th March 2018 at 15:35. |
29th March 2018, 16:03 | #4017 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Avisynth has no frame properties like Vapoursynth has. The method of filling the variable is a workaround hack which probably works only when the variable is constant.
You can define a filter to NonCachedGenericVideoFilter, like Reverse or Loop works internally. |
29th March 2018, 16:31 | #4018 | Link | |
Registered User
Join Date: Sep 2005
Posts: 178
|
Quote:
Correct me if I'm wrong but this won't fix the issue if, for example, you have a script like this: Code:
FFVideoSource("foo.mkv") bar() myfilter() Edit: Now that I think about it, even if AviSynth+ cached these it would still require the earlier filter to do the request for any non-offset frames last. For instance, if you think about a filter that does a temporal blend of frame 'f' with radius 'x' (forward and backward), it would still have to request frame 'f' last and not frame 'f + x' to get the variable correct. It seems like a better solution is to either parse the the FFVideoSource() cache (if that even contains the picture types), or the source file itself, but neither is friendly if there's a simple Trim() in the script before it hits myfilter(). In any case, there's no general solution, as even the idea of a picture type disappears with any temporal filtering. Last edited by `Orum; 29th March 2018 at 18:17. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|