VirtualDub: Correcting Field Order and Swapping in Interlaced Sources

ozjeff99 · #1 05-14-2003, 08:26 AM

I was asked by friend Boulder in previous topic about this and thought it needed a different heading. These are a couple of things I do that may be of interest to some people, obvious to others. Whilst this refers particularly to captures it can apply to any true interlaced clip. Purpose is to generate an Avisynth script to correct field order spacially and temporally with Vdub's help. Without fixing this first it can ruin what you do from that point on.

a. Correct field orientation spacially:
I check this on any capture. I generally capture in Vdub using 352x576 in Preview mode to get both fields. Opening file in Vdub I briefly apply the Field Swap filter to make sure output video is indeed worse at several points along the stream. If it is better, then I use FieldSwap() in Avisynth script to correct. It is obviously essential that lines 1,3,5… etc in the captured frames (ie. Top Field) correspond to 1,3,5..of the source. Capture cards can get this wrong sometimes. Usually it is OK but well worth checking.

b. Correct and determine field orientation temporally (field order):
I use if using a Deinterlacer that needs to know field order (TomsMoComp) or if maintaining interlacing in SVCD encoding where encoder also needs to know. I think it is a good thing to clean up regardless.

This is where things can go horribly wrong since the capture card can indiscriminantly drop fields and pairing in frames gets out of whack.

Lets say Source frames have bottom field ahead of top (bff) in time but the captured frames, due to a phase shift, now have frames where the top field is ahead of the bottom (tff). If there is no Top Field First Flag (TFF) set in the captured file (generally not) then Avisynth assumes BFF and gets it wrong. ie it serves fields which are behind, in time, the one following. If a TFF or BFF flag is actually set in the captured file and it is wrong, same problem. If you get a combination of these then you are in the pooh (in a Tolkein way of course

).

I tend to trust my eyes on fixing this rather than programs.

OK some steps on a real example:

1. Cap.avi is an actual test capture. Firstly I used this:

z="c:\cap.avi"
AviSource(z)
AssumeFrameBased()
SeparateFields()

In Vdub you see the fields individually being served BFF irrespective of what the order they actually should be or what Cap.avi file flags might say. Moving slider slowly forward you will either see a smooth transition or a forward and back motion (guess what it should be

). The latter is where the frames contain the top field ahead of time.

In my actual example Cap.avi, using above script the first half of clip was jerky and the second was smooth. I'm not joking, this was an actual capture!! I noted the transition point was at field 400 (ie. Frame 200 in clip z).

2. Here is the script which fixed the first half and gave me a final clip which was actually BFF all the way through and served that way. Use SeparateFields() at the end to double check in Vdub the flow of final clip.

z="c:\cap.avi"
AviSource(z)
AssumeFrameBased()
a = Trim(0, 200).
\ComplementParity().
\SeparateFields().
\Trim(1,0).
\Weave
b = Trim(201, 0)
a + b
#SeparateFields() #Use to double check

Note that Trim(1,0) deletes one field and Weave() restores correct phasing in frames.

Now you can tell your deinterlacer (or Tmpgenc if SVCD encoding) what the field order is with confidence.

A reminder: What the field order actually is, what the file flags say and what Avisynth assumes can be 3 different things. Trust your eyes.

Feedback welcome
Ozjeff99

Boulder · #2 05-14-2003, 10:01 AM

Thanks, I'll have to do some tests on my captures later this week. My caps have always worked out fine as BFF so it's going to be interesting to see how the tests show them to be IRL

ozjeff99 · #3 05-14-2003, 10:30 PM

Hi Boulder. I see you have a bit of experience in filtering captures. What works best for you. Any scripts welcome.

Cheers
Ozjeff99

Boulder · #4 05-15-2003, 10:15 AM

This is something I've been using on my Star Trek TOS captures, shot on film and converted from NTSC to PAL, captured at 720x576:

Code:

LoadPlugin("c:\avs25\cnr2.dll")
LoadPlugin("c:\avs25\dctfilter.dll")
LoadPlugin("c:\avs25\decomb.dll")
LoadPlugin("c:\avs25\undot.dll")
LoadPlugin("c:\avs25\stmedianfilter.dll")
SegmentedAVISource("c:\temp\captures\trek.avi")
Trim(320,23150) ++ Trim(26100,59749) ++ Trim(62299,76950).Fadeout(250)
KillAudio()
Telecide()
Crop(0,0,-0,-6)
UnDot()
BilinearResize(480,512)
CNR2(mode="ooo")
MergeChroma(Blur(1.5))
MergeLuma(Blur(0.2))
STMedianFilter(8,15,4,7)
AddBorders(24,32,24,32)
DCTFilter(1,1,1,1,1,0.5,0.5,0)
Limiter()

I usually use a similar script for all my captures, using Telecide was recommended by bb, a moderator at the Doom9 forum, he's from Germany and had also been working on an ST:TOS TV capture. So if the source is known to be originally PAL, I use TomsMoComp.

I use AVS2.5 but you can do the same things with AVS2.0x as well.

Funny thing though, I captured the clip using the Morgan Multimedia MJPEG codec, a beta version which is supposed to capture correctly in YV12, and there are no combing artifacts

If I capture in YUY2, they sure are there..

ozjeff99 · #5 05-15-2003, 10:46 AM

Thanks Boulder. I'll definitely give yours a try. I'm not sure about Telcide for PAL as I understand that it should not be used on truly interlaced video. I can see that it could match up wrong fields to minimise combing and actually mess up an interlaced stream. This is what you want for a phase-shifted or telecined progressive stream however. I guess it always comes back to checking the source in Vdub first before doing anything to check what you have. I'll check this out further. Is bb the founder of Convolution3d?? If so he obviously knows what he is talking about.

Not sure what is going on with your YV2 capture? Could be only capturing one field.

Thanks again

Boulder · #6 05-15-2003, 11:13 AM

Quote:

Originally Posted by ozjeff99

Thanks Boulder. I'll definitely give yours a try. I'm not sure about Telcide for PAL as I understand that it should not be used on truly interlaced video. I can see that it could match up wrong fields to minimise combing and actually mess up an interlaced stream. This is what you want for a phase-shifted or telecined progressive stream however. I guess it always comes back to checking the source in Vdub first before doing anything to check what you have. I'll check this out further. Is bb the founder of Convolution3d?? If so he obviously knows what he is talking about.

The founder of Con3d is Vlad59 IIRC. I don't know if bb has written any AVS filters but I do trust his word on this one. He actually discussed this with Donald Graft (a.k.a. neuron2) who surely knows everything about these things.

Quote:

Not sure what is going on with your YV2 capture? Could be only capturing one field.

See the pics here:

http://www.cc.jyu.fi/~camneely/yuy2.jpg
http://www.cc.jyu.fi/~camneely/yv12.jpg

sh0dan did test the codec as he's the one who reported a field doubling bug to the people at Morgan Multimedia and he said that it does work fine. If you want to test it, look for it at the Morgan Multimedia website forum, there's a thread regarding the matter.

ozjeff99 · #7 05-15-2003, 11:10 PM

Hi Boulder

Thought my memory was right on this one (convolution3d):

Quote:

Vlad would like to thank bb from the Doom9 forums for the original idea and test cases.

The top photo maybe field-swapped rather than interlaced. Check in Vdub.

You obviously need to know that the codec is not spacially smoothing an interlaced source. Is the Codec lossless? I always use Huffy to ensure that the video does not contain any compression artifacts prior to processing and encoding. Disk space is cheap these days.
ozjeff99

Boulder · #8 05-16-2003, 12:48 AM

Ah, I should have remembered..I didn't even remember that bb suggested the other matrix in Con3d. My brain has to be punished - again

I played some more with the codec yesterday and now I got combs in the video. I just tried disabling interleaving (interleaving is supposed to capture both fields), did a test capture, enabled interleave and tried again. If interleaving is disabled, the other field is just discarded and the other duplicated to get two fields. Somehow disabling and then enabling interleaving got the codec working correctly. I think it could be that some settings were not being set correctly (beta version) and this fixed the problem.

Anyway, here's a snapshot from the HuffYUV capture, done at the same time as the others:

http://www.cc.jyu.fi/~camneely/huffyuv.jpg

Here's my ST:TOS cap before I got things fixed:

http://www.cc.jyu.fi/~camneely/trek.jpg

When I check the field order of that clip, there's no jerky motion in TFF or BFF!

MJPEG is a lossy compression method, basically the codec encodes the source into JPEG pics. However, my quality settings are very high so it's nearly lossless. At least you can't tell the difference between a HuffYUV capture and a HQ MJPEG one. If I had digital source, things would probably be different.

vhelp · #9 05-16-2003, 01:09 AM

@ boulder,

Don't you just HATE it when they plaster those logos on our clip ??

We suffer this nonsense way over here in usa too - - sucks big time!!

Quesiton..
What "codec" does vdub reports when you open your YV12 captures in it ??

I have been doing some confusing research on YV12 captures, and..

I've ben messing w/ YV12 captures under vdub and avi_io but when I try
to open them, I get an error about an I420 missing codec or something,
which confuses me. But, I have what I believe one of the ATI codecs that
I think opens it sort of incorrectly and reports an YUV 4:2:0 (I420) codec
under vdub 1.3c, but any other vdub version won't open any of these YV12
captures. So, this is puzzeling me a bit.

If you (or anyone else) knows this phenomina, any help would be appreciated.. thanks.
-vhelp

Boulder · #10 05-16-2003, 02:21 AM

Quote:

Originally Posted by vhelp

@ boulder,

Don't you just HATE it when they plaster those logos on our clip ??

We suffer this nonsense way over here in usa too - - sucks big time!!

Actually, I don't mind. It's fun to watch the clips after years and notice that the channel has changed its name a thousand times during that period and yet most of the stuff they broadcast is still pure crap

Quote:

Quesiton..
What "codec" does vdub reports when you open your YV12 captures in it ??

It says Morgan Multimedia MJPEG codec or something like that. In fact it's the only MJPEG codec I've installed. I use a Win98 system for captures and have kept it very clean and simple.

Quote:

I've ben messing w/ YV12 captures under vdub and avi_io but when I try
to open them, I get an error about an I420 missing codec or something,
which confuses me. But, I have what I believe one of the ATI codecs that
I think opens it sort of incorrectly and reports an YUV 4:2:0 (I420) codec
under vdub 1.3c, but any other vdub version won't open any of these YV12
captures. So, this is puzzeling me a bit.

I guess that the Morgan codec I'm using is the only one that is able to capture in YV12, although I think that DivX5 and XviD should be able to do that too since they are natively YV12 themselves. You must use the beta version because a field doubling bug was fixed from the v3.0.0.9. sh0dan says it works OK so I think it really does