All were based on interlaced 1440-1080-60i HDV footage and were rendered with that same resolution, field order, and frame rate.

I trust Nick's observations - so maybe the BUG is somewhere else in the pipeline?

Interesting.

Q: Is VB used as part of the V2H? - I think it maybe . . .

Maybe it is a problem of the files themselves?
MediaInfo interpreted the 2 Cineform-files also as progressiv:

That's true, but despite that, the VP-rendered one gets correctly read as interlaced in all versions of Vegas, and pre-14 Vegas knows that the VirtualDub-rendered one isn't really progressive. So something has changed in how Vegas assesses the files. Pre-V14 Vegas was apparently interpreting the field-order of the file in a different way from MediaInfo. Maybe it's now interpreting it in the same way.

MediaInfo doesn't report anything about the field order of the MagicYUV renders. That might be because these were rendered with version 2 of the codec and MediaInfo doesn't know about that yet. But I believe this issue was also occurring with version 1 of the MagicYUV codec.

Q: Is VB used as part of the V2H? - I think it maybe . . .

I guess if the project properties are set correctly as interlaced, Vegas2Handbrake will behave itself correctly.

But I believe this issue was also occurring with version 1 of the MagicYUV codec.

MediaInfo doesn't report the field order even by using MagicYUV version 1 or even Uncompressed file. I guess that MediaInfo is reading the file header and avi file don't give much informations.

Vegas2HandBrake does not involve VirtualDub, signal passes through DebugMod Frameserver and AviSynth only.

Thanks Marco.

I had a reply from Vegas Support to the effect that the VirtualDub rendered files appear to be progressive. So, to concentrate on one of the 4 files from the zip file in the first post...

VirtualDub-HDV-Cineform.avi is read by the following as being progressive:

• MediaInfo (both mine and Support's)
• My VP14
• Support's VP14
• Support's VP13

But it's read by the following as being interlaced:

• My VP13
• My VP12
• My VP10

Particularly strange that mine and Support's VP13 are reading the file differently. Perhaps that's due to a different version of the Cineform codec?

So in an attempt to establish if the file actually is interlaced or not, I made the following AviSynth script (separate-fields.avs):

AviSource("E:\VirtualDub-HDV-Cineform.avi")
separatefields()

I then opened that script in VirtualDub and stepped through the file frame by frame with the right arrow key. This is what I see:

I think that movement between every frame proves the file really is interlaced, and so the 4 things in the first list are all interpreting the file incorrectly. Right?

(All informed input greatly appreciated as this issue is starting to drive me a little insane!)

These are the codec versions I have installed:

• GoPro CineForm Codec - CFHD.dll - v9.2.1.690
• MagicYUV - RGB - magicyuv.dll - v1.9.9.0

I have exactly the same result as you 9both in VP13 and VP14) using your files.

I have MagicYUV version 1.9.9.0 and Cineform version 9.2.1.690 as well.

Screenshot of your Vdub files played in MPC-HC Version 1.7.10 x64. Both Cineform and MagicYUV show the same issue, so I don't bother putting screenshot for both files (made with Vdub).

Playing without deinterlacer

Deinterlace artifacts are clearly visible.

Playing with deinterlace shader (blend)

Blurry result as expected but no more interlaced artifacts.

Preview in VP13

Preview in VP14

It speaks by itself

And last but not least, the project properties (automatically set by Vegas during import)

VP13

VP14

The aspect ratio is also detected differently with the same file.

So there is definitely something wrong with the way VP14 decode those files.

Thank you.

I don't think the pixel aspect ratio (PAR) is flagged/stored within AVI files. I think VP13 (and earlier) may just have been making an intelligent guess that the PAR should be set to 1.3333 if the file has 1080x1440 resolution (and perhaps it looks at frame rate too). And so VP14 is not necessarily "wrong" to set the PAR to 1.0.

For certain kind of media such data is defined in the file "Vegas profiles.ini" which you could find at "C:\ProgramData\VEGAS\VEGAS Pro\14.0". Seems like there's been changes for VP14.

I don't think the pixel aspect ratio (PAR) is flagged/stored within AVI files. I think VP13 (and earlier) may just have been making an intelligent guess that the PAR should be set to 1.3333 if the file has 1080x1440 resolution (and perhaps it looks at frame rate too). And so VP14 is not necessarily "wrong" to set the PAR to 1.0.

Based on your video file, I prefer PAR 1 though, 1.1 should be perfect 😀

For certain kind of media such data is defined in the file "Vegas profiles.ini" which you could find at "C:\ProgramData\VEGAS\VEGAS Pro\14.0". Seems like there's been changes for VP14.

Thanks Marco. Fascinating. I never knew about this file! However on my system these 2 files are identical:

• C:\ProgramData\Sony\Vegas Pro\13.0\Vegas profiles.ini
• C:\ProgramData\VEGAS\VEGAS Pro\14.0\Vegas profiles.ini

The VirtualDub-rendered files match the requirements for Key10 in that file. i.e.:

• File IO CLSID is "anything" (wildcard 0)
• Subformat is "None"
• Size X is 1440
• Size Y is 1080
• Frame Rate is 29.97
• Color Bit Depth is "anything" (wildcard 0)

So therefore it should be assigned the following attributes:

• Field Order = "Upper First"
• Pixel Aspect Ratio = 1.3333333333
• Alpha Channel Interpratation = "Undefined"
• Gamma = 1

But in VP14, that's not happening.

Based on your video file, I prefer PAR 1 though, 1.1 should be perfect 😀

The food on that boat really was very very good! 🍔🍕🍽🍜🍉

There is no mechanism in an AVI file to define aspect ratio or field order (except in the case of DV files.) If you place a clip on the timeline and go to Properties and then the Media tab, next to 'Stream" you will see a disk icon, set the parameters of your AVI file correctly and then click on the disk icon to save the profile. Next time Vegas encounters an AVI file using that codec, frame size and frame rate, it will apply the saved parameters for aspect ratio and field order.

There is no mechanism in an AVI file to define aspect ratio or field order (except in the case of DV files.) If you place a clip on the timeline and go to Properties and then the Media tab, next to 'Stream" you will see a disk icon, set the parameters of your AVI file correctly and then click on the disk icon to save the profile. Next time Vegas encounters an AVI file using that codec, frame size and frame rate, it will apply the saved parameters for aspect ratio and field order.

Thanks John, nice tip.

But, if I deinterlace the same file, it's now interpreted as interlaced in VP14 & VP13.

Do you know how to revert back to the original configuration?

I have also tried those Cineform files in Resolve. The one created by VP13 can be read, the one by Vdub can't...

...If you place a clip on the timeline and go to Properties and then the Media tab, next to 'Stream" you will see a disk icon, set the parameters of your AVI file correctly and then click on the disk icon to save the profile. Next time Vegas encounters an AVI file using that codec, frame size and frame rate, it will apply the saved parameters for aspect ratio and field order.

Thanks John! That's new to me. It works as you say for both the Cineform and MagicYUV files rendered by VirtualDub.

Do you know how to revert back to the original configuration?

Just repeat the process, setting it back to progressive field order and 1.0 PAR then click the save icon. Worked for me.

I'm curious where these user stream properties settings are stored. Did a brief search and couldn't find it.

I have also tried those Cineform files in Resolve. The one created by VP13 can be read, the one by Vdub can't...

Perhaps worth mentioning on their forum.

Do you know how to revert back to the original configuration?

Just repeat the process, setting it back to progressive field order and 1.0 PAR then click the save icon. Worked for me.

The problem is by doing that, both VP13 and VP14 read the files as progressive after.