Field Order

[Richard Sanchez]

Field order absolutely matters when compressing for DVD. On your computer it might look fine, but once you watch it on an interlaced monitor, it will have a fluttering effect. Though I don’t use procoder, that’s such a simple and important feature, it’s got to be there somewhere. They may have just moved that tool, check the help files. In a worst case scenario, you could deinterlace your video. You would be losing resolution, but the field issue would be gone.

[Erik Pontius]

Are you using Procoder 3?
Field order will definitely impact the quality of your DVD. Procoder will compensate for field order switching, however, it would need to have known the correct field order of the source. So if the source is actually lower field first but procoder thinks its upper, then the resulting field order will be incorrect.
I’m still using Procoder 2, it allows me to force the field order in the source page.

BTW, If you are working with DNxHD the field order will be upper field…

Erik

[Duane Fulk]

Yes, we just went to Procoder 3 and it doesn’t give you the choice in the drop down that Procoder 2 had. I sent a msg. to Grass Valley and they tell me there is a way to set it, but I can’t figure it out. Why they would only give you the Upper Field First option is beyond me.

Duane

[Erik Pontius]

Having upgraded recently to PC3, I’m seeing the same thing.
Apparently, from what I’ve researched, Upper/Top field first for the “DVD” mpeg2 encoding profile is forced for compatibility. As some older DVD players had problems playing anything that was lower/bottom field first. I’ve never seen one not play…not sure why the suddenly decided to enforce this rule in the 3 major release of the software…
So, they say a field order mismatch between your source and your output settings doesn’t matter…as long as the Input Source setting matches the actual source field order (ie. DV is lower field, and the source settings should reflect that). It then compensates properly switching the lower field to upper field and creates a properly encoded file with no field mismatch problems.
I’ve seen this in some tests I did long ago with PC2 and it does work, but the consequence is that it adds to the time it takes to encode since it is doing the field order switch calculations…which is why I preferred to set my output to match the field order of the source.

Erik