64-bit deflicker
64-bit deflicker
Is there a 64-bit version of Deflicker 1.3 out there? If not, does anyone know how to port it over?
I've posted a paying job here for this: https://www.upwork.com/jobs/~01504982ebad682565
I've posted a paying job here for this: https://www.upwork.com/jobs/~01504982ebad682565
Re: 64-bit deflicker
I'll try to whip it up for you.
Re: 64-bit deflicker
So, it's not just a simple recompilation with x64 target. I have to port the filter to the latest VirtualDub SDK to support 64-bit operation.
An account is needed to see your $$$ offer, but I don't want to create an account. So how much are you willing to pay for this work? It looks like at least 1/2 day's work for me. Send me a PM and we can work it out.
An account is needed to see your $$$ offer, but I don't want to create an account. So how much are you willing to pay for this work? It looks like at least 1/2 day's work for me. Send me a PM and we can work it out.
Re: 64-bit deflicker
Do you have the latest SDK v1.2 ? If not, i can give it to you. The issue is that version of SDK was avaible only on the forum, which has closed...admin wrote:I have to port the filter to the latest VirtualDub SDK to support 64-bit operation.
![Sad :(](./images/smilies/icon_e_sad.gif)
Re: 64-bit deflicker
I have version 1.1 which seems to be good enough for 64-bit development. What does 1.2 bring to the table?
And sure I'd love to have 1.2. Thanks for the offer.
And sure I'd love to have 1.2. Thanks for the offer.
Re: 64-bit deflicker
Since you use the forum, are your old e-mail (if i retreive it) still valid ?
Don't remember exactly what 1.2 brings, it begins to be a little long...![Thinking :scratch:](./images/smilies/icon_scratch2.gif)
Don't remember exactly what 1.2 brings, it begins to be a little long...
![Thinking :scratch:](./images/smilies/icon_scratch2.gif)
Re: 64-bit deflicker
That doesn't work for me. A red circle spins around and then it hangs doing nothing. Am I missing something?jpsdr wrote:Lien : https://mega.nz/#!tAd3GYhb!BKv37-nDuLDS ... t8njHA4-rY
I saw a link suggesting mega only works on Chrome. Is it so?
Re: 64-bit deflicker
Got it, thanks!
[Me too.]
[Me too.]
Re: 64-bit deflicker
Strange, i just tested now with Firefox, it works...
This leads me to the next question : Do you have also the last VirtualDub version, the 1.10.5-prerelease build 35560 ? This one also was avaible only on the forum.
Do you want it ?
![Question :?:](./images/smilies/icon_question.gif)
This leads me to the next question : Do you have also the last VirtualDub version, the 1.10.5-prerelease build 35560 ? This one also was avaible only on the forum.
Do you want it ?
Re: 64-bit deflicker
Sure, that would be great. Thanks for the offer.
- Aleron Ives
- Posts: 126
- Joined: Fri May 31, 2013 8:36 pm
Re: 64-bit deflicker
Mega can be picky if you have NoScript enabled. You have to allow not one, but two different Mega domains in order for the site to work, at least in SeaMonkey.
Re: 64-bit deflicker
Possibly so, but it hung for me also in IE11 with no add-ons or extensions. Judging by the other replies, it was a transient site problem.
Well it may all be moot as our OP has vanished. Funny, you finally find the author and he is motivated to help, but you never come back. Not a total loss, as jpsdr has come through with some goodies for us.
Well it may all be moot as our OP has vanished. Funny, you finally find the author and he is motivated to help, but you never come back. Not a total loss, as jpsdr has come through with some goodies for us.
Re: 64-bit deflicker
Last VDub version : https://mega.nz/#!VJ9j1aQC!lD2fVyRJuVA3 ... xEt51zI2Xk
Re: 64-bit deflicker
Thank you, Sir!
- Aleron Ives
- Posts: 126
- Joined: Fri May 31, 2013 8:36 pm
Re: 64-bit deflicker
Wikipedia mentions that Mega didn't play nicely with IE10, so I guess it's no surprise that it doesn't work with IE11, either.
Re: 64-bit deflicker
So, if i remember properly, it's in the 1.2 that have been added two significant features, with the prefetch possibility.admin wrote:What does 1.2 bring to the table?
Also, on the version i've provided, Phareon has updated all the internal filters to the new sdk 1.2, so, looking at the code may also serves as exemple.
The first is the possibily to change the frame rate inside a plugin. If you want to see how this is done, you can look at my Remove Frame filter in my VDub filters package on my github. This filter is realy simple because it does almost nothing...
![Wink ;)](./images/smilies/icon_e_wink.gif)
It's a decimate function. Never done an increase frame rate (add frames instead of removing). Of course, the default settings of my filter are made to match the settings needed for my IVTC filter.
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
A warning about this kind (decimate here) of feature. If for exemple you have a chain of 4 filters, and you put a decimate filter which remove 1 frame on 2 (half the frames) on 3rd positions, it will nevertheless impact the whole filter chain. If, like me, you were expecting that the filters before the decimate will receive all the frames on their input, and only the filters after the decimate will receive only half the frames, big mistake ! (My IVTC filter to work properly needs all the frame in the correct order on the input).
It seems that before doing the process, VDub run the whole video "at blank", just to check what frames will realy be needed, and then, after, during the process, send to the chain filter only the frame needed. So, if you have a decimate 1/2 in the chain, the whole chain will finaly receive only 1/2 frames, unless...
- You trick VDub like i've done in my Remove Frame filter, to make it beleive you'll need all the frames in input.
- In the filter chain you have a filter with LAG feature, but don't know exactly if it's just the fact of being present, or if there is some rule including the value of the lag.
The second is the possibility to have access to "any" input frame you want. If you filter needs to work with previous and/or next frames, no need anymore to have an internal buffer to store them. And if you needs next frames, also no need anymore to use the LAG feature. With the prefetch feature, when in the Run function you are processing the frame N, you can also have access to the N+i or N-i input frame. If you need also to have access to previous output frames, that i don't know if you also have the possibility, or if you have to handle it yourself with an internal buffer.
Again, for exemple, you can check my filters on my github, or also look at the code of some internal filters of VDub.
I don't remember exactly in how detail these features are explained in the sdk doc.
These features are interesting and greatly help the filter developpement. But, as far as i know, i think that if you're using this features, your filter cannot be load anymore in avisynth.
Re: 64-bit deflicker
Thanks for the valuable information, jpsdr. That lack of decimation capability was what made me have to resort to the goofy method I used for my original decimate filter, and was what made me transition almost exclusively to Avisynth. It seems that from what you say the current solution may still be somewhat deficient.
Re: 64-bit deflicker
No, it's just a choice made by phaeron to do things that's way, if you're talking about the fact that the whole filter chain is impacted. You just have to know how it works.admin wrote:It seems that from what you say the current solution may still be somewhat deficient.
For a decimate filter 1/2 filter, standard no trick method, it will happen the following :
Code: Select all
const VDXFBitmap& pxsrc = *fa->mpSourceFrames[0];
Filter Chain :
A
B
C -> This one is decimate, it output only odd numbers of pxsrc.mFrameNumber (0,2,4,...).
D
So, when you're doing the process, A,B and C will receive only 50 frames, the ones for which pxsrc.mFrameNumber is 0,2,4...
And if in A,B,C you display/check the value of pxsrc.mFrameNumber, you'll see that the 1rst frame will have 0, the 2nd 2, the 3rd 4, the 4th 6, the 5th 8, etc... until 98.
And, in D, if you display/check the value of pxsrc.mFrameNumber you'll have 0,1,2,3 etc... until 49.
Phaeron choose this way of doing things to optimize/reduce the process time. It's a waste of time to process a frame, if it has do be finaly discarded in the chain. Seeing like this, it makes perfect sense. 99.9999% of the time, there will be no unwanted effect. It's just me, having a very specific case, who has been bothered by this way of doing things.
But again, the critical part is you have to know this is how it will work. But, as you can see in my Remove Frame, there is a way to trick and make VDub send all the frames, but it must have to be necessary, otherwise it will just result in a increased process time for nothing.
Re: 64-bit deflicker
Thanks for the clarification, but a reasonable decimate filter is going to want to decide based on the previous processing of a frame whether or not it should be decimated. So it still looks brain-dead to me. Please clarify matters if I am wrong about it.jpsdr wrote: Phaeron choose this way of doing things to optimize/reduce the process time. It's a waste of time to process a frame, if it has do be finaly discarded in the chain. Seeing like this, it makes perfect sense. 99.9999% of the time, there will be no unwanted effect.
Re: 64-bit deflicker
Hum... By decimate, we agree you want to change the frame rate, and so you'll remove frames according a proper repetive pattern, you'll not create a total thing. Maybe if you'll explain within a few lines what exactly your decimate filter do (and very roughly the algorithm if choice have to be made) or what you want to do ?
If there is parameters, you can explain to me with an exemple of a fixed value.
Don't forget that you can request previous and next frames also. For exemple, if you want to decimate by 4, choosing to output a mix of the current and previous frames. You'll do the following :
So, in Getparams, you'll tell that you'll reduce the number of frame by 4. Your 100 frames video, will be 25 frames.
In Prefetch2, you'll tell, what input number frame you want for what ouput. VDub will first run Prefetch2 will all the values of frame to build a table i think.
So, here, you're saying that for output frame number 0, you want input number 3, and 2. For output frame 1 you want 7 and 6, etc...
So, in your Run function, when you'll process your ouput frame number 0, you'll have in the buffer the input frame 2 and 3, etc...
So, if we stay like this, VDub will find that it only needs the frames 2,3,6,7,10,11, etc...
So, the previous filters in the filter chain will only receive the frames 2,3,6,7,10,11, etc... The frames 0,1,4,5 etc... will never be send to the process chain, beacause VDub identified that they were not needed (assuming all the other filters in the filter chain before and after the decimation are "nice" filters needing only the current frame, and don't change frame rate or anything else, to keep the exemple simple and clear).
If there is parameters, you can explain to me with an exemple of a fixed value.
Don't forget that you can request previous and next frames also. For exemple, if you want to decimate by 4, choosing to output a mix of the current and previous frames. You'll do the following :
Code: Select all
uint32 YOURFILTER::GetParams()
{
const VDXPixmapLayout& pxsrc = *fa->src.mpPixmapLayout;
VDXPixmapLayout& pxdst = *fa->dst.mpPixmapLayout;
int64_t frame_count_h,frame_count_l;
VDFraction fr(fa->dst.mFrameRateHi, fa->dst.mFrameRateLo);
fr *= VDFraction(1,4);
fa->dst.mFrameRateHi = fr.getHi();
fa->dst.mFrameRateLo = fr.getLo();
frame_count_h=fa->dst.mFrameCount/4;
frame_count_l=((fa->dst.mFrameCount%4)>=2) ? 1:0;
fa->dst.mFrameCount=frame_count_h+frame_count_l; <- Here, you'll tell how number of total frame you'll output, changing the value
return(FILTERPARAM_SUPPORTS_ALTFORMATS);
}
bool YOURFILTER::Prefetch2(sint64 frame, IVDXVideoPrefetcher *prefetcher)
{
prefetcher->PrefetchFrame(0,(frame << 2)+3 ,0); <- Here, you tell what input number frame you want for the oupout.
prefetcher->PrefetchFrame(0,(frame << 2)+2,0); <- Here, you tell that you'll want also the previous frame.
return(true);
}
In Prefetch2, you'll tell, what input number frame you want for what ouput. VDub will first run Prefetch2 will all the values of frame to build a table i think.
So, here, you're saying that for output frame number 0, you want input number 3, and 2. For output frame 1 you want 7 and 6, etc...
So, in your Run function, when you'll process your ouput frame number 0, you'll have in the buffer the input frame 2 and 3, etc...
So, if we stay like this, VDub will find that it only needs the frames 2,3,6,7,10,11, etc...
So, the previous filters in the filter chain will only receive the frames 2,3,6,7,10,11, etc... The frames 0,1,4,5 etc... will never be send to the process chain, beacause VDub identified that they were not needed (assuming all the other filters in the filter chain before and after the decimation are "nice" filters needing only the current frame, and don't change frame rate or anything else, to keep the exemple simple and clear).
Re: 64-bit deflicker
There is no fixed pattern other than that I know the desired output frame rate. For example, I want to remove n frames out of every m frames and I determine which n frames to remove by comparing every frame to its preceding frame (before decimation).
Re: 64-bit deflicker
You want to remove 2 frames each 5 frames.
The input is 20 frames :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Can you tell me how you'll process the 20 frames, what number you'll compare with for each frame, and what will be the ouput criteria ?
How do you limit ? Are you working by "package" ? In that case, for exemple are you doing frames 0 to 4, then 5 to 9, etc...?
Something like this :
Input Frame : 0
Compare 0 and 1, and if Ok ouput 0 else ouput nothing.
Input Frame 1 :
Compare 0 and 1 and 2 and if Ok ouput 1 else ouput nothing.
The input is 20 frames :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Can you tell me how you'll process the 20 frames, what number you'll compare with for each frame, and what will be the ouput criteria ?
How do you limit ? Are you working by "package" ? In that case, for exemple are you doing frames 0 to 4, then 5 to 9, etc...?
Something like this :
Input Frame : 0
Compare 0 and 1, and if Ok ouput 0 else ouput nothing.
Input Frame 1 :
Compare 0 and 1 and 2 and if Ok ouput 1 else ouput nothing.
Re: 64-bit deflicker
Something like that. For my Avisynth Decimate filter, n is fixed to 1 and m is variable. For tritical's TDecimate filter, both n and m are variable. Either way, the n frames closest to duplicates are removed. This requires every frame to be examined.