How to check field order using only Vegas.

farss wrote on 8/24/2009, 8:12 PM
Big thanks to GS1966 and the Russian Vegas community. This did not originate in my head. Just that the idea is kind of lost in another thread and even there a lot gets lost in the translation. I should also thank John Meyer, several things he said and the technique he described using AVISyth got me thinking further and persisting with what was said in Russian.

1) Create progressive project at double the frame rate of the video you wish to check. That means 50fps for PAL, 60fps for NTSC. Set field order to None. Set de-interlace method to Interpolate. Pixel Aspect Ratio etc isn't critical but better to match that to source media, just to make seeing what's going on easier. Make Preview Best / Full.

2) Add interlace media to timeline. Single frame step through part of the video that has fast motion. You should see objects continue to move in the same direction between frames. If they go backward / forwards / backwards you have a field order problem. You may need to look carefully, typically you'll see a big change in position followed by a small change in position in the opposite direction.

3) To check further RClick the source media on the timeline and change the field order to the opposte value. If the motion is now all in the same obvious direction you have now made the field order correct for that source media.

Hope this helps someone. I usually check everything with a CRT monitor of some form but not everyone has these available.

Bob.

Comments

craftech wrote on 8/25/2009, 8:57 AM
Thanks Bob,

That is really helpful. I just printed it.

I did have a question about something you posted in the other thread you referenced.
You said:

"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."

How does one "shift the images +/- 1 line"?

John
Lyris wrote on 8/25/2009, 9:00 AM
Great tip, thank you. It makes sense.

Craftech: I think when he mentions shifting images up or down a line, farss means using the Crop tool to shift the image and thus change the field order. However, in this case, Vegas will interpolate, so this trick won't work.
GS1966 wrote on 8/25/2009, 9:47 AM
Misters, the question about "shift the images +/-1 line" concerns a little to other problem - to various Field First in Project Properties and event. Look my message with two screenshots here

Shift video +/-1 line - the unique way to avoid to avoid degradation (blured picture)

farss wrote on 8/25/2009, 2:50 PM
Yes, shifting the image +/- one line means Vegas is not interpolating. There's also an AVISynth script that appears to do the same thing but preserves the missing line.

Bob.
DJPadre wrote on 8/25/2009, 4:59 PM
i noticed something similar afew years ago but could never describe it clearly so i kept my mouth shut about it.

Most recently, ive been using deshaker (uncompressed) and deynapels slowmotion (encoding to Main Concept DV)
Funny enough the uncompressed shows up as upper field, and the MC although progressive, shows up as LFF.
those prerenders are rendered as Progressive from Vegas and reimported, show up as progressive so the tags work.
Its OTHER codecs that Vegas pukes with...

As it stands, if i had no clue about codecs or vegas nuances pertaining to them, my work would be unsellable...
Funny how i dont have any of these issues with PP/CS
johnmeyer wrote on 8/25/2009, 6:21 PM
Bob,

Very useful hint. I just tried it on your problem clip, and it immediately confirmed what we already know: the thing is top (upper) field first.

This is much easier and faster to use than my script, so I will be using it often.
craftech wrote on 8/25/2009, 7:22 PM
Yes, shifting the image +/- one line means Vegas is not interpolating. There's also an AVISynth script that appears to do the same thing but preserves the missing line.

Bob.
================
So does that mean that you do this as Lyris described above?

John
farss wrote on 8/25/2009, 7:36 PM
"So does that mean that you do this as Lyris described above?"

In the past I've always done it the Vegas way.
Now that I realise just what that's doing next time I have to do this I shall take a long hard look at this.
One area of concern is for people shoot interlaced HD and rendering out SD. If there's a field order swap required then IF that happens before downscaling the impact of the interpolation should be minor. If it's being done after the downscaling it could be significant.
Again I find it inordinately frustrating that the people who wrote the software expect us to reverse engineer it in order to get the most out of it.

Bob.
johnmeyer wrote on 8/25/2009, 7:56 PM
Since this is in some sense a follow-on to the earlier thread about field order, and since we are discussing the various approaches to not only finding, but also fixing those problems, I thought I should post here the same link I posted yesterday in the other thread:

Reverse Field Dominance by Donald A. Graft

As I stated in that other thread, the guy who wrote the software contained on this page has forgotten more about field order issues than all of us put together will ever know, and he provides insight into the pros and cons of several approaches to correcting field reversal problems.
Streamworks Audio wrote on 8/25/2009, 9:51 PM
I had this problem tonight. Took a AVCHD rendering that I did form Vegas using the Sony AVC encoder.... I forgot the field order when encoding - but I am sure I left it on the default for the preset.

Tonight I wanted to make a 960x540 60fps progressive Windows Media version to send to the PS3 to watch on the TV. For this I usually use Avisynth and SeperateFields() - but upon doing so I could see the field order problem (backward forward) motion. To eliminate this I simply put the ComplementParity() to swap the fields and then separate them.

Works perfect now ;-)
bsuratt wrote on 8/25/2009, 10:00 PM
<<One area of concern is for people shoot interlaced HD and rendering out SD>>

This has been a problem for me! I have experienced aliasing and artifacts in the SD version that were not in the source material. I will try using the methods described to see if this is my problem.

When you print to HDV tape does Vegas use the project or render templates or are the params fixed internally?

You would think a company like Sony with it's massive video technology and engineering resources would be able to get this right!

John_Cline wrote on 8/25/2009, 11:23 PM
"This has been a problem for me! I have experienced aliasing and artifacts in the SD version"

Have you selected a deinterlace method in the project properties page?

"You would think a company like Sony with it's massive video technology and engineering resources would be able to get this right!"

Generating excellent looking SD from HD material using Vegas is quite possible and quite easy, lots of people do it every day. It isn't rocket science, but it is video science.
albert_kes wrote on 8/25/2009, 11:40 PM
...It isn't rocket science, but it is video science...


Grazie wrote on 8/25/2009, 11:44 PM
Excellent John! - Now I do have an excuse . .

BTW, is this the first animated "smilie" gif on our Forum? Now THAT is an example of non-rocket but video-science. Nice.

Grazie
bsuratt wrote on 8/26/2009, 9:27 AM
John,

Yes, on interlace method; I use interpolated and check "Allow field-based motion compensation" on Custom/Advanced Render page, 2 pass for the best I can produce.

I may be too picky since the overall SD picture is very good, but if you look close there are minor artifacts present that were not in the HDV source material.
Subject matter is water skiing where there is lots of movement; problem lies mostly with the incidental objects such as background items which are moving. And the water has millions of riplets which are slightly blurred. You have ropes (horizontal items) which show artifacts (diagonal lines across the rope) which appear to be interlace related. This is the most objectionable problem.
The subjects (skiers) images (which the camera is following) are fine with no problem at all.

I have found that I can get a superior image when I print HDV timeline back to HDV tape on my M15U deck then recapturing to SD avi letting the deck do the conversion. So, either I have not found the correct settings in Vegas or it just can't do as good a job on conversion as a "hardware" converter can on moving object material.

Several people have said they get fine quality on HDV to SD conversions with Vegas, and I do as well with a lot of subject material. But not with a lot of moving objects. This is not a matter of the motion blur common to HD displays nor the expected softness difference of the SD image. Garbage is being added to the image somewhere. It's is a matter of the :"cleanness" of the SD image after downrezzing. Maybe I am expecting too much !
craftech wrote on 8/26/2009, 11:29 AM
Here is a sample of an SD Mpeg clip for DVDA that was progressive all the way through. It will not display properly on a CRT without motion aliasing. The colored outline on the edges is visible as well. This was done as follows:

1. Load EX1 footage (1920 x 1080p/30) as mxf onto Vegas timeline. Match project properties to mxf files.
2. Render out Huffy UV to avi file.
3. Resize in VD using Lanczos 3 resize filter and Huffy UV compression to 720 x 405 progressive.
4. Bring avi back into Vegas and render as DVDA video stream (NOTE: Problems showed up on JVC CRT pro external monitor before I even rendered).

I tried disabling smart resampling as well.

Vimeo said the download is available for a week.

There is no audio. Can someone burn this on a DVDRW with DVDA and try playing it on a CRT?

Thanks to anyone who can help me with this major problem. Every method I try yields the same results.

John

EDIT: I think you have to log in and go here. Then you can download it from the lower right side of the page. It is 13MB.
Haven't used Vimeo in a long time.
John_Cline wrote on 8/26/2009, 12:14 PM
"Maybe I am expecting too much !"

Maybe. Water skiing is really pushing the limits of HDV and MPEG2 encoding in general, I can think of very few things that would be more challenging to encode than high-motion water skiing. MPEG2 encoding looks at the video to see what pixels have changed from frame to frame and also what objects in the frame are moving and in what direction. With water skiing virtually every pixel changes from frame to frame and since there are completely random ripples and sparkles in the water, it is virtually impossible for an MPEG2 encoder to track objects. If you're producing SD MPEG2 then you are adding the artifacts of the HDV MPEG2 encoding with the subsequent additional artifacts of encoding this difficult material to SD MPEG2. I often encode very high-motion auto racing (NASCAR, IRL, ALMS) with great results, but I don't have the randomness of sparkling water with which to contend.

"And the water has millions of riplets which are slightly blurred."

Well, at a given bitrate, something has to give.

"You have ropes (horizontal items) which show artifacts (diagonal lines across the rope) which appear to be interlace related."

This is also a worst case situation since the ropes are often just slightly tilted from horizontal. Standard definition interlaced video has never handled this very well.

It may very well be that in your worst-case scenario that if you get better results printing to tape and using the M15U to do the SD conversion, then that's what you're going to have to do. I've found the M15U conversions to be a little soft and maybe that's what's working for you. Removing some of the high-frequency detail makes it easier to encode later. You have a special (worst) case and it is going to require special measures to accomplish the task satisfactorily.

The other factor is how are you watching these videos. Are you viewing on an LCD or plasma display? There are a variety of deinterlacing chips and algorithms employed across various brands and models and not all of them work very well. To get back to your original statement, yes, maybe you are expecting too much.
bsuratt wrote on 8/26/2009, 2:39 PM
John,

<<Well, at a given bitrate, something has to give>>

Y'know I had not thought of that obvious fact... I have not tried a SD Camera in such a situation. With SD there probably would not look any different since there is not that level of detail to begin with!

Thank you for your reply. I'll just have to wait until HD is more prevalent and the standard of delivery, then maybe I can be satisfied. Meanwhile I've had nothing but raves at the quality of my DVDs so most people are not aware that there is anything wrong with them.

Always trying to improve my product!