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.

[admin]

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.

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]

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 :

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);
}

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).

[admin]

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).

[jpsdr]

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.

[admin]

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.

[jpsdr]

Something like that.

... Well, you have the exemple i've described, as i said, you can request several previous/next frames when you process a frame (allowing to cover all the frames), so it's absolutely possible to do your decimate filter. For exemple, just by going by pack of m frames. I assume that in each m frames pack, you allways remove n frames. You're not realy totaly random, you're not for exemple removing no frames during 3*m frames, and suddenly removing 3*n frames in continous.
So, you'll have to think a little how to do according the way it works in VDub, but it's totaly possible.
Can't give more precise advices with just "Something like that"...

[admin]

I did specify exactly what I wanted. The "something like that" was to denote that it didn't match exactly what you described.

Given what you said, I would have to ask if you are sure that VirtualDub will cache M frames, so that they need not be recalculated. Do you know the answer?

I'm not seriously intending to implement this, but I am interested theoretically.

[jpsdr]

Given what you said, I would have to ask if you are sure that VirtualDub will cache M frames, so that they need not be recalculated. Do you know the answer?

I don't know how internaly VDub does things, so, no...