IT 1.2 (ported)

[MeteorRain]

https://github.com/msg7086/VapourSynth-IT

Latest: v1.2

Ported from original IT filter.

It did a very good job and is my favorite ivtc filter. So I did a copy-and-paste style partial porting.

8K width is supported thanks to a patch.

Now support Linux. Clang versions appear to be faster.

[turbojet]

Interesting blast from the past, this used to be my favorite ivtc too but then I noticed in some videos there was issues with scene changes, tivtc and decomb handle these same videos fine. Could the thread-safe fix this? I don't have any samples to test anymore but it happened on a substantial amount of dvd's.

[MeteorRain]

TBH I never observed such problems under linear seeking condition. If someone can find such samples....

[Myrsloik]

You should change all lines like this in the code:

(int)vsapi->propGetInt(in, "fps", 0, &err); => int64ToIntS(vsapi->propGetInt(in, "fps", 0, &err));

I see this is one of the hopeless filters with no C code at all in many places... Will you try to remove all the inline asm as well? I see that most places at least have comments saying what the asm is supposed to be doing (which of course isn't always true).

[MeteorRain]

Originally Posted by Myrsloik

You should change all lines like this in the code:

(int)vsapi->propGetInt(in, "fps", 0, &err); => int64ToIntS(vsapi->propGetInt(in, "fps", 0, &err));

I did a quick Google only to find this post itself. Any hints?

Originally Posted by Myrsloik

I see this is one of the hopeless filters with no C code at all in many places... Will you try to remove all the inline asm as well? I see that most places at least have comments saying what the asm is supposed to be doing (which of course isn't always true).

I tried to rewrite some inline asm into intrinsics, but it appears to be slower. Mixing SSE with MMX might be the cause. Maybe I'll look into that later. That's a large code base to me and I'm not that familiar with C/C++, and even ASM, and image processing, and etc..

[TheFluff]

Originally Posted by MeteorRain

I did a quick Google only to find this post itself. Any hints?

http://www.vapoursynth.com/doc/api/v...ml#int64toints

Avoid plain old C casts if possible, especially if they actually change the data (like in this case, an integer width reduction). In general in C++ if you really really do need to cast you should probably use static_cast<typename>(), reinterpret_cast<typename>() and friends instead. See http://stackoverflow.com/questions/1...nstead-of-intx and http://stackoverflow.com/questions/3...t-cast-be-used

[Myrsloik]

The main problem is that all of these simply truncate the value. If someone passes 0x100000000 it will appear to be 0. Obviously no one really expects this behavior which is why int64ToIntS is provided to provide saturated values. (as in, return the closest value representable by an int instead of the usually 32 lowest bits)

[MeteorRain]

Nice guide, thanks @TheFluff! I'm quite new to the plusplus world.

@Myrsloik Thanks for letting me know. I will try to improve the code.

=====

And I have uploaded v0.3.

[MeteorRain]

So I'm experimenting on the asm code.

===
nvm

What version of the IT source code did you base your port off of? Just so I can have a reference.

If you want, I can try to help you fix up and clean up your port so it compiles outside of VC++. I will start by getting rid of all your macros and reimplementations of Avisynth interfaces to make your code look less awkward. Then before trying to recreate the assembly, the focus should be on just getting plain C code for everything then try to optimize with assembly intrinsics from there after doing some profiling.

[MeteorRain]

I have rewritten all inline asm code into both C and SSE intrinsics. I have carefully compared the results to ensure they are binary identical translation.

[Selur]

doesn't work at all in 64bit for me