Can the frameserver be reversing the field order?

craftech wrote on 7/14/2013, 10:50 AM
I should have asked this question a long time ago.

Using Vegas 8 with mxf footage from my EX1 the Vegas media properties tab correctly flags the footage as UFF.

I frameserve the footage to Procoder 3 via the following script:


#Frameserve in YUY2 format

SetMTMode(5, 4)
AviSource("e:\fs.avi")
ColorYUV(levels="TV->PC")
AssumeTFF
SetMTMode(2)
TDeint(mode=1)
Lanczos4Resize(1440,960)
Lanczos4Resize(720,960,-.8,.6)
Lanczos4Resize(720,480,-.8,.6)
blur(0.0,1.0)
sharpen(0.0,0.75)
assumetff()
separatefields()
SelectEvery(4,0,3)
Weave()
Distributor()


When I open the Source video coming off the frameserver via the script in Procoder 3, Procoder 3 ALWAYS recognizes it as LFF.

What I have been doing all along is simply changing it to UFF in the Procoder 3 properties. It seems to work OK, but now I am wondering where the mistake occurs?

Could it be the frameserver or something wrong with the script?

John

Comments

musicvid10 wrote on 7/14/2013, 11:17 AM
It may be the AVI frameserve wrapper that defaults to LFF.
I bet Nick Hope or John Meyer can help. They're all over this stuff.
johnmeyer wrote on 7/14/2013, 5:44 PM
I use frameserver every single day with all sorts of source footage. I have never seen it reverse field order ...

... but ...

I have had problems with field reversal when frameserving due to issues that can drop up in the Vegas media settings, Vegas project settings, and in the script itself. As a result, here is the workflow I always follow when frameserving. Perhaps this will help you.

First, when I have the project edited and ready to frameserve, I first serve it into this three-line script:
AVISource("e:\fs.avi")
assumeBFF()
separatefields()


I change the assumeBFF() to assumeTFF() depending on my source footage.

The purpose of this step is to make sure, before serving into my actual, more complicated, AVISynth script, whether the field order is what I think it is. When I open this video in Virtualdub and step through field-by-field, if I get that characteristic back-and-forth motion that indicates I have specified the wrong field order, I can go back to Vegas and look more closely at both the source footage and also at the project settings. What I often find is that Vegas assigns the wrong field order to source footage. If so, I right-click on the media (or one of the events) and change the field order from TFF to BFF, or vice versa. I then re-check using the script above.

I then serve into my main script. If I then get a problem, I can be reasonably certain that it has something to do with my script. To find out where I might have screwed up, I do something that is roughly equivalent to putting break points into computer code. What I do is to assign one of the lines in my script to a variable, and then at the end of the script I include a "return" statement that will return that variable, and I add a "separatefields()" statement to the end of that variable. So, in your script, I might do this:
...
test = TDeint(mode=1)
Lanczos4Resize(test,1440,960)
...
#Last statement in script
return test.separatefields()

All the statements after the test line will be ignored, but you don't have to bother to comment them out or otherwise modify the script. If you open this in VirtualDub, you can walk through the script field-by-field, and you can check for field order reversal.

In direct answer to your question, I've never seen frameserver actually screw up the fields: the problem, in my experience, has always been in the Vegas settings or in the script. If the above tests show that the field order is what you expect, than the problem lies probably lies with Procoder. As I mention above, Vegas sometimes reads the wrong field order from some files and you have to manually correct that (although this is rare). Perhaps procoder is doing this.

If Nick reads this, he may have some other ideas to offer.

craftech wrote on 7/18/2013, 1:44 PM
Thanks (again) for the amazing level of help you always provide John. I am playing with your suggestions right now as we speak.

Regards,

John