I actually have never gotten the newer versions of HuffYUV to work consistently, so I still use huffyuv-2.1.1.zip.

Try this page:

HuffYUV downloads

I'd be happy to create the same file using any other codec. I think the Sony YUV would also work.

I've had no luck installing that version of Huffy. It probably isn't Vista64 compatible.

I've had no luck installing that version of Huffy. It probably isn't Vista64 compatible. OK, here's a link to the same thing, but encoded with the SonyYUV codec. It is twice as large as the HuffYUV version, but you (or anyone else) should be able to put this on the Sony Vegas timeline and use it without having to do anything or install anything.

Alternating black/red scan lines encoded with SonyYUV

You can create such video using Vegas.

Turn off QTF in an interlaced project. Create a one frame crossfade between gen media of red and black. Place cursor at middle of crossfade, grab frame.

Turn QTF back on. Duplicate frame as many times as need to create your video. Render to whatever codec you desire.

I posted this years ago. Spot used alternate fields of black and white to check out HTDVs at various trade shows if I recall correctly.

Bob.

Project creating in Vegas - HD 1080-60i (1920x1080; 29,970 fps) (2Mb)

Thank you so much John. The tests I just did confirm my recent posts. It's one heck of a lot easier to see with the red and black alternating lines than it is squinting at video still frames though.

Here are some results:

I put my clip on the Vegas 8.0c timeline. I set the project properties to match the clip (1920x1080 PAR 1.000, TFF, Deinterlace: Blend).

I rendered it using SonyYUV using a render template that matched the project properties. The resulting file looked the same.

I changed the render settings to BFF, and the lines were reversed. I then realized that my test file doesn't easily let me know if the fields are being reversed; are the fields being shifted up one, or is the first field being dropped. If we decide to really get into this, I'll re-do the script so it creates one frame with alternating red/black and then next frame with alternating green/blue. That way we can tell if Vegas combines fields from adjacent frames.

I then changed the render to Progressive, and ended up with each scan line the same, with the color being a very dark red -- i.e., the lines had in fact been blended.

I then changed the project deinterlace properties to Deinterlace and repeated the same three renders.

My first surprise is that there was no difference between TFF and BFF. Both started with a black line.

The next surprise is that the progressive clip was completely black. Thus, there appears to be a significant difference in how interlaced material is converted to progressive. If you choose interpolate, it appears that half the scan lines are simply thrown away, and the remaining scan lines are duplicated, thus resulting in half the resolution being thrown away. Blend seems to average both fields. Neither is a very smart way to deinterlace, but I guess that has been covered by many others. So, I didn't really discover anything here; I simply confirmed what these two settings do.

I then set the project properties to deinterlace: none and did the same three renders. I got the identical result to interpolate when doing the TFF and BFF renders. The surprise on this one was when I did the progressive render, I ended up with my original file, with alternating red and black lines. Thus, this keeps all the original resolution and lines, but both lines will, I am sure, be displayed at the same moment in time.

I then changed the source field flag to BFF, changed the project properties back to the original settings (TFF, deinterlace blend) and re-did the three renders. I got the identical results to my first test, except that the resulting file started with the black line instead of the red line. The progressive render had every line the same shade of very dark red (i.e., the fields had been blended).

I then went back to my original test case, but this time rendered to DV NTSC AVI, both 4:3 and widescreen. Much to my surprise, I ended up with alternating red and black scan lines. I am not sure what I expected, but I guess I thought the lines might be some sort of blend. I tried rendering using both Good and Best, but in this somewhat pathological test case, I didn't see any difference.

I changed the project properties to NTSC DV Widescreen and did the render to NTSC DV Widescreen. I didn't see any difference from when the project properties matched the source.

I'll leave it up to others, if anyone wants, to do a few more tests using the deinterlacer plugins.

The net of all this is I didn't see anything too surprising.

If someone wants to check for whether fields from adjacent frames are ever combined (e.g., situations where first field is dropped), then this script will create video that will be useful.

#Create odd frames alternating black/red scan lines; even frames alternating green/blue scan lines; 



firstodd= BlankClip(length=10, width=1920, height=540, fps=29.97, color=$000000)

firsteven=BlankClip(length=10, width=1920, height=540, fps=29.97, color=$A52A2A)

secondodd= BlankClip(length=10, width=1920, height=540, fps=29.97, color=$8FBC8F)

secondeven=BlankClip(length=10, width=1920, height=540, fps=29.97, color=$483D8B)



interleave(firstodd,firsteven,secondodd,secondeven)

assumefieldbased()

weave()

assumefps(29.97)

assumetff()

killaudio()

john
To see authentic result, it is necessary for you to change Project Properties at viewing:
1. Field order - None
2. Frame Rate - 59,940 (Double NTSC)
3. Deinterlace method - Blend or Interpolate
4. Preview window - Best Full or Good Full


... then set the project properties to deinterlace: none and did the same three renders...
It is erroneous result - in yours frame there is no movement, it is static!
Please taste this clip (1.2 Mb)

Yours is definitely a better test clip because it has movement.

However, I re-did most of my tests with your excellent clip and I didn't see anything different than what I already reported.

Spot used alternate fields of black and white to check out HTDVs at various trade shows if I recall correctly.

Do you ever forget anything? :-)

Somewhere on the VASST site, there is the b/w gen media project that we used to create these tests, 'bout the same way you suggest.

I feel the tests are -still- important today, because they not only help determine how a display is managing deinterlacing and/or progressive content, but they also dramatically show upsampling errors by some of the cheap upsample DVD players. Been a while since we did this, but it's still useful.
It's very cool to see the interest in playing with deinterlacing, because
A-interlacing will stay with us for a while both at acquisition and broadcast
B-The internet obviously is always best progressive.

It's also nice to see folks more pleased now with how Vegas manages deinterlacing. Dennis has worked pretty hard on that aspect of the software.

I urge that folks remember that content type determines the deinterlacing methods, however.

The GS1966 clip is also 60i rather than the unusual 24i which helps as well.

All the stuff I've been talking about is quite clear with this test material.

If you set your project properties to match the GS1966 clip (1920x1080x60i), select a deinterlace method, then change the project properties to widescreen SD (720x480x60i 16:9), you'll clearly see that the two fields are still represented by alternating even and odd lines. In other words, the fields were automatically separated, resized, then folded back together in alternating even and odd lines at the new size. The image is still interlaced, but resized correctly.

If you set the deinterlace method to "none" the image is resized without the field separation and no longer correspond to even and odd lines at the new size. This would correspond to what I've been saying about the interlace comb being resized and giving you those weird wiggly artifacts on motion parts. With the example you don't see the wiggly artifacts because of the test material but you can clearly see that the interlace pattern is messed up. With real life footage that would mean that parts of an image that happened at one point in time would be mixed in with the frame captured a sixtieth of a second earlier or later and vice versa.

In other words, if you are downrezzing 60i HD footage to a 60i SD (the best way to do it), you need to make sure you select a deinterlace method even though you aren't deinterlacing in order to keep the even and odd fields intact during the resize.

If you want to use the Dawdle deinterlacing plugin or the Mike Crash smart deinterlacer, what you need to do is select no deinterlace method in your project properties and insert the deinterlacer on the clip as "Media FX" rather than "Event FX" (which is what happens when you use the effects insert icon in the lower right of each clip). If you don't insert the effect as "Media FX" it will no longer work with even and odd fields properly when you do any sort of simultaneous resize. Another option would be to set a deinterlace method in your project properties but disable it from individual clips you want to use the deinterlace plugin on by going to that clip's properties and changing it from interlaced to progressive.

Confusing? Yes, ever so slightly!

I see posts with problems that are related to these issues every couple of weeks. People want to make 60i SD 4:3 into SD 16:9 and it looks terrible: Why? People are getting horrible looking downrezzes from HD to SD: Why? People are getting terrible results when they zoom and crop a little into an image: Why? People are working with interlaced material, disabling the deinterlacer and getting screwy results: Why? These are all related to this Vegas behavior.

We need to put together some sort of deinterlacing reference paragraph and have it assigned as a sticky so that as these problems come up, we can just point people to this clear explanation.

I know that this is the most confusing thing I've run into in Vegas so far.

"I know that this is the most confusing thing I've run into in Vegas so far. "

It's confusing thing in anything!
We have several Panasonic MX50 mixers. Some time ago a good mate of mine remarked "They're not very good, they're only single field". Now I understand why, they do picture in picture, in real time. A week ago I was working with some ancient video and found the fields were completely different images, no doubt much of the early video processing software and hardware had considerable difficulty dealing correctly with interlacing and short cuts were taken.
The first time I ran into the issues you're now working through was probably with Vegas 4. I was converting PAL to NTSC, didn't look too bad but someone else from this forum did mention the nasty jaggies on moving edges. That was the time I learned about the importance of selecting a de-interlace method. At the same time I did some quick research into how the hardware standards converters work. They too wrangle the problem by de-interlacing however they use motion vector de-interlacing, part of the reason they cost so much I guess. If you've got the money and want to wrangle the last pixels worth of quality out of the image you can do this with AE (or probably in VDub for nix) and some of the expensive plugins. Personally for the money my clients pay me and the quality of the footage I get handed Vegas is more than good enough. I also tell them if they want better I have the numbers of post houses with the good gear, no takers so far.

In general when I strike seemingly intractable problems getting Vegas and interlaced material to do my bidding I break it down into simple steps. Render out at source res to uncompress, take that into new project and do the rescaling or whatever. Thank goodness big disks are cheap and I afford the time this takes.

I certainly agree this needs better documentation and explaination. The quality of any NLE is judged by what Joe Average gets out of it and I've seen plenty of horrors come out of Vegas for this very reason. Other NLEs seem to handle this better. I don't know if this is a product of their "optical flow" processing or if they simply use more intelligence under the hood.

Bob.

I have been dealing with this issue for quite a few years too, but recently two different issues have made me revisit deinterlacing quality:

1/ Finally having a progressive scan camera: the HVR-Z7. This has made me deal with the issue of dealing with older interlaced footage in newer progressive scan projects.

2/ 720p HD Internet video delivery. High quality Youtube, Vimeo and Facebook video is so much less forgiving of problems than SD DVD delivery.