Interesting issue with Vegas Pro 8.0c

[David W. Richardson]

Working on a PC running Windows 7.

I have footage from several cameras, all from a wedding video shoot. One of the cameras is a Nikon which shot using the H.264 codec. As you know, Vegas 8 doesn't cope with H.264 very well.

I have LOTS of clips from that camera. When I try to add them to the project media, Vegas crashes. So I'm in the process of exporting them from Quicktime Pro as MPEG-4 files. (Quality 'Best', keyframes and data rate set to 'auto'. 1920x1080.)

I've run into something odd.

I decided to do a test, to ensure the quality of the MPEG-4 is up to snuff. So I created a new project and added just 2 clips to it -- one of the original (H.264) clips and its corresponding rendered MPEG-4 clip. Both are the same length (6.03). Both are 1920x1080x24 with 1.000 PAR. Both look identical to me when played separately. Audio synch is good on both.

But I put one on a timeline directly above the other, in order to do a split-screen to check the quality side-by-side. Now forget the split-screen for a moment -- even without that, I have the same behavior.

If I pull back the top clip (the H.264) a few frames, I can then switch back and forth, a frame at a time, to see first the H.264 clip and then the MPEG-4 clip -- with a 1-frame difference in the image. And if I do this at the very beginning of the clip, it all looks fine.

But if I then go to the middle of the clip, split the top clip, and pull back one of the edges to reveal the MPEG-4 clip beneath, something is wrong. It's as if the MPEG-4 clip is running FASTER than the H.264 clip, because they no longer appear to be in synch -- even though the audio waveforms for both clips still match perfectly.

I tried slowing down the MPEG-4 clip by changing the playback rate in 'Properties', but couldn't get it right. I even tried changing the playback rate of the H.264 clip, but that didn't help either.

Strangely, when I set the playback rate of both clips back to "1.000", everything seemed fine after that. Image synch between the two seemed normal.

Anybody ever run into anything like this?

 

[David W. Richardson]

Well, solution found.

Once I put both clips on the timeline, if I then selectively pre-render, after that the video of both clips is in synch. Should've thought of that.

Mystery solved!

 

[drapeama]

I then selectively pre-render, after that the video of both clips is in synch.

Selective Pre-Render works a bit the same as Media Composer that conforms the videos in order to be able to edit, more smoothly. But everytime you make an adjustment, you'll have to pre-render again. Otherwise it works fine.

 

[PerroneFord]

I hope you'll take this information in the spirit I offer it. But posts such as this are always worrisome because they highlight the fact that people don't have a good grasp of codecs and what is going on.

H.264 and Mpeg4 (part 10) are two different names for exactly the same thing. Same compressions scheme. The only difference is the name because one refers to the ITU name and the other to the ISO name. So all you did is introduce a generational loss of quality and not make the file one bit easier to deal with on the timeline.

The other part of your issue comes down to how long-GOP codecs are handled on the timeline. They are partial frames being put together on the fly. The pre-render actually creates full, discrete frames which eliminates the issues you saw. This should serve as a good reminder why most professional editors advocate for putting DCT based codecs (ProRes, DNxHD) or Wavelet codecs (RedCode, Cineform) on the timeline. They generally eliminate these kinds of problems.

Best of luck with your project.

 

[David W. Richardson]

Thanks drapeama. I use selective prerendering all the time in order to get smooth playback of AVCHD and similar material on the timeline. It just didn't occur to me that two versions of the same clip could be so far out of video synch without prerendering. Now I know.

 

[David W. Richardson]

I hope you'll take this information in the spirit I offer it. But posts such as this are always worrisome because they highlight the fact that people don't have a good grasp of codecs and what is going on.

H.264 and Mpeg4 (part 10) are two different names for exactly the same thing. Same compressions scheme. The only difference is the name because one refers to the ITU name and the other to the ISO name. So all you did is introduce a generational loss of quality and not make the file one bit easier to deal with on the timeline.

The other part of your issue comes down to how long-GOP codecs are handled on the timeline. They are partial frames being put together on the fly. The pre-render actually creates full, discrete frames which eliminates the issues you saw. This should serve as a good reminder why most professional editors advocate for putting DCT based codecs (ProRes, DNxHD) or Wavelet codecs (RedCode, Cineform) on the timeline. They generally eliminate these kinds of problems.

Best of luck with your project.

Well I'd read this on the web. Remember, it relates to older versions of Sony Vegas Pro -- versions 7 and 8.

"I believe you've uncovered the core problem. Vegas cannot use DirectShow codecs; it only supports the older Video For Windows codecs. You can't change this behavior (Sony has to). If you don't want to re-encode the video from your camera then you need to find another editing program to use."

Now the problem with encoding using Avid DNxHD is that it turns a 46MB file into a 266MB file. I have hundreds of clips I need to get into this project. At some point size will matter.

Rendering as an MPEG-4 file (.m2ts) gives me a file about 30% smaller than the original, and I cannot discern a significant loss of quality. Not saying it's not there, just that I'm not seeing it.

I'm trying to find a render that won't eat up all the available space on my hard drive with huge files, will give me acceptable quality, and won't crash Vegas Pro 8.0c when I add a couple hundred of them to the project. So far Vegas seems to have no problem with the .m2ts files.

 

[PerroneFord]

Well I'd read this on the web. Remember, it relates to older versions of Sony Vegas Pro -- versions 7 and 8.

"I believe you've uncovered the core problem. Vegas cannot use DirectShow codecs; it only supports the older Video For Windows codecs. You can't change this behavior (Sony has to). If you don't want to re-encode the video from your camera then you need to find another editing program to use."

Yes, I understand. It's why I eventually settled on using Matrox's VfW codec when I used Vegas 8 years ago.

Now the problem with encoding using Avid DNxHD is that it turns a 46MB file into a 266MB file. I have hundreds of clips I need to get into this project. At some point size will matter.

Sure. This is when nesting is helpful, or working on the project in pieces. Vegas in not Avid. It's not even Premiere. You have to work inside it's parameters.

Rendering as an MPEG-4 file (.m2ts) gives me a file about 30% smaller than the original, and I cannot discern a significant loss of quality. Not saying it's not there, just that I'm not seeing it.

Yep, you just threw 30% of the data away. If you're good with that, then OK.

I'm trying to find a render that won't eat up all the available space on my hard drive with huge files, will give me acceptable quality, and won't crash Vegas Pro 8.0c when I add a couple hundred of them to the project. So far Vegas seems to have no problem with the .m2ts files.

1TB drives are $100 or less these days. If you aren't willing to spend $100 to not throw away 30% of your data, then it seems you have your solution. Hopefully, this thread will hope others in the future.

 

[David W. Richardson]

Yep, you just threw 30% of the data away. If you're good with that, then OK.

So then using the DNxHD codec which gives me a file size 6 times bigger, is ADDING data? That doesn't seem logical.

When I render this project out to a DVD, it's going to lose probably a lot more than 30%, since DVDs are all standard-def.

1TB drives are $100 or less these days. If you aren't willing to spend $100 to not throw away 30% of your data, then it seems you have your solution. Hopefully, this thread will hope others in the future.

It's not about the hard drive space. It's the fact that Vegas is going to choke on hundreds of clips that are 6 times bigger than the hundreds of clips it's choking on now.

The ideal, to me, is to render a file that is roughly the same size as the original, but minus the h.264 codec. I can live with a filesize twice the original, but 6 times the original is just too much.

 

[David W. Richardson]

Sure. This is when nesting is helpful, or working on the project in pieces.

Nesting is probably the most viable option in order to simply save time at this point.

EDIT: Or maybe not.

For nesting, I chose to break the shoot down into 3 sections -- Pre-Ceremony, Ceremony and Post-Ceremony.

I created a new Vegas project and saved it as 'Pre-Ceremony'.

When I try to import all of the pre-ceremony clips shot using h.264, the project crashes. And that's just the footage from a single camera -- we shot with 4 cameras.

So apparently transcoding is my only option.

 

[PerroneFord]

So then using the DNxHD codec which gives me a file size 6 times bigger, is ADDING data? That doesn't seem logical.

It's not logical, and that's not what is happening. Again, this is not understanding how codecs work. Particularly intraframe vs interframe (Long-GOP) codecs.

When I render this project out to a DVD, it's going to lose probably a lot more than 30%, since DVDs are all standard-def.

Quite true. But one might hope that you see the value in keeping your master in as pristine a form as possible. Your argument here is like shooting a movie on the best Kodak film available, and then prepping for DVD and throwing away the film.

It's not about the hard drive space. It's the fact that Vegas is going to choke on hundreds of clips that are 6 times bigger than the hundreds of clips it's choking on now.

No. And I'll try to explain why in a moment.

The ideal, to me, is to render a file that is roughly the same size as the original, but minus the h.264 codec. I can live with a filesize twice the original, but 6 times the original is just too much.

That would be ideal. Unfortunately it's impossible. And I think you need to have a MUCH better understanding of DNxHD and bit rates. Bit rates are what determine file sizes. If you use DNxHD at the same bitrate as your original recording, the file will be no larger. You don't say what kind of camera you are using, but you do mention the Nikon. If it's a modern Nikon, then the bitrate is likely more than 40Mbps. DNxHD's lowest bitrate is DNx36, which would in fact make SMALLER files than what you are using now. But you'd throw quite a lot of data away.

Vegas, and any other editor, struggle with footage for generally 1 of 2 reasons:

1. The disk subsystem has trouble delivering the data fast enough. We see this when people try to hook up old hard drives with high bitrate material over USB2 or other slow connections.
2. The codec used is very computationally heavy and the CPU/GPU are not fast enough to decode it at playback speed.

If we think back to the old days of film, you could hold it up to the light and see a frame of the image. Each discrete frame on the film had a complete image. If we were to scan each of those images and make them digital files, we could do it in one of three ways. The first is to use NO compression at all. This makes HUGE files because each pixel of data is recorded 1:1 with the original source. This is in the rage of 1TB per hour at 1080p. The second way it can be compressed is to compress each discrete frame independent of the next or the previous. This is referred to as intraframe compression. This is what most editing codecs do, and it's the way most high end cameras record. It takes very little computer power to encode this and very little to decode this. That's why playback speed with this is excellent assuming the disks can keep up. The third way is INTERframe compression. In this kind of compression, the compressor looks at the first frame of video and compresses it normally. Then for the second frame it calculates ONLY THE DIFFERENCES from the first frame and compresses that. Ditto for the third, fourth, etc. It will do this for a finite number of frames, 15 being common, before it samples another full frame of video. The benefit to this is that it saves a TON of space. It's why you can record an hour of HD video on an SD card. The drawback to it, is that there is a LOT of computation going on to compress and decompress it. So heavy movement when recording will cause glitches and breakup, and when decoding, the computer is doing a LOT of computation and most CPUs struggle.

So here's how this relates to your problem. Your file sizes are small. That is what H.264/Mpeg4 do. That interframe compression allows the file sizes to be quite small. But it is very difficult to play back well because the CPU has to do SO MUCH work. It's not the file size causing the issue, its the type of file that's causing the issue. Your hard drives are plenty fast. Transcoding to something like DNxHD makes the files MUCH easier to play back for your CPU as long as we keep the bitrates low enough that your drives can keep up. Most modern drives can deliver 2-3 streams of 220Mbps without much issue. USB2 can deliver that without much fuss as well. The problem is that DNxHD, ProRes, and other intraframe compression codecs are not as efficient. They don't store "partial frames". Each frame is discrete. So the file sizes swell because of how they are storing the data.

If your Nikon is using 50Mbps bit rate to record the data, it's likely that it would take a bitrate 3x that much for DNxHD or similar codecs to accurately save it. So you'd need something like DNxHD at 150Mbps to make an accurate representation. However, codecs like this are quite smart in how they deal with data. So it's possible that you could get away with DNxHD 115 or so and get a visually similar copy. Your data has grown in size, but not by a lot, and your computer is doing maybe 1/5 the work to play it back because it doesn't have to try to build complete frames on the fly, from the partial frames the camera recorded.

So this leads to an interesting question. Why don't modern NLEs have trouble playing back H.264 stuff? This is primarily because this is now offloaded to the GPU on the video card. GPU's excel at doing this kind of thing. And most modern NLEs have the capability of handing off this part of the job to the GPU. The problem YOU are having is that Vegas 8 doesn't support GPU processing. So it forces the CPU to do all the work. Later versions of Vegas, and just about all other NLEs on the planet, hand this off.

So your solutions are really these: Transcode to a codec that will work better on your timeline, upgrade to a version of Vegas that can support a GPU (assuming you have one), switch to an editing program that can take better advantage of your hardware. The first option is attractive, because it's free or cheap. DNxHD, Cineform, etc. The second option isn't too bad. The third option is the hardest and most expensive.

I hope this helps you and others in understanding what's going on.