64-bit deflicker

[jpsdr]

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 ?

[admin]

Sure, that would be great. Thanks for the offer.

[Aleron Ives]

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.

[admin]

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.

[jpsdr]

Last VDub version : https://mega.nz/#!VJ9j1aQC!lD2fVyRJuVA3 ... xEt51zI2Xk

[admin]

Thank you, Sir!

[Aleron Ives]

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.

[jpsdr]

What does 1.2 bring to the table?

So, if i remember properly, it's in the 1.2 that have been added two significant features, with the prefetch possibility.
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...
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.
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.

[admin]

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.

[jpsdr]

It seems that from what you say the current solution may still be somewhat deficient.

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.

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];

Video 100 frame, 0 to 99
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.