Field Order bug in V8 & V9

Back to post

Comments

farss wrote on 8/23/2009, 8:10 PM
You may have hit the mother lode. Here is my vegas profiles.ini:

;
; Sony Vegas
; Video Media Profiles
;
; Profiles start numbering at 1
;
; Profiles must be consecutively numbered (i.e. no holes in the numbering)
;
; Each profile is divided into two parts - a key and an attributes line formatted as follows:
;
; Key1=File IO CLSID, "Subformat", Size X, Size Y, Frame Rate, Color Bit Depth
; Attributes1="Interlace", Pixel Aspect Ratio, "Alpha Channel Interpretation", Gamma
;
; where:
;
; File IO CLSID is either 0 or a CLSID formatted {12345678-1234-1234-1234-123456789ABC}
; Subformat is either "None" or a string which is specific to the file IO class
; Size X is 0 - 800
; Size Y is 0 - 600
; Frame Rate is 0.0 - 1000.0
; Color Bit Depth is 0 - 32
;
; Interlace must be one of (case insensitive):
; "Undefined"
; "Progressive"
; "Upper First"
; "Lower First"
; Pixel Aspect Ratio is 0.5 - 2.0
; Alpha Channel Interpretation must be one of (case insensitive):
; "Undefined"
; "None"
; "Straight"
; "Premultiplied"
; Gamma is 0.0 and 10.0
;
; Strings must be enclosed in double quotes
;
; Spaces on a line are ignored unless they are inside double quotes (in which
; case they are considered part of the string)
;
;
; The key fields are used to match video streams in media and if there is a match,
; then the attribute fields are applied.
;
; All of the key fields can be setup as "wildcards" using the value of 0 (or "None" for
; the file IO subformat string).
;
; Keys are searched for a match to video streams starting at the largest key and working
; back towards 1. Therefore, keys later in the file that match will override earlier keys
; that match.
;
; Common file IO CLSIDs:
; AVI {EA9D287B-C85A-11d3-BB3A-0050DA1A5B06}
; QuickTime 4 {B7409F7E-9EC1-11d3-BB2E-0050DA1A5B06}
; MPEG {F009FBF1-B1A6-11d3-BB34-0050DA1A5B06}
;

[Video Media Profiles]
Key1=0, "None", 720, 480, 29.97, 0
Attributes1="Lower First", 0.9090909090, "Undefined", 1

Key2=0, "None", 720, 576, 25.0, 0
Attributes2="Upper First", 1.0925925925, "Undefined", 1

Key3=0, "None", 720, 486, 29.97, 0
Attributes3="Lower First", 0.9090909090, "Undefined", 1

Key4=0, "None", 704, 480, 29.97, 0
Attributes4="Upper First", 0.9090909090, "Undefined", 1

Key5=0, "None", 640, 480, 29.97, 0
Attributes5="Upper First", 1, "Undefined", 1

Key6=0, "None", 352, 240, 29.97, 0
Attributes6="Progressive", 0.9132420091, "Undefined", 1

Key7=0, "None", 768, 576, 25.0, 0
Attributes7="Upper First", 1, "Undefined", 1

Key8=0, "None", 352, 288, 25.0, 0
Attributes8="Progressive", 1.0920607185, "Undefined", 1

Key9=0, "None", 1440, 1080, 0.0, 0
Attributes9="Progressive", 1.3333333333, "Undefined", 1

Key10=0, "None", 1440, 1080, 29.97, 0
Attributes10="Upper First", 1.3333333333, "Undefined", 1

Key11=0, "None", 1440, 1080, 25.0, 0
Attributes11="Upper First", 1.3333333333, "Undefined", 1

Key12=0, "None", 1920, 1080, 29.97, 0
Attributes12="Upper First", 1, "Undefined", 1

Key13=0, "None", 1920, 1080, 25.0, 0
Attributes13="Upper First", 1, "Undefined", 1

Key14={372FDC19-3E1A-403B-BC13-BAAEDC318C3A}, "None", 704, 576, 25.000000, 12
Attributes14="Upper First", 1.090909, "None", 0.000000


I note that all entried have key = 0 apart from 14!
How did entry Key14 get in there, it's the ONLY one with a CLSID.
I just went back to this problem using GS1966's method to look at the fields. Results are intersting to say the least. If I put video onto the 50p timeline I can clearly see the field order change as I change the media's field order and yet it NEVER comes out that way in the rendered output.

I'll delete Key14 and see what happens.

Bob.
bsuratt wrote on 8/23/2009, 10:18 PM
Bob,

On my system which has both 8.0c and 9.0a the profiles.ini for 8.0c is named Vegas profiles.ini.

The Video profiles.ini which is identical to what you listed above is in the Sound Forge directory.

I do not have an ini file for 9.0a so it must use the 8.0c ini if present.

farss wrote on 8/23/2009, 11:47 PM
Thanks to our Russian friend I tried converting the 50i to 50p.
The 50p file was perfect.
From that file I rendered back to PAL DV.
PERFECT, well a tad soft but that's to be expected.

Then I really thought about how Vegas does change field order and the penny dropped. Vegas must do exactly what I'd just done internally. Here's why.

In regular PAL DV the first field ontains only the even numbered lines, the second field the odd numbered lines etc. This is referred to as Lower Field First or Bottom Field First.

If somehow this is messed up and you need to make the first field which contains in fact odd numbered line contain even numbered lines there's a BIG problem. The camera never recordered them, that part of the image does not exist. The only way to create them is through interpolation. You might be tempted to think why not simply swap the fields but there's a problem, you've now got the whole sequence going backwards/forwards/backwards because the second field was recorded at a point in time after the first field. Get the sequence reversed and you really have a mess.

So interpolation is the only answer. Why I could not get this to fly was very simple, I'd effectively disabled this by not having any deinterlace method defined. I knew that but never figured it would matter when simply reversing field order. Why it worked on my old systems was because I'd long ago changed all the project presets to specify a deinterlace method. It was that friggin simple.


Out of all this comes another realisation.
If we use the method that Vegas provides to reverse field order or even if Vegas has to do it because our source and output field order does not match we must loose some image qulaity. Vegas is 'inventing' what the camera never recorded. Even at Best it's only a very good guess and like all such guesses it can fail or be tricked. Fine edges would cause problems, hm, heard this as an issue more than once.

There is another way.
If you simply cut off the first and last field then no interpolation is required. Of course this does have a penalty, you loose a frame and that could really cause some anguish unless you knew to expect it. I think one of the AVISynth scripts that John Meyer kindly sent me does this.

Bob.



GS1966 wrote on 8/24/2009, 2:10 AM
farss
Today I have installed Vegas 5 (system Win XP SP2), and unfortunately have not found out essential differences with Vegas Pro.

Taking an opportunity, I wish to touch a following problem.
Unfortunately, at Vegas long time exists the unpleasant feature delivering some inconveniences. If in the project with LFF to open on TL a videofile with UFF (or on the contrary, SD or HD, PAL or NTSC - has no value. The main thing that Field First a file differed from Field First the project), this videoclip will be appreciable blurred.

Original frame (LFF) in LFF project:


Frame with LFF in UFF project:


To restore sharpness, it is necessary to shift on TL the necessary shots for one line upwards or downwards. Will agree, it is very inconvenient to make it manually.


Useful material - All About Video Fields

Gene
farss wrote on 8/24/2009, 4:33 AM
That article is a great read although from our perspective it covers much the same material as the article I linked to before. It also mentions the problem of intercutting interlaced video of differing field order.

The two frame grabs you posted show exactly what I feared was happening with the way Vegas handles this. The problem would probably change it's appearance when viewing it as moving images.

I tried to find another way apart from shifting the images +/- 1 line but with no success. I had hoped it would be possible to turn Quantize To Frames Off and trim one field from the head of a clip and hence shift the fields but I could not get that to do anything. There seems to be a way to do this but only outside of Vegas.


I shall be very happy to see the end of interlaced video.

Bob.
johnmeyer wrote on 8/24/2009, 8:56 AM
I am not sure the problem was found, but maybe I don't understand.

The video you sent to me definitely had the field order the wrong way around. I was able to demonstrate this by reading it into the following AVISynth script (this is the first one I sent to you):



#This script reverses fields



#Modify this to point to the video file you use. 

AVISource("E:\Documents\Dnload\UNPACK\OnTV.avi")



AssumeTFF()



#Comment out the line above and use the line below

#if the video is ACTUALLY bottom field first

#AssumeBFF()





#Use the line below if you actually want to look at individual fields

#You will immediately be able to detect if the video now has the correct field

#dominance. It the fields are reversed, each field will "jitterbug" back and

#forth from the adjacent fields.



#Separatefields()

I un-commented the Separatefields() line at the end of the script and this let me look at each field as if it were a frame by itself. When the fields are being played back in the correct order, the resulting video looks just like regular video; but if the field order is reversed, then the resulting video "jitterbugs" with every second field/frame going backwards in time.

This script, as written above, can fix many field reversal problems simply by changing the header in the file. In the case of the video that Bob was having problems with, that video had the header set to BFF (lower field first in Vegas terminology). But the fields were actually TFF. So, in the script above, I told AVISynth to treat the video as TFF, and ignore the BFF flag/convention that is part of a PAL DV AVI file.

However, some programs don't do what the header says. in that case, each pair of fields has to be swapped. That's what this script does:

#This script reverses fields



#Modify this to point to the video file you use. 

AVISource("E:\Documents\Dnload\UNPACK\OnTV.avi")



#Use whichever line below matches the source video



source=AssumeTFF()

#source=AssumeBFF()



even=source.trim(1,0).separatefields().selecteven

odd=source.separatefields().selectodd

interleave(odd,even)

fixed=weave()



#In the line below, use the OPPOSITE of what you chose above because the fields

#have now been reversed



#AssumeTFF(fixed)

AssumeBFF(fixed)



#Use the line below if you actually want to look at individual fields

#You will immediately be able to detect if the video now has the correct field

#dominance. It the fields are reversed, each field will "jitterbug" back and

#forth from the adjacent fields.



#Separatefields()

Once again, I included a "Separatefields()" statement at the end which can temporarily be uncommented in order to test the result.

IMHO, you should never convert to progressive unless you are converting for the web. This will always degrade the video. It certainly should not be considered a "solution." I guess it can be considered a "workaround" in order to get the job out the door, but it is definitely going to compromise quality.


johnmeyer wrote on 8/24/2009, 8:41 PM
One more comment:

You might want to check out this page:

Reverse Field Dominance by Donald A. Graft

This is a Virtualdub filter for reversing field dominance. I am linking to it not only because it might provide a better solution to the problem (at least for some people) than the AVISynth approach I posted, but I also am posting this because I think the description of the problem and the various solutions might provide further insight into why Vegas may appear to not be doing the right thing in certain situations. The second of my two scripts posted above does the "trick" he describes at the very end of the page.


Between the Canoupus problem referred to in earlier posts, and the apparent fact that PAL DV is BFF whereas standard PAL is TFF certainly seems like there might be various ways to go in a circle and end up exactly back where you started, in this case TFF.