1. Field order problem? & 2. How to fix?

[fvisagie]

Hi All,

1. I seem to have a field order problem but would like you to confirm or correct my suspicion before wasting time on the wrong treatment.

Home movies I author to DVD have "shuddering" motion when viewed on a stand-alone DVD player. The content is interlaced and displays perfectly on a PC with e.g. PowerDVD which deinterlaces for playback.

After searching for similar descriptions on this forum I came to suspect reversed field order. GSpot shows the edited AVI has BFF whereas the encoded MPEG-2 file has TFF.

Does this support the suspicion that field order reversal is the cause of this shuddering motion?

2. The basic video tool chain is Sony handycam -> captured via STOIK capturer -> "raw" DV AVI -> edited via Windows Movie Maker -> "edited" DV AVI (to preserve DV DATECODES for subtitles) -> mencoder -> MPEG-2.

The "edited" DV AVI has BFF and the encoded MPEG-2 has TFF, but it would probably be naive to believe that mencoder is the cause of the problem?

Is it possible that the field order got reversed higher up the chain but that the field flags or something weren't updated correspondingly, and now this problem just perpetuates down the chain?

Do you spot any known field order offenders in this tool chain? More importantly, how to fix that behaviour?

Or any other suggestions?

Thanks in advance,
Francois

[freebird73717]

DV is BFF so your encoded mpeg should be BFF also. You can run the mpeg through restream to correct the field order and then reauthor. It's been ages since I've done it so I can't remember exactly what the settings are in restream but if you do a forum search it should get you the info you need.

Not sure how your field order got reversed in the first place though.

[jman98]

Yes, it sounds like a field order problem. You can fix it without re-encoding with the program ReStream.

Some encoders default to encoding TFF no matter what their input video flags say. I have also seen the flag be set incorrectly. For example, the Hauppauge PVR-250 and PVR-350 video capture cards are very good, but they set the flag wrong in the video stream. They set the flag as TFF, but it is actually BFF. If you know this, you can set the encoder to use BFF and it will be OK if you re-encode to a lower bit rate. I don't know of any known offenders in your process, but again note that I said that some encoders default to always use TFF and maybe mencoder is like this.

[jagabo]

My PVR-250 sets the field order flag to TFF and the video is TFF.

You can reverse the field order of a video by shifting the frame up or down by one scan line.

[jman98]

My PVR-250 sets the field order flag to TFF and the video is TFF.

You can reverse the field order of a video by shifting the frame up or down by one scan line.

Interesting. My PVR-350 says its TFF but it most definitely is always BFF.

I have no idea how to shift a frame up or down by one scan line so I have no idea how to put this suggestion to any practical use.

[jagabo]

Reverse field order: Crop one scan line off the top, add one to the bottom. Or vice versa. You can't do this with YV12.

[jman98]

Thanks, jagabo. I understand what you mean with that explanation.

[jagabo]

Yes, in AviSynth it's:

Crop(0, 1, -0, -0).AddBorders(0, 0, 0, 1)

[byteguy]

Yes, it sounds like a field order problem. You can fix it without re-encoding with the program ReStream.

Restream will only FIX a bad flag setting in the file. It will not actually change the encoding of the file. Trust me; I worked through this with the developer to make sure I understood.

[jman98]

True, but I have seen examples where that was sufficient to fix the problem.
It's worth trying and so much the better if it works and no loss if it doesn't as you aren't worse off.

[jagabo]

Restream will only FIX a bad flag setting in the file. It will not actually change the encoding of the file.

The wrong flag is exactly the OP's problem.

When I gave information on reversing field order I simply meant it as informative. In case he needs to do it for some reason in the future.

[freebird73717]

It's worth trying and so much the better if it works and no loss if it doesn't as you aren't worse off.

Exactly.
I used to have an old ati card that set the field to bff when it should have been tff. Restream worked everytime for me.

[fvisagie]

@ byteguy (and others re. ReStream)

You're quite right, that option in ReStream merely seems to change the field order flag without re-encoding the stream.

In my case that didn't help.

What did help was to add -lavcopts top=0 to the command line (for the encoder to output BFF), and all was perfect! This was a real project-killer; the relief was overwhelming .

Thanks to all for your contributions.

Kind regards,
Francois

[jagabo]

What did help was to add -lavcopts top=0 to the command line (for the encoder to output BFF), and all was perfect!

All that does is change the field order flags of the output file.

[fvisagie]

By golly, you're right. As you expected .

Even "ReStream works now", for the same reason of course.

Normally I test very thoroughly and I'm stumped as to why last night I concluded changing the field order flag with ReStream didn't work...

But at least I now have a solution. Thanks to all for their kind contributions.

Kind regards,
Francois

[jagabo]

A frame of interlaced video contains two half pictures. When viewed you should see one of those half pictures at a time, one after the other. The field order determines which half picture you see first.

Beyond that you have whether the frames are encoded interlaced or progressive. This effects how the frames are handled internally by the encoder. There's nothing to stop you from encoding an interlaced frame as progressive, or vice versa. But using the wrong encoding will result in degradation of the chroma channels (a slight blurring of the colors).

What I don't know is if you encode a video as progressive, then use Restream to set a field order, if it also changes the encoding flag to interlaced. If not, that would explain why it sometimes doesn't work. The playback device may just ignore the field order flag when the video is marked progressive.

[fvisagie]

My guess would be that progressive video being frame-based, it has no concept of fields (I do seem to recall that some videos I opened in GSpot had neither TFF nor BFF set, although I know this isn't conclusive proof).

What you say about the field order flag is how I had understood it, too. Additionally I'd also thought that (some) encoders have control over the order in which fields are written out? mencoder has the phase filter that can supposedly take into account whether capturing was B/TFF, whether subsequent transferring in the tool chain was B/TFF, and whether output needs to be done in the opposite order or not.

phase[=t|b|p|a|u|T|B|A|U][:v]

Delay interlaced video by one field time so that the field order changes. The intended use is to fix PAL movies that have been captured with the opposite field order to the film-to-video transfer. The options are:

t
Capture field order top-first, transfer bottom-first. Filter will delay the bottom field.

b
Capture bottom-first, transfer top-first. Filter will delay the top field.

p
Capture and transfer with the same field order. This mode only exists for the documentation of the other options to refer to, but if you actually select it, the filter will faithfully do nothing

a
Capture field order determined automatically by field flags, transfer opposite. Filter selects among t and b modes on a frame by frame basis using field flags. If no field information is available, then this works just like u.

u
Capture unknown or varying, transfer opposite. Filter selects among t and b on a frame by frame basis by analyzing the images and selecting the alternative that produces best match between the fields.

T
Capture top-first, transfer unknown or varying. Filter selects among t and p using image analysis.

B
Capture bottom-first, transfer unknown or varying. Filter selects among b and p using image analysis.

A
Capture determined by field flags, transfer unknown or varying. Filter selects among t, b and p using field flags and image analysis. If no field information is available, then this works just like U. This is the default mode.

U
Both capture and transfer unknown or varying. Filter selects among t, b and p using image analysis only.

v
Verbose operation. Prints the selected mode for each frame and the average squared difference between fields for t, b, and p alternatives.

So are you saying that all encoders write out fields in the same order they read them, always? (that's if you don't interlace )

[Alex_ander]

Top_field_first flag (1 for tff, 0 for bff) is a property of each induvidual frame.
I case of interlaced encoding an encoder outputs all frames with the same setting (1 or 0). To prevent wrong setting some encoders take info about actual field order from the input video, some (like CCE) want the user to enter the correct data. An encoder may also have an ability to output video with different field order (e.g. using line shifting like CCE).
In case of progressive encoding a standard MPEG2 decoder will also follow that flag. E.g. in case of soft pulldown video is marked as progressive, but the decoder follows top_field_first flag in combination with repeat_first_field flag to build extra frames from repeated fields.
http://scanline.ca/deinterlacing/

[jagabo]

I'd also thought that (some) encoders have control over the order in which fields are written out? mencoder has the phase filter that can supposedly take into account whether capturing was B/TFF, whether subsequent transferring in the tool chain was B/TFF, and whether output needs to be done in the opposite order or not...

So are you saying that all encoders write out fields in the same order they read them, always? (that's if you don't interlace ;-))

Encoders don't normally separate the frames into fields. Frames are compressed as frames. Field order flags are there to tell a player which field to display first during playback.

Encoders will usually allow you to specify the field order and interlaced/progressive status in case they can't determine the properties correctly themselves. They may additionally offer the ability to swap the field order of the frames. This can be done by shifting the frame up or down by one scanline, or by recombining fields from two consecutive frames.

The PAL phase option is a special case where a progressive source is packaged such that the two fields that make up a frame are split between two consecutive frames. The frames are separated into fields, then a field from one frame and a field from another frame are put together to restore the progressive frames -- which are then MPEG compressed.

[vcddude]

By golly, you're right. As you expected .

Even "ReStream works now", for the same reason of course.

Normally I test very thoroughly and I'm stumped as to why last night I concluded changing the field order flag with ReStream didn't work...

But at least I now have a solution. Thanks to all for their kind contributions.

Kind regards,
Francois

Hi Francois,

I have the same problem -- I am trying to use Nero Vision 5 to capture straight to MPEG2 using my ADVC-100 video converter box. It detects the box just fine and captures just fine except for one big problem: as expected, the ADVC captures in BFF field order, but Nero's on-the-fly MPEG2 encoding results in a TFF file -- creating jerky video as a result.



Here is a screenshot from ReStream. How do I correct the flag from TFF to BFF with Restream without having to re-encode the video?

Thanks,
Kevin

[jagabo]

Uncheck "top field first."

[vcddude]

Uncheck "top field first."

Yep -- that did it.

Thanks!
Kevin

[Smack2k]

My video, captured from an ATI ALL-IN-WONDER 8500 when I open it in restream has frametype progressive checked and top field first is unchecked. My video is very jittery on this settings.

What should I change it to fix my issues? Do I both uncheck progressive and check tff or just check tff?

Sorry, still trying to get a grip on all of this!

Thanks!

[jagabo]

It should have been encoded interlaced. You can get away with just flagging it interlaced and (probably) TFF but colors will be a little blurred. If TFF is still jittery use BFF instead.

[Smack2k]

How do I set it to BFF? I dont see a choice for that in restream.

Also, are you saying my video is captured deinterlaced? When setting up my capture using ATI's software, the only option is to check Deinterlaced. I assumed by not checking that that I was interlaced.

Thanks for helping a newbie out, I can seem to find any guides on restream

[jagabo]

How do I set it to BFF?

Turn off TFF. Ie, it's either TFF or BFF.

The field order is determined by the capture device. Some capture TFF, some BFF.

[Smack2k]

It was BFF then, so I should change it to TFF?

Also, do I leave the progressive checked?

[jagabo]

You should turn off progressive -- otherwise the field order flag may be ignored. Yes, change the field order to TFF.

[Smack2k]

Thanks a lot!

I will give it a go!

[Smack2k]

Everything worked out well, the video looks fantastic now!

Thanks for all the help.

Also, which Adobe product would you reccomend to make video look a little better?

I have the CS3 suite and wanted to know which to use