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. |
29th April 2020, 02:08 | #103 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,908
|
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. |
29th April 2020, 02:50 | #104 | Link | |
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
https://web.archive.org/web/20090803....php?p=1205653
__________________
See My Avisynth Stuff |
|
4th May 2020, 17:30 | #105 | Link |
Registered User
Join Date: Jan 2017
Posts: 5
|
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) |
5th May 2020, 14:16 | #106 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,318
|
In VDub, this seems to work :
Code:
ColorBars(width=640, height=480, pixel_type="yv12") #QTGMC().SelectEven() Code:
QTGMC(preset="Very Slow", InputType=0,sourceMatch=3, sharpness=0.2, tr2=2, ediThreads=1).SelectEven() 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).
__________________
My github. |
5th May 2020, 14:42 | #108 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
|
|
5th May 2020, 16:16 | #111 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,318
|
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: Code:
void nnedi3::copyPad(int n, int fn, IScriptEnvironment *env) { const int off = 1-fn; PVideoFrame src = child->GetFrame(n, env); Now, i need the src to create the dst, so, now, instead of: Code:
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); Code:
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); I've tried Code:
void copyPad(const PVideoFrame &src,int n,int fn,IScriptEnvironment *env); Code:
void copyPad(PVideoFrame src,int n,int fn,IScriptEnvironment *env); I'll try a mix with previous version, copyPad geting src and return it...
__________________
My github. |
5th May 2020, 16:41 | #113 | Link |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,318
|
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.
__________________
My github. |
5th May 2020, 17:00 | #115 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,314
|
Quote:
This one works: int x = field > 1 ? (n >> 1) : n; PVideoFrame src = child->GetFrame(x,env); |
|
2nd August 2020, 14:31 | #120 | Link |
Registered User
Join Date: Jul 2018
Posts: 1,078
|
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. Last edited by DTL; 2nd August 2020 at 18:20. |
|
|