Best method for deinterlacing

[poisondeathray]

Go through all the steps in this thread. Make sure you replace the .dll
http://forum.doom9.org/showthread.php?t=148782

[manono]

Same thing, it says the problem is with line 3 anyway, which is the first one...

Didn't understand that, but the third line in your script is the first SetMTMode line. LoadPlugin lines and commented out lines are counted. With the line either removed or commented out you still get the same error message? Not sure I believe that.

Maybe it isn't important, but that first 'SetMTMode(5, 3)' is supposed to be at the very top of the script, even before any LoadPlugin lines.

[ROBO731]

The issue was that I was on avisynth 2.5 when I originally replaced the avisynth.dll, but when I upgraded to avisynth 2.6 I forgot to replace the dll. It's working now.

[ROBO731]

So the program crashed again towards the end, it may have actually finished, but crashed upon finishing. If it didn't finish completely then it was at least very close because the last time I had checked it, it was at 95%. Could there be something wrong with my x264?

[poisondeathray]

So the program crashed again towards the end, it may have actually finished, but crashed upon finishing. If it didn't finish completely then it was at least very close because the last time I had checked it, it was at 95%. Could there be something wrong with my x264?

Unlikely to be x264 issue

1) Make sure there is nothing wrong with the video. If it crashes at the end all the time, that might suggest a problem with the video. Try encoding a fast yadif script. This will rule out video errors, possible x264 binary issues

2) How much memory do you have ? The other common issue causing MT crashes is low memory. It's unlikely to be a problem with SD video, but tun taskmanager and see how much you are using during encoding compared to how much is free. The slower the settings (esp. with x264), the more memory requiredfor lookahead. Also QTGMC requires quite a bit. If memory is an issue , you might have to use SetMemoryMax() , or divide up the filtering and encoding into stages (e.g. using a lossless intermediate)

I wouldn't use such slow settings (for QTGMC and x264) until you get the hang of it / fix your setup and successfully do some encodes. Especially not for initial debugging

[ROBO731]

Ok, well memory definitely isn't an issue. I ran the same encode and I watched it very closely, it finished the encode and immediately after finishing and displaying the final information it crashed. I'm going to try using a different video. If I encounter the same issue, I'll post a more relevant thread. Thanks for all the help.

[manono]

I get that livelock problem (if using VDub), too, from time to time. As long as the encoding has completed I don't worry about it.

[ROBO731]

Yeah, I figure if it's not interrupting the process then, it doesn't matter. One last question. When I demux the files with DGindex, at the end it says that there's a field order transition. Is there a way for me to check where the transition is in the d2v file? When I opened the d2v file, it seems to change from "b2 b2 a2" to a few different formats throughout the file. I'll attach it, just change the extension from log back to d2v if you need to. If I correct it, how will it affect the video?


Hopefully this will be last thing I need to sort out.

[manono]

Good question and I don't think there's an easy answer. I usually answer 'yes' to the question. But then I'll go through the video carefully to make sure everything looks alright *. If it's a long video it's hard to find the place where the transition took place and if it affects anything. It might not in which case it doesn't matter what you answer (unless using TIVTC, which will insist you fix the D2V).

Someone else might know more about it, but I've rarely had a problem after answering 'yes'.

* Not looking alright means that forward/backward jumping around stuff indicative of the wrong field order.

[manono]

double answer.

[ROBO731]

I had originally said no to it, and the encoded files came out fine. It'd probably be difficult to find the spots where these transitions happen since there's not time codes.

Here's a log that it opened after I said yes, it details the sections that it adjusted:

D2V Fix Output

Field order transition: 0 -> 2
d00 5 0 215439360 0 0 0 90 a0 a0 a0 a0 a0
d00 5 0 215513088 0 0 0 b2 92 b2 b2 a2 a2 a2 a2 a2 a2 a2 a2 a2 a2
corrected...
d00 5 0 215439360 0 0 0 90 a0 a0 a0 a0 a1
d00 5 0 215513088 0 0 0 b2 92 b2 b2 a2 a2 a2 a2 a2 a2 a2 a2 a2 a2

Field order transition: 2 -> 0
900 5 0 434833408 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2 a2 a2 a2 a2 a2 a2 a2 a2 a2 a2
d00 5 0 435488768 0 0 0 90 a0
corrected...
900 5 0 434833408 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2 a2 a2 a2 a2 a2 a2 a2 a2 a2 a3
d00 5 0 435488768 0 0 0 90 a0

[ROBO731]

Is it necessary to specify tff or bff for QTGMC? Can't it just detect which field order it is from the d2v? It doesn't say anything in the manual about setting field order, so I'm wondering if it can detect it, then it would be able to deinterlace the transitions without a problem.

[jagabo]

Is it necessary to specify tff or bff for QTGMC? Can't it just detect which field order it is from the d2v?

Yes: Mpeg2Source("filename.d2v", info=3).

[ROBO731]

Well, I mean, can it detect the field order transitions or can it only detect the dominant/original field order?