[John Bean]

There are too many variables involved to figure out what might be the problem.

Try this for now since you have a deadline.

1. Render out your video as an AVI using a LOSSLESS codec like LAGARITH. If you don’t have it already, Google it and download it. It’s free.

Alternatively, you can also use a VISUALLY LOSSLESS codec like Cineform. You’ll get a smaller file size with this codec than LAGARITH. Cineform might already be included in your version of Vegas.

Set your audio to uncompressed PCM.

2. Using this AVI, use another encoder to compress it to your desired format.

Where is this video going to be stored at? A Blu-ray? A website like YouTube? That will affect what compression codec you will want to use for your final delivery.

[John Bean]

Vegas, like every app, depends on Windows operations and resources. So when Vegas has to *wait* for some Windows operation, like a disk write or memory read, the Windows OS will switch to another process (thread) like some other app.

As well, Windows is not a real-time OS. So every process (application or thread) gets a time-limited access to the computer resources. In the average case, every process gets equal time.

So turn your Windows system to its absolute bare minimum. Turnoff any program or services you don’t need.

Turn off all the fancy Windows management stuff like restore points and file indexing too.

Then, when you run Vegas, you can assign it to have the highest priority over every other process running on your Windows system. With a higher priority, Vegas will get more time allocated to it to use the computer’s resources.

Lastly, I’m not sure how optimize the Movie Studio version of Vegas is for multiple CPUs, especially an older version like 9. So, you’ll have to check on that too. An application still needs to be designed with multiple CPUs taken into consideration in order to maximize multiple CPU usage.

[John Bean]

If restarting Vegas fixes your BLACKOUT problem, it is most likely due to Vegas having some kind of memory issue; perhaps a memory leak.

This would be a BUG.

[John Bean]

Try rendering out the audio by itself using WAV (uncompressed PCM).

Then see if this WAV file has any problems.

[John Bean]

It seems somebody does know how to build a website? :p

Link is dead: https://www.frogpondmedia/enctest

Simple math really.

An uncompressed 1080p video at 30 fps runs at 1.5 Gb/s. So how do go from 1.5 Gb/s to 6 Mb/s without losing a lot of information, thus causing a ton of compression artifacts?!

So which is better?

Upscaling a 480p video at a high bitrate to 1080p, or, decoding a 1080p from a very low bit-rate like 6 Mb/s?

Upscaling algorithms vs compression algorithms?

I know I would rather watch the DVD version of Transformers than watch a 1080p-6 Mb/s stream of it.

Cheers!

[John Bean]

From this post: https://forums.creativecow.net/readpost/24/945296

Dave wrote:
That’s not right. He’s got very high quality 480p, but it’s still just 480p. If you upload very good quality 1080/24p to YouTube (I’ve sent them 20Mb/s AVC in the past), they will render it using the excellent x264 AVC CODEC to 1080/24p at about 6Mb/s.

While this isn’t anything to write home about, it’s actually pretty close to the lowest bitrate setting on my Panasonic HMC40. AVC at 6Mb/s is going to suffer terribly on fast motion, but it’s going to look much better than anyone’s 480p when displayed on a good television… not to mention the fact that the 1080p doesn’t need to be upscaled, only the 480p does.

I’m pretty in this quote, you are claiming a 1080p video at 6 Mb/s is superior to a 480p video at 23 Mb/s. And here we are talking about a 480p video encoded using AVC too!

In regards to Dave’s understanding of BITRATE, from the same post, Dave wrote:
The bitrate is going to be a very big factor when it comes to the quality of upscaling, which he’s got to do here. When you upscale compressed video, you’re upscaling the compression artifacts, too. The Canon 480p should look better upscaled than regular DV-class video, as long as he’s not shooting overly fast motion video.

Regardless of what video codec you are using, the BITRATE is a big factor when it comes to DECODING because it limits the number of bits the encoder can use to encode all of the frames in any given 1 second interval of the video.

A 1080p video at 6 Mb/s is limited to 6 Mb per second regardless of what codec is being used.

It is then up to the codec to adjust its parameters accordingly so as to satisfy the desired bitrate requirement. Maybe it means using bigger blocks. Maybe it means less sensitivity to temporal changes. Who knows?!

But in the extreme cases like we have here, it does not matter because it is not necessary to know the details of the codec’s inner workings.

In the context of this thread it is not necessary to get into the gritty details of any particular codec. Hence, it is not necessary to have degree in Cog-Psych and Math to understand what is going on. Just basic math and understanding of video structure.

In the best case scenario for an INTER-FRAME codec, if all the frames in 1 second are exactly the same, then the encoder can use almost all the available 6 Mb for the first frame and copy it over for all the remaining frames. But 6 Mb is still far short of the 50 Mb required for one frame of 1080p video. If your 1080p video was just a picture (repeated over and over), you still could not achieve LOSSLESS compression with a bitrate of 6 Mb/s.

In the worst case scenario for an INTER-FRAME codec, if all the frames in 1 second are totally different from one and other, the encoder must divide the 6 Mb among each of these frames. In the case of 30 fps, that is 200 kb for each frame (6 Mb / 30). In this case, this INTER-FRAME codec essentially behaves like a INTRA-FRAME codec.

In other words, a 1080p video at 6 Mb/s will have LOTS and LOTS of compression artifacts from its worst case scenario to its best case scenario.

Best case scenario for a 480p video: if all the frames are exactly the same in 1 second, only 8.29 Mb is required for LOSSLESS compression. Yes, LOSSLESS compression! This 8.29 Mb/s is well within the range for standard DVD videos. If your video is just one picture frame (repeated over and over), you can set your MPEG-2 encoder to LOSSLESS compression!

Worst case scenario for a 480p video: if all the frames are completely different in 1 second, then for 30 fps at 8 Mb/s, each frame gets 267 kb (8 Mb / 30). Now consider the bit-rate of the 480p-23 Mb/s video in this thread. That is 767 kb per frame in the worst case scenario (23 Mb / 30).

So it’s really not hard to see that a 1080p video at 6 Mb/s will have very much more compression artifacts than a 480p video with a very high bit-rate.

So the debate really boils down to this: upscaling algorithms vs compression algorithms

Can a 480p video at very high bit-rates upscale to 1080p and be of higher quality than a 1080p video encoded at low bit-rates like 6 Mb/s?

My position is that a 480p video encoded at very high bit-rates will have very much less compression artifacts. Because the compression artifacts are indeed low, when you then upscale to 1080p, the compression artifacts will still be very much lower than a 1080p video at encoded at very low bit-rates like 6 Mb/s.

Cheers!

[John Bean]

That YouTube video already has top and bottom BLACK BARS.

It looks like the person who uploaded it, simply captured it from their standard-definition cable-tv signal and uploaded it to YouTube without cropping the BLACK BARS out.

The actual video – without the black bars – is suppose to be widescreen 16:9. Given that the video frame size is 480×360 with black bars, that would mean the actual video (without the black bars) is just 480×270.

So you need to change your project settings. Personally, I’d go with a more standard frame size for 16:9 like 640×360.

So your PROJECT SETTINGS should be:
1. FRAME SIZE = 640×360
2. PAR = SQUARE
3. SCAN-TYPE = None (Progressive)
4. FRAME RATE = 30

After importing the video, then use the PAN/CROP tool. Simply select the preset for 16:9.

That is it! No more black bars!

[John Bean]

Here are some things to try.

1. Verify that your TEMPORARY FILES folder for Vegas has enough space. See PREFERENCES.

Shutdown Vegas. Then go delete everything in the Vegas TEMPORARY FILES folder before restarting Vegas.

If for some reason, you can’t delete all of Vegas’ temporary files, then see #2.

2. Is Vegas crashing on you? Some times when an app crashes, the process doesn’t completely die and get cleaned up by Windows. So some of the files it creates and uses, including temporary files, cannot be released back to Windows. So even if you restart Vegas, the new Vegas process may not be able to read and write to some of the files it needs.

3. Maybe one of the effects plugins or codecs you are using is having problems with Vegas. Perhaps you are using plugins and codecs that are incompatible with your 64-bit Vegas. Update all plugins and codecs Vegas maybe depending on. Ensure they are 64-bit compatible.

[John Bean]

Your *fix* of restarting Vegas seems odd.

If you restart Vegas and then render out your project, do the black-outs still show up in the rendered output?

Do the black-outs occur in the same frames every time you preview and render out? Or does it seem randomly?

What are the frame rates for your source media files?

What is your project frame rate set too?

What is your rendered output frame rate set too?

[John Bean]

Dave,

Please don’t get upset here.

Your claim that a YouTube 1920x1080p video at low bit-rates like 6 Mb/s is far superior than a DVD video at standard MPEG bit-rates like 8 Mb/s just doesn’t make sense mathematically, nor can it be validated with any visual comparisons.

Most YouTube 1080p videos are closer to 3.5 Mb/s too. Since AVC is better than MPEG-2, at best, you may only be able to claim that they are comparable in quality, ie. equal.

Just think about this: one uncompressed 1920×1080 frame video requires ~50 Mb (1920×1080 * 24 bpp)

One frame alone from a 1920×1080 video already exceeds the low bit-rate of 6 Mb/s. Low bit-rates of 3-6 Mb/s that you typically find with 1080p streaming websites and consumer camcorders just can not give you enough bits to store great quality 1080p video.

Where as one frame from a 720×480 video requires only 8.29 Mb (720×480 * 24 bpp). Then using the INTER-FRAME encoding algorithms of the codec, subsequent frames can be recreated without much more new bits of information. This is all well within the standard bit-rates of 7-9 Mb/s for DVD videos.

Cheers!