Vegas BR-out template vs DVDA recompression

megabit wrote on 11/14/2008, 4:57 AM

OK - so, after a long time busy with downconverting my EX1 HD to an SD DVD, back to HD and BD :)

I'd like to omit detailed description of my doubts on purpose for now (so that I don't suggest anything to a person who is kind enough and answer this question), just please tell me:

- in order for DVDA 5 to avoid re-compression, which are the maximum quality settings of the m2v files you render out from Vegas for DVDA to use when authoring BD? I mean:

1. do files, rendered basing on the Vegas default template "BluRay 1920x1080-50i, 25 Mbps" work for you, or do you need to modify them and change the maximum bitrate from 30Mbps to - say - 28Mbps?

2. Can you somehow avoid recompression in Vegas set to 50i, when a progressive media is inserted into the project?

Both question are of paramount importance for getting the best possible BD-delivery results from the EX HQ sources, as their bitrate is high (35Mbps) and they're best when shot in progressive mode...

Also, the absolute maximum bitrate that DVDA can put on a BD without recompression, is going to be even more important with the advent of recorders such as the Flash XDR / NanoFlash, capable of 50 or 100 Mbps !

Comments welcome,

Piotr

Back to post

Comments

blink3times wrote on 11/17/2008, 1:55 PM

As usual, when you turn to technical matters, you are wrong blink"

Well, first of all Terje, as I have said many times (and quite contrary to you)... I have no ego problems at all, so admitting wrong is something I am fully capable of doing. You would have in fact seen this if you had bothered to read further.

Second... YOU'RE never wrong 'eh...... (from another thread):
-------------------------------------------------------------------------------------------------
Also - there are different versions of Vista 64 bit - some are capable of handling more RAM that others.
----------------------------------------------------------------------------------------------------
You were in fact corrected on this issue. Of course because you DO seem to have a rather large ego problem, we're all going to hear that you're right and we're all just misinterpreting your words ;)

Third: Your posts do not help Megabit at all. If you wish to tell me ho UN-technical I am... then do it in another thread and don't mess this one up.

Jay Gladwell wrote on 11/17/2008, 3:10 PM

Glad to hear you got it figured out! That has to be a load off your mind. I know how frustrating that kind of thing can be.

Were you able to determine what the problem was (or did I miss that)?

farss wrote on 11/17/2008, 3:20 PM

"Were you able to determine what the problem was (or did I miss that)?"

That was the final episode for this year......

Seriously, I too would love to know how this was finally made to work.

Bob.

megabit wrote on 11/17/2008, 4:12 PM

Bob & Jay,

Unfortunately, I cannot say I know what was going wrong (and believe me - being a CAD engineer by profession, when I can't find the reasons for problems, it doesn't make me feel any better when the problem disappears by itself; I have this uncomfortable feeling it will show its ugly head again, when I have a strict deadline :)

Generally speaking, my method can be outlined like this:

1. I made sure the way of rendering the media to be used in DVDA project are all BD-compliant, and do not require re-compression, by testing them in a separate, simple project

2. I made sure the disk space is plenty, the asset names are legal, and do not contain extended ASCII characters

3. Only then did I star to re-create my projects step by step; right after something important was added (like big jpeg for a menu background, or a submenu with scene selection) - I always tried to prepare a BD; as it usually failed with this dreaded message about invalid parameter, I saved, closed DVDA and restarted - luckily enough, after reopening it always was able to render !

As I said earlier - this, and my other problem with Vegas downconverting HD to widescreen PAL for DVDA - should definitely be addressed by SCS.

You have probably noticed by now that I'm not one of those who rant about Vegas and/or DVDA being "unusable"; 99% of time it works for me just great. But this remaining 1% can be very frustrating...

Thanks for your help,

Piotr

blink3times wrote on 11/18/2008, 9:54 AM

This I find quite interesting.... (further to the cbr/vbr conversation)

This is from the Roxio DVDit Pro HD user manual:

CBR (constant bit rate) and VBR (variable bit rate) are two ways of encoding video.

Be it right or wrong, Roxio is stating that vbr CAN produce a smaller file than cbr

megabit wrote on 11/18/2008, 10:21 AM

Isn't it exactly what I always kept saying?

farss wrote on 11/18/2008, 12:53 PM

Agree with Piotr here. It says exactly what we've been saying.

"VBR encoding can provide the same quality as a CBR encode but at a lower overall bit rate (so

Note the "at a lower overall bit rate" part. That means at a lower AVERAGE bitrate. The average bitrate will determine the size of the file for typical video and it will be the same sized file as CBR using the bit rate that was used as the average for the VBR encode.

Can I point out that I actually took the time to test this before I said anything? Despite already having a pretty good idea of how the mpeg-2 encoding process works I still wanted to make certain I hadn't misunderstood something.

A more interesting discussion than the basics of arithmetic would be how the sliding window averaging system works in VBR encoding and if more than 2 pass VBR yields even better results.

If you want to really see what the mpeg-2 encoder is doing get a mpeg-2 analyzer.

Bob.

Terje wrote on 11/18/2008, 1:43 PM

so admitting wrong is something I am fully capable of doing.

Which is why the last technical discussion we had, when I showed you how SCS confirmed how wrong you were, that you put both fingers in your ears and went "la, la, la I am not going to listen to you"

You were in fact corrected on this issue

I was, and I have no problem with that. That is why I had no comment, I was corrected and he was right.

Terje wrote on 11/18/2008, 1:49 PM

encoding can provide the same quality as a CBR encode but at a lower overall bit rate (so you can fit more video on the disc),

Roxio is correct and you are still wrong. VBR will typically yield smaller files with the same quality as CBR, but if they are encoded with the same bitrate then they are the same size. I do assume you understand that there is a difference between the concept of quality and the mathematical bitrate.

Here is an extreme example. If you film a wall with a uniform color for an hour, it can theoretically be encoded, with a perfect encoder, at just a little over 24 (8 for each color) bits per hour. If you encode it at 50Mbit/sec the two files will be extremely different in size but identical in quality.

blink3times wrote on 11/18/2008, 2:29 PM

"Can I point out that I actually took the time to test this before I said anything? Despite already having a pretty good idea of how the mpeg-2 encoding process works I still wanted to make certain I hadn't misunderstood something."

Yes.
I tested as well and got pretty much what you did.
But Terje is so nice as to place an extreme example on the board... A smaller file is produced. Now I'm sure that if 2 pass vbr is used you would probably get a better quality (haven't used 2 pass yet) but I have seen the results of single pass vbr and it isn't pretty.

blink3times wrote on 11/18/2008, 3:23 PM

Okay...

I redid my test (2 minute HDV) only this time I did not set the average at the HDV rate. Instead I set the average at 15M in order to give VBR some head room to play with.

The test strip was indoors with average lighting
VBR was set for 15M average, 30M high, and 10M low (2 pass) and took 4:29 to render
CBR was 15M and took 2:09 to render

My results were as follows:
VBR file size= 235,794,432
CBR file size= 237,525,104

When burned to disk and played back in the PS3:
CBR varied in bit rate between 14.6 and 15.6
VBR varied in bit rate between 9.3 and 28.3

As for quality.... my wife and I couldn't tell the difference between the 2.

The VBR file size is DEFINITELY smaller..... BUT it does however produce the same quality (or at least no difference that I could see)

farss wrote on 11/18/2008, 3:43 PM

Actually I think you'll find it was me, well at least if you read my post regarding my tests you'll see that a VBR encode of solid black or white will produce a file size way, way under what you'd think it would. That's why I said "typical" video. Unless your video is all blind polar bears in a snowstorm those outlier results are quite irrelevant. If you understand how an mepg-2 encoder works you'd also understand that it has no mechanism to produce a bigger file.
During the motion estimation phase of the encode it will not find any difference between frames or macroblocks to be more specific, about the only thing using any of the bandwidth and hence making the file larger would be the I frames.

If you're getting poor results from VBR encoding you're doing it wrong. See my recent topic on this very subject. Getting good results from mpeg-2 or any lossy encoding starts with what's in front of the camera. Even the quality of your tripod can have an impact on the results you get. Shoot good artifact free video with expensive cameras under good conditions and you can compress it dramatically. Use cheap consummer cameras with poor lighting and cheap kit in general and you're setting yourself up for problems and poor results.

Bob.

blink3times wrote on 11/18/2008, 4:39 PM

"Actually I think you'll find it was me, well at least if you read my post regarding my tests you'll see that a VBR encode of solid black or white will produce a file size way, way under what you'd think it would."

My test was not a black wall or anything of that nature.. It was an average shot indoors with average lighting and average human movement

Here's Terje's statement (which is incorrect):
VBR will typically yield smaller files with the same quality as CBR, but if they are encoded with the same bitrate then they are the same size.
Both my test pieces had the same average bitrate (15M) and the VBR test STILL came out smaller.

"If you understand how an mepg-2 encoder works you'd also understand that it has no mechanism to produce a bigger file. "
If you're talking about producing a file size BIGGER than the original then this would be true. If you're maximum bit rate on you input file was 28M then it wouldn't make much sense to encode at 30 or 40M

However if you're talking about vbr vs cbr then I would have to say it (theoretically) IS possible to get a bigger file than a cbr recording. If I set my average bit rate at 15M vbr (for HDV which has a bitrate of 25) and set my high at 28M, and the video is nothing but bright high action scenes... then I would expect a file size BIGGER than a cbr recording at the same bitrate setting. The cbr render would of course hover at 15M while the VBR render would be up in the 20's (or higher) most of the time Granted I haven't tried this yet so it's only theory I could well be wrong... depending on how seriously the encoder is about holding to the average setting.

ADDED:
I've been sitting here thinking about this and a question comes to mind.... Because VBR has the ability to rise to the occasion so to speak (provided you high rate setting is high enough) then logically speaking you SHOULD be able to operate with an average bitrate setting LOWER than that of a comparable CBR setting, thereby possibly saving more room on a disk. Does this not make sense? I know (or believe anyway) for example that it does not make much sense to set a vbr average at 25 and a high at 30 with hdv since an ORIGINAL hdv recording is at 25M to start with (added bits past the original bitrate recording is kind of useless since you can't get better quality than what was recorded in the beginning). In other words would it not make more sense (for HDV) to set an average at say..... 23M, then a high of 28 or 30. Does this make sense.... or am I over analyzing?

Terje wrote on 11/20/2008, 2:33 PM

Both my test pieces had the same average bitrate (15M) and the VBR test STILL came out smaller.

That is caused by an error in the encoder in reality. Perhaps error is a harsh word, an inaccuracy. The easiest way to show this is as I did above.
4 + 4 + 4 = 12 -> CBR, 4 units per time period (bits per second)
2 + 8 + 2 = 12 -> VBR, 4 units AVERAGE per time period (bits per second)

It's maths, and as such not really something that can be debated. I (among others) am right no matter what results you get from an actual encode.

If your CBR encode yields a larger file size that the VBR and the CBR is encoded at the correct bitrate, than the VBR encode isn't encoded at the bit rate you specified. If it was, the files would have been close to identical in size. Please note, there data in a video file that isn't video. If either of the two formats have more meta data like this than the other, then there will be a difference in bit rate.

I had a similar discussion with a friend some time back, he was encoding with the DivX encoder and strongly insisted that if he encoded a file to MPEG-2 with a VBR of 8M/s and then encoded a DivX file with 8Mbits/s, or even an H.264 file with the same bitrate, then the DivX and the H.264 files would be significantly smaller. Of course they are not, they are the same size as the MPEG-2 file to within a very small margin (meta related).

I would have to say it (theoretically) IS possible to get a bigger file than a cbr recording.

No, theoretically it is not. In practice it is probable that there is a difference in file size, but theoretically they should be identical in size, at least the video portion. When there is a difference in size this is due to non-video data (meta data as I said) in the file, which is small, and inaccuracies in the encoder, which can be much larger.

then logically speaking you SHOULD be able to operate with an average bitrate setting LOWER than that of a comparable CBR setting

And here you are correct. The advantage of VBR is not to get the file size down at the same bitrate, it is to get the file size down at the same quality or at least similar. Again, if you film a static blue wall for an hour and encode with a VBR encoder at 24 bits/hour, you should theoretically get exactly the same result that you would get with a CBR encode of 50 Mbits/s. The VBR file would here be about 1 byte plus a little overhead, the 50Mbits/s with the identical result would be many, many gigabytes large.

blink3times wrote on 11/20/2008, 3:00 PM

"That is caused by an error in the encoder in reality."

Okay so I have heard it all now... Terje is right and the ENCODER is wrong. You crack me up!

We're going to have to start calling you "wrong way" pretty soon there Terje!

megabit wrote on 11/22/2008, 3:37 AM

Back to the main topic, ie the DVDA Blu-ray disk compatibility of various render methods in Vegas.

As my faith has been shattered (see other threads on the subject) that the 25p->50i Vegas renders, required for BD compatibility, merely change 25p into 25PsF thus preserving the progressive quality, while preventing re-compression by DVDA - I have just rendered my 1 hour long concert into a 24p file. I used Bob's method of stretching the nested 25p project slightly so that it occupies exactly the same number of frames in the 24p Vegas project as it did in the original, 25p one. Then I set up a new DVDA project, set its properties to 24p progressive, and ...bummer!

DVDA wants to re-compress as it says the "Media is not compatible with the disk format" ....

Now, I must say I'm loosing confidence... any thoughts, why?

megabit wrote on 11/22/2008, 4:37 AM

OK, it seems mxf files (even though accepted by DVDA, starting with 5a, I think?) are the culprit.

I just rendered a 24p m2v, using Vegas own BR template, and it's NOT being re-compressed by DVDA.

So basically, a false alarm. My apologies.:)

farss wrote on 11/22/2008, 4:46 AM

Something going wrong there. A few thoughts.

a) You cannot change frame rate without recompression I would think.
b) Render a small section ( 1 second would do) to uncompressed AVI. I say small because otherwise it;s going to be a HUGE 1080p file. Bring that back into Vegas and check it's properties. If Vegas doesn't think the AVI is 24p then rendering to any other codec would yield the same problem.
c) In some respect using a Digital Intermediate such as NeoHD would make life so much easier. You're trying to avoid recompression and for good reason. A good DI codec means you can go through many intermediate renders (almost) losslessly. Either that or buy some big disks and work in uncompressed. At least use uncomp to run tests on tiny sections of your project. Rendering out an hour of anything to then find it don't work is soul destroying. I learned early on in this game to test, test, test. It keeps me sane.

Bob.

megabit wrote on 11/22/2008, 5:08 AM

Rendering out an hour of anything to then find it don't work is soul destroying. I learned early on in this game to test, test, test. It keeps me sane

Ha, you've the point here, Bob :)

However, you will be surprised if I tell you my Quad at 3 GHz only needs an hour for that project to render (yes, - real time); the project's main video track consists of plenty of short clips coming from longer ones, and active takes changing constantly; it also has a couple of B-roll cut-ins here and there on a separate video track, plus one full length, and two additional (shorter) audio tracks.

Other than that, it's relatively simple - just one global FX (broadcast safe).

So I guess real time rendering to 1920x90/24(25)p is not bad, is it?

And no, I am not going to uncompressed until I really have to; I have checked the overall timeline playback fps suffers badly with several uncompressed streams open at the same time, in spite of using pretty fast RIOD 0 (capable of over 200 MBps).

But back to the subject: I find it weird that SCS would allow DVDA to open MXF files while they need re-compression anyway; we all know DVDA cannot use multiple cores and hence is much slower than Vegas - so what's the point?

PS And even during this one hour of test rendering, I have plenty of other work to do simultaneously, and it's a paying job I'm doing, so no problems with as many trials as needed. Oh, perhaps there is one: when at 100% CPU, my PC is quite noisy with all the fans blowing at full speed - but a pair of good headphones plus a CD with good music solves that one, too :)

megabit wrote on 11/22/2008, 5:19 AM

Bob, I just re-read you point:
a) You cannot change frame rate without recompression I would think.

What do you mean? Of course I do recompress in Vegas; in DVDA I set the project properties to 24p and expect it to leave my 24p media alone - which it does, but NOT with mxf format.

I hope I'm more clear now :)

Terje wrote on 11/23/2008, 12:21 PM

Terje is right and the ENCODER is wrong.

Yes blink, and that is neither unusual, nor is it particularly surprising. The encoder does one pass through the material and estimates how it can arrive at the average bitrate desired. This is an estimate and will not be 100% accurate. If the encoder does more passes through the material then it will become more accurate. This is maths blink, but I guess you don't believe in maths either. There is no realistic possibility for a a two-pass or even more, to arrive at the precise determination of the appropriate bitrate.

With CBR this is not an issue, so it should be accurate.

Again, what is it about average you do not understand? Actually, what is it about "bitrate" you do not understand? Here is the simple truth blink, and it is not me "claiming" this, it is pure math.

Again, I will take it slowly. Assume a 3 second video, you want to encode it at 3 Mbits/s average bitrate and at 3 Mbits/s constant bitrate. The below shows how this might be encoded.

Average may be for example: 4 + 2 + 3
Constant will be: 3 + 3 + 3

How does this impact file size? Well, it is actually quite easy. That is what Mbits/s tells you. On the constant side, 3 Mbits/s means that every second the encoder produces 3/8 Mbytes of data (assuming an 8 bit byte on your computer, most have that now). The total amount of bytes produced by the encoder will be 9/8 Mbytes. For three seconds? What happens on the average side? Well, 4/8Mbytes for the first second, add 2/3 MBytes for the second and 3/8Mbytes for the third. Again, that is what the concept of "average" means. The encoder will, if 100% accurate, produce 4/8 + 2/8 + 3/8 Mbytes of data, in other words, 9/8 MBytes. Exactly.

Depending on the meta data stored with the video, there might be a slight variation but it should be very slight. The amount of VIDEO stored should be exactly the same. If it is not the same that can have one of two possible explanations, either the VBR encoder was unable to accurately estimate the bitrate needed every second or the CBR encoder did something similar. That means that one or both of them are NOT at the bitrate chosen by the user, but only somewhere in the right neighborhood.

I have no hope that you will ever listen to basic logic however, you simply don't have the capability.

Now, I am going to assume that you are not totally brain dead and I will give you a car analogy. If two cars start at the same time, and drive the exact same distance, which of the two will arrive at the target first? The two cars drive quite differently, one drives at a constant 60 mph, the other drives at 120 mph here, 20 there and so on, but over the total distance the second drives at an average speed of 60 mph.

Unsurprisingly, people who are not brain dead easily understand that the two cars will arrive at exactly the same point in time. Why would you assume that "average" in the calculation of video bitrate means something TOTALLY different than what it does when you drive a car blink? You see, that is exactly what you are claiming.