Field order of interlaced video
Hi, recently we have exported our 3D animation to mov file in DV50 codec.
All the materials and projects, sequences etc. have the attribute below:
PAL 720x576, 16:9 anamorphic
The raw materials are interlaced uncompressed avi files, top field first, rendered by 3D software on Windows platforms. Played back by QT player, the objects in these avi files have jagged edges.
Then we edited those materials in an un-interlaced sequence in FCP. Viewed in FCP, those jagged edges have gone, the edges of those objects are smooth.
Then we rendered the sequence to a mov file in DV50 codec. But the jagged edges appear again, when viewed in QT player, and seems more serious.
By searching the net, I have learned that as for top field, it may refer to differnt lines, some mean odd lines, while others mean even lines. Is this the cause that make the jagged edge appear again?
Thanks in advance.
Are you viewing the footage on a computer monitor or broadcast reference monitor?
Your computer display (and your LCD, plasma, LED TV) is a progressive scan monitor. So when you preview interlaced footage on there you tend to see the scan lines (odd and even). If you pause it then it's really pronounced. But even when it plays you'll see the interlacing in any motion areas (running, cars driving by, hand waving, etc.).
Preview your footage on an interlaced monitor and you shouldn't have any problems. If your final delivery is intended for progressive displays (projectors, YouTube, Vimeo, etc.) then you'll need to de-interlace your material before final delivery.
I think you have a field order problem.
Basically fields in an interlaced stream are easy to understand (field 1 is the first field to be recorded/displayed, field 2 is the second one to be recorded/displayed, calling them top/bottom, odd/even, whatever is just bullshit jargon, you can find the proper description of fields on here http://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-5-200204-I!!PDF-E.p... ), BUT there is an issue with the way that different codecs encode the data and if you're not careful you can end up having the fields displayed in the wrong order, i.e., field 2 before field 1, which has the visual effect of jagged edges and shimmery motion.
Most codecs need to be encoded as top field dominant (don't get hung up on the jargon, just go with it for now) but the DV codecs are bottom field dominant so to get the field order right on playback you have to switch the field dominance to bottom on the export settings when you make your DV50 files.
Hope that helps.
thanks for all your replys.
Sorry, I forgot to mention that the jagged edges are obvious while QT player was paused. And we noticed the problem on computer monitor.
Later, we changed the sequence of FCP to top field first ( it's no field before), the same order as raw avi files, and the result is much better.
Here comes another question. Since QT player is paused, what we see is a complete frame having 2 fields displayed simultaneously, right? Then, the order of the fields should have no effect, right? But it seems that the order does have effect.
And as for our case, the raw avi files are top field first, sequence has no field, DV50 codec is bottom field first. When rendered to DV50 mov, does FCP deinterlace first then send the data to DV50 codec? Here the key point is sequence's field setting. Since later on, we changed the sequence's setting to top field first, and the result is much better, we guess that FCP does nothing to the raw materials' field and send the interlaced data to DV50 codec.
One last question, it's strange that different softwares have different reports about the same avi files' field order. In FCP, it's top field first. In G-Spot on windows platform, it has no field. And in another video app, it's bottom field first. Terrible!
Well, actually it is important that the fields come in the correct order because the way in which the lines are combined can change. Hopefully this won't get too confusing...
Lines are always numbered in the order in which they are scanned, so for a progressive picture the lines go 1, 2, 3, 4, etc, down the screen. But for an interlaced scan, the lines in field 1 are numbered 1, 2, 3, etc, and the lines in field 2 go 563, 564, 565, etc, and those slot in between the lines in field 1. (That's the numbers for an HD picture but the principle is identical for SD).
Swap the fields and, for example, line 566 won't be displayed in between lines 3 and 4, where it should be, but it'll be shown between lines 2 and 3.
So if you have a shot where a diagonal line should display like this:
what the screen will show when the field order is wrong will be this:
Hence the jagged lines.
TBH, I don't know why different software would tell you different things because I don't know how they work it out.
Thanks for reply.
But I'm afraid field order has no relationship to the swaping of lines -- this is swaping of spacial order. It should be related to temporal order -- whether it's the top field displayed first then the bottom field or vise versa. As for still image, it should have no effect, well maybe the result depemds on how the 2 fields are combined to be displayed on computer monitor, anyway it should have no line swaping. But when the video is viewed on video monitor, the motion of objects may look like jumping back and forth, due to the reversed temporal order of top and bottom fields. Is it right?
And as for our case, it seems somewhere in the flow path the spacial order of the lines are changed.
Sorry, can you be clear about which field is top and which is bottom in terms of temporal order.
Movement jumping back and forward is what you would see when the fields are displayed in the wrong order on an interlaced display (television screen).
I thought we were talking about a progressive display (computer screen).
BTW, if swapping field order doesn't cause line swapping, you're using different software to the various things I've used over the last few years. In HD video line swapping is very hard to see, other than by noticing jagged lines on diagonals, because the lines are so close together, but you used to be able to see it happening with SD if you were looking critically at a grade 1 monitor.
THB, field order can only be displayed in two ways, correctly or incorrectly. If it's incorrect (which is what your description sounds like to me) you need to step through your workflow to establish where it's going wrong. If you're going through steps a, b, c, d, etc, it's pretty much impossible for someone to diagnose across the internet where exactly the problem lies.
Hopefully my suggestions will help you get to the bottom of it, but you need to keep a clear head and be methodical. I'm assuming that the ITU-R spec that I linked to makes perfect sense to you and that you have read the manuals for the software your using.
Thanks for kind help.
My mind is kind of in chaos. I need time to think it over again.