I cannot get the field order correct

[drinklime]

About a year ago I captured some AVI files of TV shows from the S-Video output on my cable box. It was captured with VirtualDub on either an Nvidia or ATI VIVO port.

My problem is this: I have never been able to encode them as MPEG2 without either of two things happening: either the video jumps up and down, or the video plays the fields out of order. In other words, if I watch the resulting DVD on my tv and step forward frame-by-frame, the picture shifts up and down each frame, or every two frames are swapped, depending on my field order settings. Right now I am trying with CCE SP, and last year I was trying with TMPEGenc, but I just cant get it right.

When I encoded the same source files as DIVX, I used the steps on 100fps.com and using the Deinterlace-Smooth filter, I had to use the following settings in the AVISynth script to get a 60 fps video in order without the jumping:

AVISource("cops6nocomm.avi")
ComplementParity
SeparateFields

Then in Smooth Deinterlace config, I had to select "Alternate Field Order"

So if anyone could tell me how I could correctly encode an MPEG2 from the interlaced source videos, I would really appreciate it. I am guessing I need a combination of settings to get it right.

[Baldrick]

please post converting questions in our conversions forum. moving you.

[jagabo]

You shouldn't be deinterlacing at all. Just capture, determine the field order, tell the MPEG encoder what the field order is, encode as interlaced MPEG2, author a DVD.

[drinklime]

I am not deinterlacing the video. I simply pointed out the two settings I had to change when I did deinterlace the videos when I was using them for something else. My problem is that I am unable to encode an interlaced MPEG from the original interlaced AVI's without the picture either jumping or playing out of order. How can I fix this?

[drinklime]

I just had an idea... since encoding top field or bottom field both seem "broken," I am guessing the original AVI's have the problem. I did encode them as Huffyuv, and I just looked and noticed an option "Swap fields on decompress (for people with broken capture drivers)." Could that be it? Could I re-encode these Huffyuv's with the option unchecked again as Huffyuv with this option checked without losing anything?

[jagabo]

There's only two possible field orders so one or the other should work.

If you want to verify the field order create an AVISynth script with something like:

WhateverSource("video.ext")
AssumeTFF()
BOB()

Then play that with a media player or open it in VirtaulDub. If it plays smoothly it's TFF. If it's jerky it's BFF. If you always see two nearly identical frames in a row it's progressive. Note that BOB() will create a small up/down bounce on video with sharp horizontal edges. That's not an issue when just determining the field order.

Some encoders have options for both the source field order and the output field order. (This would allow you to convert from one to the other if you want.) Be sure both are set correctly. And make sure the DVD authoring software identifies the field order correctly.

I've used both TMPGEnc and CCE -- both can deal properly with either TFF or BFF files. Note that TMPGEnc often guesses the source field order wrong (AVI doesn't have a field order flag in the header) so you should set it manually on the Advanced tab of the Settings dialog.

Be careful with any filtering that will disturb the field relationship. An example would be cropping an odd number of scanlines off the top of the video -- that will reverse the field order. Generally you should mask rather than crop to remove noise around the edges of the frame.

[jagabo]

I just had an idea... since encoding top field or bottom field both seem "broken," I am guessing the original AVI's have the problem. I did encode them as Huffyuv, and I just looked and noticed an option "Swap fields on decompress (for people with broken capture drivers)." Could that be it? Could I re-encode these Huffyuv's with the option unchecked again as Huffyuv with this option checked without losing anything?

Yes, that option is specifically to correct video from certain capture cards that saved video with the top and bottom fields swapped in the frame. For example normally the scanlines would appear in order:

1--------
2--------
3--------
4--------
5--------
6--------

but some cards saved them like:

2--------
1--------
4--------
3--------
6--------
5--------

If you don't have one of those cards (the only ones I know of was the old Matrox Marvel and eTV cards) you shouldn't use that option. That would cause the up/down bounce you are seeing.

[drinklime]

is there a way i can check the actual order of the scan lines? something is seriously messed up, and both field orders dont work

[guns1inger]

If neither field orders work then you may have deinterlaced when you captured, in which case you have something of a mess on your hands. If you open the clip in virtualdub and go through it frame at a time, what do you see ?

[drinklime]

holy sh**, it works! after 13 months it finally works. OK, I dont know what the hell happened, because I convinced myself with a bunch of AVISynth scripts that it was top field first. Well long story (really long story) short, I ran:

AssumeTFF()
BOB()

and i scrolled through the frames in virtualdub and it was clearly out of order. I then ran:

AssumeBFF()
BOB()

and it looked good.

So then I encoded in CCE SP: (I THINK)

(UNCHECKED) Output top field first stream
Offset line = 0

and now finally it doesnt make me sick on my TV. I could have sworn I tried this before but I guess I didnt. Thanks!!!

[jagabo]

Keep in mind that changing the swap filds option in HuffyUV corrects the spacial location of the fields but it also reverses the temporal field order.

Once you know what to look for it's easy to identify the field order error that the HuffYUV option fixes. Look for a nearly horizontal line or edge in a still shot. With the correct setting the line will appear unbroken. With the wrong setting the line will be broken:

Here are some crops from tests I ran with my old Matrox G450 eTV long ago. The top three lines are with the correct field swap setting, the bottom three with the wrong setting: