[John Bean]

If your PREVIEW looks as expected than you are rendering out using an incompatible template.

Most likely your RENDER-AS frame rate does not match your PROJECT SETTING’s frame-rate and/or your source media frame rates.

When you RENDER-AS, Vegas will indicate with an ‘=’ which templates best matches your PROJECT SETTINGS.

Since you are NOOB, for now you should stick to selecting one of the templates that Vegas suggests.

[John Bean]

It should also be noted that:
a video’s BIT RATE includes information about its FRAME-SIZE (resolution)

A video’s FRAME-SIZE is an integral part of its encoded BIT-RATE value.

In most scenarios, videos of higher bit-rate should also have a higher FRAME-SIZE.

For example, as in Andre’s case:
480p->23 Mb/s
720p->47 Mb/s

So it should be no surprise that a YouTube 1080p-6 Mb/s video is of lower quality than a 480p-8 Mb/s video.

Thus, a video’s BIT-RATE value provides us with more information about the quality of a video than the video’s FRAME-SIZE.

[John Bean]

Two ideas come to mind:

1. It could just be that your computer system is not *powerful* enough to handle the high quality and/or highly compressed quality of your videos. If this is the case, you will need to upgrade your system (more memory, better CPU, new motherboard, etc …)

or

2. You have a version of Vegas that may not have the right codec to properly handle your video. Older versions of Vegas could not handle many camera AVCHD video formats. If this is the case, you should upgrade your Vegas version.

[John Bean]

Try a clean re-install of the latest Sony Vegas Pro 10 build.

If you don’t already have the latest Sony Vegas Pro 10 build, you can download the latest update build from their website.

Uninstall your Sony Vegas Pro 10.

Reboot.

Then re-install Sony Vegas Pro 10 using the latest build you have.

[John Bean]

So your MEDIA PROPERTIES for your source video has a SCAN-TYPE field order of NONE (Progressive)?

Then, why do you need to set the DEINTERLACE METHOD to INTERPOLATE?

If your source video is PROGRESSIVE (None), then the DEINTERLACE METHOD can be left at NONE. It doesn’t matter what you set the DEINTERLACE METHOD two because your a PROGRESSIVE video does not need deinterlacing.

Or perhaps, you mean you changed the PROJECT SETTING Field Order to NONE?

[John Bean]

Variable Bit Rate vs Constant Bit Rate

variable – the bit rate can vary around the target median bit rate you have set

constant – the bit rate remains constant through out the video

It really just depends on the quality of your video and where the video is going to be stored (uploaded) to.

If your source videos are all of very high bit-rate, similar or equal in value, then a constant bit rate might be a good choice. For example, say all of your source videos are around 25 Mb/s. Then you might want to use a constant bit rate of 25 Mb/s.

If your source videos are all of varying bit-rates, or your final composition contains a lot of frames of varying bit-rates, then the variable bit-rate setting may be a good choice here.

A variable bit-rate will allow frames that have a lot of information (ie. action, movement, effects, etc.) to have a higher bit-rate by *taking* bit-rates away from frames with less information, so that the target MEDIAN bit-rate you selected is maintained throughout your video.

The other consideration is storage of your video. A variable bit-rate can potentially in most cases lead to smaller bandwidth (storage) requirements. Frames that have very little information (like black frames) will not require a lot of bandwidth. But if you chosen constant bit rate, then every frame in your video will be encoded at that constant bit rate even if it is not necessary to do (like on black frames).

Those are probably to the two main things to take into consideration.

For most cases, VARIABLE BIT RATE is the best choice.

[John Bean]

Just try it!

Re-wrapping (re-muxing) should not be a long process.

If Handbrake takes a long while to complete, then my guess is that it is doing some kind of encoding.

I believe there are some GUIs for FFMPEG out there, like WinFF I believe. But I don’t use them.

Because you will have more control and customization using ffmpeg from the commandline.

Plus, it will make feel like a NERD … and hence smart and cool!

[John Bean]

I should of used the word *decode* instead of upscale.

“Based on *visual comparison* only, you can verify that a YouTube 1080p video will not *decode* to 1920×1080 as good as a DVD 480p video can *upscale* to 1920×1080 at bit-rates equal-to or greater than YouTube’s 6 Mb/s for 1080p.”

On a 1920×1080 HDTV or monitor, compare a good quality DVD movie to the best quality YouTube 1080p video you can download. It doesn’t even come close that the DVD movie is better!

And this is because a 720x480p-8Mb/s video has *potentially* more information per frame to accurately decode to 720×480 and then up scale to a higher resolution like 1920×1080.

A 1920x1080p-6Mb/s video does not contain 1920×1080 pixels of information! It contains very much less information to decode with. Much less than what a 720x480p-8Mb/s video has to decode with. The analysis was done in my previous post.

And of course the video CODEC used matters when comparing video quality! I clearly stated this and made sure to make it clear during my analysis.

The video codec and the settings used for it, must be equal or similar in quality in order to better estimate which video is of better quality if all you know besides the codec is the FRAME SIZE and BIT-RATE.

And in the context of this thread, we are for the most part talking about videos that have similar quality codecs.

And my analysis of LOSSLESS compression was needed to demonstrate why a 720x480p-8Mb/s video can potentially contain more accurate information to decode with than a 1920x1080p-6Mb/s video, when a LOSSY codec is eventually used.

All in all, the point I making was making to Andre (the OP) was that a video with a bigger FRAME SIZE is not necessarily going to have a better quality than a video with a smaller FRAME SIZE, especially when there is huge disparity in the BIT-RATE values.

Assuming the video codecs are equal or similar: in most scenarios, you are better off to have a smaller FRAME SIZE video with a HIGH BIT-RATE than to have a bigger FRAME SIZE video with a LOW BITRATE. In other words, a HIGH BITRATE low resolution video that is UPSCALED to a higher resolution – more often then none for the standard cases – will be better than a video at that same higher resolution but has a LOW BITRATE.

Cheers!

[John Bean]

Oh NO! By no means did I say or suggest that the BIT-RATE value is the *sole* indicator of quality for a video.

In the same token, in no ways is just knowing the FRAME-SIZE a good indicator of the quality for a video, if we assume LOSSY compression is involved (which is the case 99% of the time).

Just because a video claims to be 1080p does not mean it is a good quality video that will look great on a 1080p TV or monitor such as a 52″ 1920×1080 HDTV.

Based on *visual comparison* only, you can verify that a YouTube 1080p video will not upscale as good as a DVD 480p (or i) video at bit-rates equal-to or greater than YouTube’s 6 Mb/s for 1080p.

A DVD video can have a MAX bit-rate of 9.8 Mb/s. Most DVD videos average around 8 Mb/s.

And if you do the MATH as well, you can verify mathematically why a DVD 480p video is more often then none better quality than a YouTube 1080p.

That is why sites like YouTube do not advertise their BIT-RATE values. They only advertise 1080p!

Similarly, many cameras will also advertise that they do 1080p video capture. But what they don’t advertise is the BIT-RATE! If you buy a 1080p camera but that camera only captures at bit-rates like YouTube’s 6 Mps, then your 1080p footage will suck!

In the context of this thread, what I said was a generality: in general, knowing the FRAME-SIZE and BIT-RATE will give you a *good* indication (estimate) of the quality of the video in comparison to other videos.

And in the context of this thread, we know the FRAME SIZE, BIT-RATE, SCAN-TYPE, and CODEC. We then, can also assume typical values for FRAME RATE (24, 30, 60).

So based on the context of this thread, on the surface, one can safely conclude with *great accuracy* that Andre’s 480p @23 Mb/s video is also a much HIGHER QUALITY than YouTube’s 720p and 1080p videos.

By QUALITY, we mean how LOSSY is the video compressed. The closer the compressed video is to representing its ORIGINAL UNCOMPRESSED self, the smaller the LOSSY factor, and hence, the HIGHER the QUALITY.

To definitively conclude which video is of HIGHER QUALITY you need to know:
1. Frame size
2. Frame rate
3. Bits per pixel
4. The CODEC type and settings

To illustrate, let’s compare these two videos:

Video#1: 1920x1080p (23.976 fps, 8 bpp) @6 Mb/s
Video#2: 720x480p (23.976 fps, 8 bpp) @8 Mb/s

First, we will do a LOSSLESS compression analysis.

For Video#1: 1920x1080p (23.976 fps, 8 bpp) @6 Mb/s

Bits per frame = pixels per frame * bits per pixel
= (1920×1080 ppf) * 8 bpp
= 16588800 bits/frame
~= 16588.8 kb/frame

Bits per second = bits per frame * frames per second
= 16588800 bpf * 23.976 fps
= 397733068.8 bps
~= 397.7 Mb/s

=>for a 1920x1080p (23.976 fps, 8 bpp) video, in its uncompressed form, it has a BIT-RATE of 397.7 Mb/s.

Compression ratio = target bit rate / uncompressed bits per second
= 6 Mbps / 397.7 Mbps
= 6000000 bps / 397733068.8 bps
= 0.0150854944
~= 66.2 to 1

=>to achieve a TARGET BIT-RATE of 6 Mb/s, for a LOSSLESS compression, a video stream of 1920x1080p (23.976 fps, 8 bpp) requires a compression ratio of about 66.2 to 1.

That is, for LOSSLESS compression, roughly 66.2 bits of uncompressed video information must get encoded to 1 bit to achieve a TARGET BIT-RATE of 6 Mb/s.

Or stated differently, for LOSSLESS compression, 1 bit of compressed video information must decode to 66.2 bits of uncompressed (original) video information, if the desired TARGET BIT-RATE is 6 Mb/s.

On a PER FRAME basis, a 1920×1080 video frame compressed by a factor of 0.0150854944, gives:
=> bits per frame * compression ratio
= 16588800 bpf * 0.0150854944
= 250250.2495 bits/frame
~= 250 kb/frame

=>for LOSSLESS compression, a video stream of 1920x1080p (23.976 fps, 8 bpp) at 6 Mbps has 250 kb/frame of information.

=>to obtain a TARGET BIT-RATE of 6 Mb/s for LOSSLESS compression, the encoding video codec must compress 16588.8 kb/frame of ORIGINAL UNCOMPRESSED video information into about 250 kb/frame.

For Video#2: 720x480p (23.976 fps, 8 bpp) @8 Mb/s

Bits per frame = pixels per frame * bits per pixel
= (720×480) ppf * 8 bpp
= 345600 bits/frame
= 345.6 kb/frame

Bits per second = bits per frame * frames per second
= 345600 bpf * 23.976 fps
= 8286105.6 bits/s
~= 8.286 Mb/s

=>for a 720x480p (23.976 fps, 8 bpp) video, in its uncompressed form, it has a BIT-RATE of 8.286 Mb/s

Compression ratio = target bit rate / uncompressed bits per second
= 8 Mbps / 8.286 Mbps
= 8000000 bps / 8286105.6 bps
= 0.965471644
~= 1.0358 to 1

=>to achieve a TARGET BIT-RATE of 8 Mb/s, for a LOSSLESS compression, a video stream of 720x480p (23.976 fps, 8 bpp) requires a compression ratio of about 1.0358 to 1.

That is, for LOSSLESS compression, roughly 1.0358 bits of uncompressed video information must get compressed to 1 bit to achieve a TARGET BIT-RATE of 8 Mb/s.

Or stated differently, for LOSSLESS compression, 1 bit of compressed video information must decode to 1.0358 bits of uncompressed (original) video information, if the desired TARGET BIT-RATE is 8 Mb/s.

On a PER FRAME basis, a 720×480 video frame compressed by a factor of 0.965471644, gives:
=> bits per frame * compression ratio
= 345600 bpf * 0.965471644
= 333667.0 bits/frame
~= 333.7 kb/frame

=>for LOSSLESS compression, a video stream of 720x480p(23.976 fps, 8 bpp) at 8 Mbps has 334 kb/frame of information

=>to obtain a TARGET BIT-RATE of 8 Mb/s for LOSSLESS compression, the encoding video codec must compress 345.6 kb/frame of ORIGINAL UNCOMPRESSED video information into 334 kb/frame.

TO SUMMARIZE:

To achieve LOSSLESS compression

Video#1=1920x1080p (23.976 fps, 8 bpp) @6 Mb/s
=> 250 kb/frame of COMPRESSED information must decode back to 16588.8 kb/frame of ORIGINAL UNCOMPRESSED information to achieve LOSSLESS compression

Video#2=720x480p (23.976 fps, 8 bpp) @8 Mb/s
=> 334 kb/frame of COMPRESSED information must decode back to 345.6 kb/frame of ORIGINAL UNCOMPRESSED information to achieve LOSSLESS compression

This illustrates who difficult it is for YouTube to obtain LOSSLESS compression. Trying to compress 16588.8 kb/frame of ORIGINAL UNCOMPRESSED information to 250 kb/frame is impossible! (or nearly impossible?)

In other words, the only way to achieve a TARGET BIT-RATE of 6 Mb/s for a 1920x1080p video, is to compress it to the MAX using a LOSSY compression codec! So a ton of video information is being thrown away!

If LOSSLESS compression was possible for a 1920x1080p-6Mb/s video, then of course, the 1920x1080p-6Mb/s video is of HIGHER QUALITY than a 720x480p-8Mb/s video. But this is not possible!

In comparison, for a 720x480p (or i) video at 8 Mb/s, it is much easier to achieve LOSSLESS compression. Less compression is needed.

Which is of HIGHER QUALITY for LOSSY compression?

Let’s assume we take a UNCOMPRESSED 1920x1080p video and then scale it down to create an UNCOMPRESSED 720x480p video. So we now have two videos of different frame sizes of the same video.

Now if we use the same LOSSY codec to compress these two videos, a 720x480p-8Mb/s video will contain more *accurate* information than a 1920x1080p-6Mb/s video.

This is easily seen by comparing the bits per frame requirement for LOSSLESS compression:
720x480p-8Mb/s => 334 kb/frame
1920x1080p-6Mb/s => 250 kb/frame

=>So using the same LOSSY codec, the 720x480p-8Mb/s video can compress to 334 kb/frame, while the 1920x1080p-6Mb/s video can only compress to 250 kb/frame.

=>So using the same LOSSY codec, the 720x480p-8Mb/s video is of HIGHER QUALITY than the 1920x1080p-6Mb/s video.

=>Hence, in this scenario, the 720x480p-8Mb/s video can upscale back to 1920x1080p much better than the 1920x1080p-6Mb/s video.

=>THIS IS WHAT I MEAN when I say you can *generally* have a good estimate of how good the quality of a video is … in comparison to other videos if you only know its FRAME-SIZE and BIT-RATE.

It is by no means definitive, but most of the time using this quick estimation will prove to be correct.

BUT in reality, YouTube uses AVC and DVD uses MPEG-2 (both are LOSSY codecs).

AVC is a better compressor than MPEG-2 in that it can compress more information of the same video.

So to get a more *accurate* assessment of QUALITY when comparing 1920x1080p-6Mb/s AVC video to that of a 720x480p-8Mb/s MPEG-2 video, you will need to calculate their EFFECTIVE BITS per FRAME information.

The EFFECTIVE BITS per FRAME value will tell us how many bits per frame after DECOMPRESSION (decoding) is is equal to the ORIGINAL UNCOMPRESSED bits per frame. In other words, how LOSSY is the compression.

But most of the time, you will not be able to access the ORIGINAL UNCOMPRESSED video to make this analysis.

Even still, you can safely guess and be right most of the time that a DVD video of 720×480 @8Mb/s is of HIGHER QUALITY than a YouTube video of 1920x1080p @6Mb/s.

Hopefully, my analysis is sound here. If not, please do correct me! :p

[John Bean]

It doesn’t look like MPEG Stream Clip can re-wrap .MP4s to .MOVs without re-encoding.

You edit your clips in Vegas. Then you rendered it out to lossy codec. Lossy means you lose you information, and hence quality. Then when you use MPEG Stream Clip, the app uncompresses your video and then it recompresses it to a H264 video inside a MOV file container.

[source video]->VEGAS->{lossy compression}->[MP4 video]->MPEG-STREAM-CLIP->{uncompresses}->{lossy compression}->[H264 MOV video]

So along this chain, video data is being lost every time you compress and uncompress to and from a lossy codec. Hence you lose quality.

I don’t use Handbrake either, but I think its very similar to MPEG Stream Clip.

Google: ffmpeg

Download and install it. It’s free.

Then open up a command line terminal and type: ffmpeg -i test.mp4 -vcodec copy -acodec copy test.mov

where “test.mp4” is the MP4 you rendered out from Vegas, and “test.mov” is the new MOV file you want to create.

That’s it!

If you’ve never used a command line terminal before, now is a good time to learn!