Problem with Kurosu's TPRIVTC...

[leowong1]

I've been using TPRIVTC for a long time and it always works well. However, I always have a problem when using the deinterlac function of TMPGENC. When I just use the IVTC function , avs loaded properly. It seems that avisynth cannot load the deinterlaced frame properly and it always gives a result like this:

http://img.photobucket.com/albums/v328/leowong1/error.jpg

With reference to Kurosu's tprivtc thread [http://forum.doom9.org/showthread.php?s=&threadid=44854 ], it should supports a deinterlace mode called 'Double'. I chose to deinterlace as 'Double' as shown in this picture:

http://img.photobucket.com/albums/v328/leowong1/tmpgenc.jpg

Can anyone tell me what did I do wrong? And can anyone please give me a solution? I've been dealing with this annoying problem for a long time and I've tried lots of method. Hope to get an prompt reply. And I say a 'Thank you' to those who help.

[leowong1]

Bump

[Wilbert]

Please, don't bump after a day. (Sorry, I can't help you with your problem.)

[leowong1]

Second bump

[leowong1]

third cump

[leowong1]

wanna ask does anyone have the same problem as mine?

[Wilbert]

I encourage you to bump one more time. Btw, why don't you send Kurosu a pm (since no one responds here)?

[Zarxrax]

Switch to YATTA.

[leowong1]

YATTA is not as good to be honest...
And also, there are no tutorials for the latest version of Yatta.
BTW, I think Kurosu has left the doom9 forum, so pmming him won't help.

[Kurosu]

pms often send an email to the user, so I could have probably been reached. On that one though, you owe Wilbert one for reaching me instead.

I don't have MSVC anymore but from the code I can spot those problems:
- the iSSE code uses pavgusb which is AMD only. pavgb should work
- anyway, the iSSE code was never finished, so it should be deactivated.

I'll try to grab the free compiler and see how it can be compiled. I don't think I will be able to generated a DLL though.

[Kurosu]

OK, I managed to build it (http://kurosu.inforezo.org/avs/tprivtc.dll).

[leowong1]

I'm glad to know Kurosu still here. BTW, that means the latest dll generated by u have solved the problem?

[leowong1]

I just tried the latest version. It worked very well. I thank Kurosu for this great filter.

[DarkNite]

Did you seriously just say YATTA is not as good?

If you're looking for a manual you should try reading the changelog (it's like a manual), and the YATTA key definitions file. After that you might want to try the irc channel, or the forum.

Just because you fail to understand something does not mean it is inferior.

@Kurosu

Good job on the quick fix.

[leowong1]

i can only say, using yatta to do manual ivtc is more complicated than tmpgenc. tmpgenc is easy and efficient:)

[Dreassica]

I'm getting a unknown ivtc method: N-47 when i load a tpr file through avisynth using this plugin. Anyone know where the error lies?

PS it only gives me the error when i use dll that supposedly fixed Leowongs problem. if i use the one of mf's avs dumpster it loads, only i get teh infamous green frames again (not exactly like my old bugreport).

[Kurosu]

The known deinterlace modes (hexadecimal codes, fire up calc.exe if you can't figure them out):

/********** TMPEG IVTC Modes ************/
#define MODE_NONE 0x00 //no deinterlacing

#define MODE_EVEN 0x01 //even field
#define MODE_EVEN_AD1 0x02 //even field (adaptation)
#define MODE_EVEN_AD2 0x03 //even field (animation adaptation)
#define MODE_EVEN_AD3 0x0C //even field (animation adaptation 2)

#define MODE_ODD 0x04 //odd field
#define MODE_ODD_AD1 0x05 //odd field (adaptation)
#define MODE_ODD_AD2 0x06 //odd field (animation adaptation)
#define MODE_ODD_AD3 0x0D //odd field (animation adaptation 2)

#define MODE_DBLE 0x07 //double
#define MODE_DBLE_AD1 0x0F //double adaptation
#define MODE_DBLE_AD2 0x08 //double field
#define MODE_DBLE_AD3 0x10 //double (field,adaptation)

#define MODE_ODDEVEN 0x09 //odd/even
#define MODE_OE_AD1 0x0A //odd/even (adaptation)
#define MODE_OE_AD2 0x0B //odd/even (field,adaptation)
#define MODE_OE_AD3 0x0E //odd/even (field,adaptation 2)
/********** End TMPEG IVTC Modes ************/


and the mapping done by the filter:


switch(mode)
{
case MODE_NONE: //no deinterlacing
Mode[i] = MODE_NONE;
break;

case MODE_EVEN: //even field
case MODE_EVEN_AD1: //even field (adaptation)
case MODE_EVEN_AD2: //even field (animation adaptation)
case MODE_EVEN_AD3: //even field (animation adaptation 2)
Mode[i] = MODE_EVEN;
break;

case MODE_ODD: //odd field
case MODE_ODD_AD1: //odd field (adaptation)
case MODE_ODD_AD2: //odd field (animation adaptation)
case MODE_ODD_AD3: //odd field (animation adaptation 2)
Mode[i] = MODE_ODD;
break;

case MODE_DBLE: //double
case MODE_DBLE_AD1: //double adaptation
case MODE_DBLE_AD2: //double field
case MODE_DBLE_AD3: //double (field,adaptation)
Mode[i] = MODE_DBLE;
break;

case MODE_ODDEVEN: //odd/even
case MODE_OE_AD1: //odd/even (adaptation)
case MODE_OE_AD2: //odd/even (field,adaptation)
case MODE_OE_AD3: //odd/even (field,adaptation 2)
Mode[i] = MODE_EVEN;
break;

default:
env->ThrowError("TPIVTC: Unknown IVTC mode number %i", mode);
}


So nothing comes close to mode = 47, as you may figure.

Maybe a new mode for later versions or a 'replace by frame' deinterlace method, for which I had a request, but I got bored of development before I came to that. Many things aren't implemented and I don't even remember what is actually left unused in the file format.

[Dreassica]

Well it works using the old green frame outputting versions. New ones it give sme taht weird error. Not exactly N-46, more as ine N--46 ro something. AFAIK it doesnt use any weird deinterlacing options in tmpgenc which could cause it.

[acrespo]

Can I use files saved in TMPEG 3.0?

[wolfsoft]

Originally posted by acrespo
Can I use files saved in TMPEG 3.0?

I don't like this ver. It looks like that you can't make a manual IVTC again...