JPSDR Avisynth's plugins pack

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[FranceBB]

Originally Posted by jpsdr

New version, see first post.

Yep, I silently lurked the awarpsharp thing on the other topic.
Thank you for the update, it seems to work fine on Windows XP; perhaps I never noticed the error 'cause AVX are not a thing on XP (and I don't encode anime at work where I have Win10), so I never used that part of the code...

Cheers,
Frank.

[real.finder]

Originally Posted by FranceBB

Yep, I silently lurked the awarpsharp thing on the other topic.
Thank you for the update, it seems to work fine on Windows XP; perhaps I never noticed the error 'cause AVX are not a thing on XP (and I don't encode anime at work where I have Win10), so I never used that part of the code...

Cheers,
Frank.

awarpsharp may made for anime, but it used in YAHR by Didée which a general use dehalo

https://web.archive.org/web/20090803....php?p=1205653

[SeregaDS]

Hi!
I have an issue with last version of plugins_JPSDR_v3_2_1 (But with the previous version plugins_JPSDR_v3_2_0 - all right).
The next code produce strange video:
TempGaussMC_beta2u (tr0=2,tr1=2,tr2=3,EdiMode="NNEDI3", SLrad=2)

(without using NNEDI3 - also all right)

In the same time, the next code produce normal video:
QTGMC(tr0=2,tr1=2,tr2=3,EdiMode="NNEEDI3", SLrad=2)


Win10x64. AviSynth+ 3.5.2 (r3218, neo, x86_64)

[jpsdr]

In VDub, this seems to work :

ColorBars(width=640, height=480, pixel_type="yv12")
#QTGMC().SelectEven()

but this one crash inside avisynth:

QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=1).SelectEven()

The second one involve FFT3DFilter.

Is TempGaussMC_beta2u using FFT3DFilter ?

I'll try to make a version not using the new Pplanar, maybe it was too soon for the new headers... (if it's that).

[SeregaDS]

Is TempGaussMC_beta2u using FFT3DFilter ?

I don't think so...
Search for string "FFT3" inside script didn't find any results...
And if i use EEDIx (not NNEDI3) - script works normal.

[pinterf]

Originally Posted by jpsdr

In VDub, this seems to work :

ColorBars(width=640, height=480, pixel_type="yv12")
#QTGMC().SelectEven()

but this one crash inside avisynth:

QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=1).SelectEven()

The second one involve FFT3DFilter.

Is TempGaussMC_beta2u using FFT3DFilter ?

I'll try to make a version not using the new Pplanar, maybe it was too soon for the new headers... (if it's that).

Previous version (0.9.4.53) was staying at 306MB (avsmeter64) and works at 8+fps (whole qtgmc), this last one seems to have a memory leak, shortly reaches 4GB where Avisynth is slowing down since it tries to free up caches.

[jpsdr]

My standard PC (the one i'm writting with here) is under standard avs2.6.1, this is why the second qtgmc script crash, it's probably not working under avs2.6.1.

[SeregaDS]

So, please try to use TempGaussMC_beta2u
It works with all versions of Avs...

[jpsdr]

Ok, i've figure out where it's happening, but i'm unable to figure out the proper syntax for transmiting parameters.

Before, the src was created and used inside the copyPad function, called at the begining of the GetFrame function:

void nnedi3::copyPad(int n, int fn, IScriptEnvironment *env)
{
	const int off = 1-fn;
	PVideoFrame src = child->GetFrame(n, env);

and src wasn't needed outside anymore.

Now, i need the src to create the dst, so, now, instead of:

PVideoFrame __stdcall nnedi3::GetFrame(int n, IScriptEnvironment *env)
{
	int field_n;

	if (field>1)
	{
		if (n&1) field_n = field == 3 ? 0 : 1;
		else field_n = field == 3 ? 1 : 0;
	}
	else field_n = field;
	
	copyPad(field>1?(n>>1):n,field_n,env);

i have:

PVideoFrame __stdcall nnedi3::GetFrame(int n, IScriptEnvironment *env)
{
	int field_n;

	if (field>1)
	{
		if (n&1) field_n = field == 3 ? 0 : 1;
		else field_n = field == 3 ? 1 : 0;
	}
	else field_n = field;
	
	PVideoFrame src = child->GetFrame(n,env);
	
	copyPad(src,field>1?(n>>1):n,field_n,env);

This is what creating the memory leak and the issues.
I've tried

void copyPad(const PVideoFrame &src,int n,int fn,IScriptEnvironment *env);

and without const and also

void copyPad(PVideoFrame src,int n,int fn,IScriptEnvironment *env);

still the same behavior...
I'll try a mix with previous version, copyPad geting src and return it...

[MeteorRain]

I noticed src was used in both copyPad and NewVideoFrameP. Any chance it's the latter?

[jpsdr]

No... It's the new thing, now i need src for NewVideoFrameP.
I've made my tests by implementing the changes step by step, and kept NewVideoFrameP for the end, so, i've re-created the issue before puting back NewVideoFrameP.
It seems that a mix, creating src inside copyPad and having it return src works, no memory leak anymore and identical speed.

New build soon.

[pinterf]

Originally Posted by MeteorRain

I noticed src was used in both copyPad and NewVideoFrameP. Any chance it's the latter?

I have tried with an old r2900 avs+, and it still leaks, that is not using the P vesion. For the first sight I cannot tell what is happening.

[pinterf]

Originally Posted by jpsdr

No... It's the new thing, now i need src for NewVideoFrameP.
I've made my tests by implementing the changes step by step, and kept NewVideoFrameP for the end, so, i've re-created the issue before puting back NewVideoFrameP.
It seems that a mix, creating src inside copyPad and having it return src works, no memory leak anymore and identical speed.

New build soon.

GetFrame recursively called itself with the same n, but 'n' is different in copyPad.
This one works:
int x = field > 1 ? (n >> 1) : n;
PVideoFrame src = child->GetFrame(x,env);

[jpsdr]

OMFG !!! This is what i've missed !!!

[jpsdr]

New version, see first post, should be fixed.

[jpsdr]

New version, see first post.

[jpsdr]

New version, see first post.

[DTL]

As an addition to readme.txt about SincLin2Resize:

It designed as workaround to fix edge bugs with SincResize if using too few number of taps. 'Too few' mean about < 60..70 with 8-bit integer samples processing. It gives at least taps/2 full-strike sinc kernel size and last taps are linearly faded to zero (something like 'trapezoidal weighting'). At some testcases it allows to get clean 8-bit result with taps parameter as low as 15. That is significally faster in compare with SincResize(taps=70). With lesser taps parameter it may definetly expose same edge 'ghosting' and 'object griding' bugs as old SincResize. So for high quality work it is recommended to keep taps >15..20. It is a bit sharper in compare with LanczosResize with same number of taps because of less aggressive sinc kernel weighting.