I have mixed HDV and SD on the timeline with no problems-if rendering to DVD MPEG-2. I haven't noticed there being issues at the edit points as you have Bob, and I have been checking closely lately.

Here has been my problem, as stated in another thread:

when I rendered to Quicktime MotionJPEG, no matter which way I put the field order, DV and HDV field order were always opposite (one was always headache inducing and the other wasn't).

Also, taken a step further, I did tests with 30p and 24p in the same timeline and found that DV and 24p go together, and HDV and 30p go together. In that when rendering, if the DV had the correct field order, so did the 24p after rendering. But the HDV and 30p did not. And vice versa.

My solution was to use an AVI intermediate at 60i, and then render to Quicktime. This was time consuming, (although I'm not sure that quality was hit too hard) so I would love if someone could show me the errors of my ways!

kairosmatt

Since you are going to render the result, when you render, either the HD or SD will be resampled to the final resolution (whichever one doesn't match the render resolution). The field order will be changed then when it is resampled.

Also, field order is dirt-simple to change, especially if you don't mind losing the top/bottom field of the first & last frame in a cut.

" especially if you don't mind losing the top/bottom field of the first & last frame in a cut. "

Having to drop a field is the same conclusion I reached.
It would have implications when cutting between two shots of the same thing if it's moving.

Bob.

There's no field drop because whatever field order is used and whatever the field order of adjacent video events is - always the complete frame will be read. It doesn't matter which field of a frame is read first if only each single event is read correctly, which is the case in Vegas.

From the very beginning on Vegas - as a video editing system - was designed to handle almost any kind of video formats in the same timeline - even when having dissolves between different kind of media and Vegas did and does a very good job here.

Marco

So what you're saying is that at a cut the field order will go1A,1B,2B,2A.

If Vegas does do that it'd be totally WRONG.
The only way ANY editing system can cut between UUF and LFF is to drop a field.

Bob.

Cuts are never done field based.

"So what you're saying is that at a cut the field order will go1A,1B,2B,2A."

Whether this is correct or not depends on how a video clip is defined and how it was recorded. What Vegas has to do is to read the clip the way it is defined. And that it does.

Marco

"Whether this is correct or not depends on how a video clip is defined and how it was recorded."

We're assuming one clip (A) was recorded UFF and the other (B) LFF.
That means that at the same point in time one 'camera' recorded the odd (upper) scan lines and the other camera recorded the even (lower) scan lines.

When you cut between the two something has to give otherwise the field order would be reversed at the cut. The last field of clip A will be an even numbered field, the first field of clip B will also be an even numbered field. You see the problem here? The field order just got reversed.

Hopefully no NLE including Vegas would make such a hash of it and indeed Vegas doesn't. Vegas is not being questioned at all.

The only correct way that JM and myself can see for the cut to be made correctly is to drop the first field from clip B. That will preserve the correct field order but produce a half frame jump in motion. Technically I think what would happen at the cut is field order is preserved but field dominance is reversed. Hardly a big issue and one you'd only see if in the real world both cameras were genlocked and if so it'd be very, very unlikely that you'd use two cameras recording with different field orders.

This isn't just an entirely theoretical brain teaser. Some here are having strange issues with QT and field order. I've had the same problem with QT and field order. One client lost a lot of money because of this with a pile of DVDs that had to be trashed.
I'm trying to understand what goes on in the various NLEs and systems that we have to deal with, some might handle things differently in subtle ways, by better understanding all of this then the pitfalls could be noted to look out for. It's not a finger pointing exercise. Needless to say I check anything and everything on a CRT. I've never once seen Vegas make a mistake, I have seen errors occur between Vegas and other systems. Whose fault that is doesn't matter to me, understanding the 'why' and the 'what' is way more productive.

Bob.

I think I know exactly what you mean. But actually I never had a problem with mixing field orders. I used PAL DV (lower field) next to PAL SDI (upper field) and HDV next to lower field MPEG and PAL DV. I did lots of compositings with both media mixed, dissolves and cuts and always Vegas did a perfect job.

HDV records the upper field first and Vegas reads the upper field first. But it will always cache the entire frame before doing anything. And same to DV with lower field first. Now Vegas reads the lower field first but caches the entire frame before any action happens.

I don't think any digital NLE is capable to do a field-based cut at all. The only exception might be Vegas when having set Quantize to Frames turned off. But I think only the former Vegas versions might cause problems in this certain case.

Dropping a field does not make sense for a digital system and it's (more or less) easy to proof this is not the case. Just create a frame with one field black and one field white, copy it and have it once defined as upper field first frame and once defined as lower field first frame. Be sure Quantize to Frames is turned on and place both the media next to each other, cut it and watch the preview while set to Best/Full (with project settings NOT set to progressive). You'll see both fields in the preview even at the cutting edges. No field dropped.

Marco

Two things I have learned dealing with interlaced. First of all forget about frames. Don't ever use that term, and don't ever think about it. All that matters is fields. You display one field and then the next field and then the next, etc., just as you display frames with progressive. If you start thinking about grouping any two fields together into a frame, this will lead you down many wrong paths.

Now, once we get that in our heads, the only other thing that matters is that an odd field always has to follow an even field, and an even field always has to follow an odd field. Or, you can call it upper and lower, or 0 and 1, or whatever naming convention you use.

Finally, each field obviously must be from a later moment in time. Otherwise you get that horrible "wrong field first" judder and forward-backward-forward motion (if you step one field at a time).

So, if you are mixing identical resolution video from multiple sources (e.g., a lot of MPEG-2 camcorder SD video I've gotten is TFF, whereas SD DV video is BFF), Vegas is either going to have to re-do one of the streams (resample and I don't know what else) or else just be smart and drop the first field and last field from every event that abuts video which uses the other field sense.

However, if you are mixing HDV and SD, which was the original topic, I don't think any such field dropping is necessary, because the video is going to be completely re-done in order to be either up- or down- res'd to the final render resolution. Since the result will be a completely different number of "scan lines," the original upper or lower sense won't matter much, since everything is being re-created from scratch, i.e., the "up-down" motion due to the vertical displacement between each field can easily be reversed when resampling to a different resolution.

I've been trying to test this, not easy!
What caught me out at first is Vegas ignores the field order specified in the Render As dialogue, I had to switch project settings between PAL DV and PAL Standard to create a UFF and LFF file of the same event which was a Vegas created video with very fast moving generated media.
Bringing the two files back into a Vegas project they appear different according to the thumbnails, I think they're only built from one field. However going through both of them on the T/L they're identical!
If I cut them together the result is indeed perfect!

I suspect I've started off with a false premise.
I'd assumed that the two virtual cameras would take the first field at the same time, one recording the upper field and the other the lower field. This would seem wrong. They both record the upper and lower fields at the exact same time. As you said when dealing with this Vegas buffers a whole frame. Looks like it's very clever. Depending on several factors it'll pull two fields from the one frame or the last field from one frame and the first field from the next. By doing this there's nothing missing, no jump in motion etc.

Time permitting I should do some more work on this, I really need to get into a tool like AVISynth.

Bob.

I really need to get into a tool like AVISynth.It is a little intimidating, because of the scripting, but actually I think you'd find it really simple once you spent a few minutes.

For what you are doing, I would recommend that you render your test cases from the Vegas timeline to an uncompressed AVI file. This avoids any issues of dealing with a frameserver.

Then, use this script, and open this script in Virtualdub. This will let you look at each field on the video and it then becomes trivial to tell what is going on:

AVISource("d:\uncompressed video from Vegas.avi")

separatefields()

In VirtualDub, you can right click on the preview window and select the 4:3 option (or 16:9 if that makes sense) and Virtualdub will re-scale the video so that instead of appearing vertically squished because half the fields are missing, it will be re-sized so the video aspect ratio looks correct. I find this easier to look at, even though it really isn't necessary for most of what you'll be doing.

Thanks John,
I will have a go at this.
First though I have to work our why one of my 1TB disks has developed a case of the Go Slows. Trying to edit at 1fpm (frames per minute) is more than I can stand.

Bob.