Could VBR ever be better than CBR??

[Cornucopia]

If-
Multipass VBR does more for the encoder, compared to CBR, than just bit rate allocation...

Then-
What if someone (here) actually tried encoding a difficult movie clip.
1st-CBR @2520
2nd-Multipass VBR@min2520,avg2520,max2520

Obviously, the file sizes should be nearly identical. (Inefficient bitrate tracking possible)

Next, ANY quality difference found should just be attributable to motion search prediction differences, NO?

Anybody want to ante up?

Scott

[mats.hogberg]

I may be dense, but isn't VBR with identical min, max and average bitrate = CBR? If not, please explain how the bitrate could vary if min and max are equal!

/Mats

[SatStorm]

same min/ave/max: Better allocation of data per field/frame, same filesize with CBR...

[vitualis]

same min/ave/max: Better allocation of data per field/frame, same filesize with CBR...

Exactly!

Also, it seems that no matter how much I describe it people just don't get it. BITRATE ISN"T EVERYTHING when it comes to the final quality. The accurate of the "motion search prediction" (for the want of a better term) is important too. This is BEYOND the little option you see in TMPGEnc.

I'm talking about the concept of it.

What does it actually mean when you set it from very fast to very slow? It means that the encoder spent more time working to find the best settings with the same bitrate. This is why very slow looks better than very fast.

When you encode multiple passes, this "motion search prediction" improves as well (yes, I KNOW THAT YOU HAVEN"T CHANGED THE SETTING IN TMPGENC, but I'm talking about the broad concept). Why? Because essentially the encoder has spent more time working to find the best settings even with the same bitrate.

The article I've referred to (about 4 times now and even quoted the relevant paragraphs twice) has a specific example of how motion vectors can be improved for a specific situation (fades) on the SECOND PASS. This is independent of bitrate allocation.

That is, a multipass VBR with min/max/avg the same as a CBR encode could hypothetically look better than the CBR encode.

For those who keep saying "isn't it just the same as CBR?" think about it! Just because something is "CBR" doesn't mean that the quality will be the same!! Otherwise, "very slow" wouldn't be any different to "very fast" as both are "CBR" with the same bitrate.

Obviously, any benefits from using VBR in such a situation are negligible. However, it is not "the same" as CBR.

Regards.

[SatStorm]

Michael, still watching Enteprize? I saw the whole first season twice, and I stand to my position: Babylon 5 rules!!!!! Voyager and Enterprise sucks!

Don't waste time anymore for debates like this. Sit down and write a good article for the subject and link those who interest there. You (we) waste much time talking that thing (CBR vs VBR vc multiVBR) all over again every six months or so. It is majochism after the 6 - 7 time

[vitualis]

B5??? The Next Generation was (and still is) the best SF series ever, and now released on DVD (in the voice of Mr Burns... "excellent!").

You're right. This is just masochism... All I have to post on this topic is "up" this thread.

Regards.

[SatStorm]

The Famous "SatStorm DVD Releases Inc" company, already published a limited (very limited, only one package in the world!) 6 DVD set of ALL Babylon 5 episodes! 5 seasons, with amazing 4:3 picture, Dolby souround sound, @ amazing 1/2 D1 Resolution!!!



Now in production from "SatStorm DVD Releases Inc" company, a 2 DVD set of the 13 Crusade episodes (B5's censored spinoff), in an amazing box set with collectable sign photos from JMS (THE creator of SciFI series!)



Future release: Farcape seasons 1 - 4, 100 SVCDs box Set.
This set is called: Even Puppets are better Star Trek



Also, watch out our new amazing item for kiddies: Star Trek The Next generation. Special KVCD release (4 episodes per CD, amazing better than DVD quality)
This offer ships with an amazing template for TMPGenc, let 8 hours of DVD quality video on any CD


For all visitors of http://www.firsttvdrama.com/enterprise/index.php3 a special offer: A Janeway naked photo



Remember: "SatStorm DVD Releases Inc". The best friend of any trek fan!

[SatStorm]

ohhhh....
I hope I wont banned from the forum, because I advertize "SatStorm DVD Releases Inc" company

B5 season one is also releasing this very month on DVD. The whole 6 DVD box set cost 30 Euros in Germany! (amazon.de)

Now, that kind of releases we - the dvd enthusiasts- need!

[adam]

I never thought a thread could improve by getting off topic, but this one just did.

No offense to those who sincerely care, but if you haven't gotten it by now your not going to get it.

But returning to the practicalness of using multipass VBR with max and avg equal, I'm not so sure one shouldn't do this, at least not if they have a decent computer. My PC does nearly double time per pass in CCE and even when I use full filters I still get over real time per pass and I only have an AMD 1.333 which is by no means cutting edge. So regardless of whether I do CBR or 5 pass VBR its still finished by the time I wake up. If I'm limited to an avg bitrate of 2500kbits, and quality can be improved by even a fraction by doing multiple passes, then why not?

[WarpEnterprises]

Is there a comparison example (screenshot) floating around for CBR/2pass/5pass that SHOWS a difference?
I'm just curious, especially on which details to look at.

[dc91gt]

For all my SVCD encodings up until recently, I'd do something along these lines (since I wanted to keep movies on 2-disc sets):

Tmpengc 2 pass VBR - min 1850 avg 2350-2450 and max 2520.

Average depends on the length of the movie, but most are in the 85-90min range, clipping credits.

The quality is FAR better then doing the same encode at CBR of 2350 or 2450. The motion is smoother.

I recently replaced my pioneer 343 with a C503 5 disc changer pioneer - so 2 disc movies are no longer important, as my lazy ass doesn't have to get up and swap out discs anymore, lol.

I'd really wish DVDR's would drop in price for "good" quality ones.. like $1-$1.50 each and not have to deal with SVCD's anymore.

-d

[aszep]

I may be a bit off topic, but my question is about the LOG file that Tmpgenc is creating while coding 2pass VBR.

The first part I'm ok with, but in the secon pass it gives lines like:
"Req bitrate=1268,51 kbps Org Req CQ = 65,86 Req CQ = 79,25 CQ correct = 1,62 (org 1,51)"
And codes it:
"Current bitrate = 1351,21 kbps"

Can anyone explain to me what those figures are indicating ? Send me a link if it is written some where, or drop me letter.

Thanks: Attila

[aszep]

To add something to the CBR-VBR theme: based upon my experience (not too much about 12 DVD to SVCD conversion) if I had bitrate problems (i.e.: 122minutes to 2CD) VBR looked better if I set maximum bitrate closer to average.

I think the point behind that is, that the encoder does not take to "many bits" away from light-to-code scenes to make them "blocky" to give them to scenes very-hard-to-code. Those few bits do not improve those hard-to-code scenes, but the others are made uglier if the encoder was allowed to go for higher bitrates.

I'll try to put an example together:

The movie has to be coded at 1600kb/s (480x576pal).

Setting 1.
Min 300, average 1600, max 3000
easy scene coded at 800kb/sec
normal at 1600
hard at near 3000.

Setting 2.
Min 300, average 1600, max 1900
easy@ 1300(!)
normal at 1600
hard at 1900.

Hard scenes are tending to be very quick, flashy ones. So one's eyes can hardly see whether it is a blocky "flash" or a nicely coded one,
but easy scenes are slow, static shots where block noise is easy to see.

These may apply to my taste only. Sorry if I was to long: Attila

[DJRumpy]

This ol thread? Just when you though it was safe to wade into the forum.

Only one thing to add since my original post. Knowing a little more about the actual MPEG stream, Key frames, and what goes on between, I don't see how CBR could look better, assuming the same max/min/avg settings for VBR, and CBR set to the same max, since the first pass did all the homework, the second and subsequent passes would all seem to be gravy.

Everything about an MPEG stream is motion. The difference between the same pixel across a frame. If the pixel has moved, change brightness, color, anything, it takes some bits (simplistic yes, but close enough?). If a pixel is motionless, it is not taken into the next frame (assuming the next frame is not a key frame?), and that bit is used elsewhere. Assuming a simple scene, where there was plentiful amounts of bitrate, and little 'motion' from the previous frame, the difference would not be noticable, as there is no shortage of bitrate.

BUT:
Same example, but lets consider a quick scene change. Now the encoder looks at it's previous frame, and then the next frame. It would have no frame of reference ON A SINGLE PASS, as the entire scene is different, with seemingly no reference to where pixel 'A' moved to. It would have to guess (badly), that pixel 'A' has moved, wasting large amounts of bitrate ( Adam, Snowmoon, someone correct me if I'm wrong here, as I don't know how an encoder reacts to a scene change..issue a new key frame?).

I may still be seeing this the wrong way, but everything I'm learning points to the fact that ANY change from scene to scene could be considered motion or whatever word you want to call it, as it still uses bits, in order to be carried to the next frame, and taking them away from something that might need them. VBR would allow you to 'predict' these changes, and allow for them, not wasting bits on scenes that do not change enough to require the bit's, and saving them for the scenes that do.

[DJRumpy]

Actually, reading my own post, I would think that the encoder would have to wastefully keep throwing bits after a scene change, since keyframes are a setting you can select. If it had 10 frames to go before the next keyframe, then it would have to use bits for every change that was not in the original keyframe. Considering a scene change, that could be like having 10 keyframes in a row. Very wasteful.

[bewley]

boathouse -

I hope you find this amongst all the other "stuff" in this post as I didn't see anyone mention it:

Sounds like a good idea, but if the video exceeds 2520 at any point doesn't that mean it will be outside the svcd/cvd standard.

One thing to be very careful of is max bit rate. I usually encoded my CVD's at 0-~3000-5150 and I have wonderful results yielding 30 - 35 minutes per disc. However, I have found many of my friends are unable to play these discs as their equipment can not handle the high bit rate. I would highly recommend that you run a few tests and see how high your DVD can handle before deciding on a max bit rate.

So if I encode at 352x576(cvd) and the bitrate exceeds 2520, will I still be able to create dvd's with these files without having to re-encode?

If you encode the audio at 48KHz, you will be in 1/2 DVD spec. This means you should be able to take the files and master them to DVD at a later time. If you decide to encode at 480x576 or 41KHz, you will have to re-encode at a later point to master to DVD.

Good luck!

[snowmoon]

I, P, B and scene changes.

To get a good idea on how that all works get the moonlight cordless mpeg stream analizer ( same site as the elecard codec ). This program shows you a graphical representation of the GOP structure and the size of each frame as well as decoding in either stream or decoder order. Each frame type ( I, P, B ) can take a scene schange, and it will bloat the size accordingly. This is one of the reasons DVD's look so good, their MAX bitrate allows for huge bloating of one GOP without ill effect.

Even with VBR this will have to steal bits from either the previous GOP or the next GOP since it cannot raise the bitrate/s over the MAX. This is the same type of activity CBR would have to do as well. The only reason VBR would look better is because some encoders do not enfoce VBR bitrates as tightly as CBR bitrates.

[Donovan]

OK - newbie here...

Does a VBR encode with I-frames only make sense, especially given that all the bits are carried through to the next frame?

[troyvcd1]

I just wanna know if there is any SMART person from CCE who reads this forum who can answer this question for good. They probably read this and just think it is cool to see what everyone else thinks.

[DJRumpy]

Donovan, that would essentially be an AVI in everything except name. The way the MPEG gets its compression is from leaving off bits that haven't changed from the previous keyframe.

[Donovan]

DJRumpy,

Thanks for the reply. There is obviously some compression that takes place. I had ~9Gig AVI which I encoded as CBR @ 8000 which ended up at ~2.8Gig MPEG-2. The same AVI encoded as VBR (Max 8000, Avg 7000 and min 2000) ended up being ~2.2/2.4 (I can't remember which).

The reason I asked is that it appeared that a VBR I-frame and CBR I-frame at the same bitrate would end up the same size. I guess my next question would be: Given my previous statement, would scene's with motion be any different between the 2? But I don't think I want to go there given the hot debate on the issues above...

I'll do some tests and draw some conclusions.

[DJRumpy]

Donovan, you seem to be confused as to what CBR, and VBR do. They don't change the way that the MPEG is put together, or the way it is compressed in the general sense. Both will still have I,B,and P frames. They both use bits to encode any changes from frame to frame. They both use keyframes at intervals. Creating a keyframe every frame, basically removes what compression in MPEG is all about. The ability to leave those bits out that don't change from frame to frame is how such a high compression rate is achieved.

To answer your other question, a complex avi, with alot of motion, would normally be smaller using VBR, and larger using CBR. However, if you use the same min/avg/max for VBR, that you are using for CBR, then you are essentially making a CBR, with better motion detection/bitrate allocation (assuming multipass was used). The filesize, however, should be consistant with the CBR, or pretty close, considering your scenario. I would be interested in your results though.

[KWG22]

I haven't totally finished reading this lengthy thread, but there always seems to be disagreement on this subject. Boathouse, I just wanted to say that you expressed exactly my questions on it. Thanks. And thanks to all.

[Donovan]

DJRumpy - thanks, you cleared up a few things for me.

As for my results - I need to create a smaller file to encode. My 9.8Gig AVI will take too long (a P4 2.53Ghz is on the cards for Xmas...)

[cdog]

D_Head

This message is to you...

CBR is not always better. If you encode lots of video, you should know this by simply looking at videos.

The best way is to encode a video using CBR > find a high motion area that is real blocky > slap the original source and encode a few pass VBR at the same bitrate or even LOWER average bitrate > Presto the blockiness is reduced or even gone.

Fiddle around with cce and you will see that this works very nicely for svcd encoding. TMPGENC does a decent VBR but CCE does exellent VBR

[luxx]

My personal experience:
I put 1,5 hours SVCD in 1 CD. I do it all the time with VBR, I tried with CBR and it was (clearly) lower quality. 800Mb of VBR look much better than 800Mb of CBR.

[DJRumpy]

Donovan, see if you can find a copy of CCE. Use multipass VBR (3-pass) to get the smallest file possible. The gains of more passes after that seem to be very minimal, and not worth the extra time. Use a minimum of 0 (or 300 if your standalone has problems with the 0 setting). Set your average, and max according to what standard your going for (VCD/CVD/SVCD).

For VCD, I would suggest Min 0, Avg 1000, max 1150.
For CVD/SVCD, I would suggest Min 0, Avg 2000, Max 2520

If you can't get a hold of CCE, than use two pass VBR with TMPGenc. It will be much slower to encode though.

[RoopeT]

Some comments:

CCE, for instance, seems to keep closer to the average. If you want REAL max values around 2500, specify 2800 to 3000 in settings.

Depends on the Q setting used. Use max 2500, avg 1000 and Q=1 and you'll get CBR 2500 (practically). By specifying 3000 max you'll risk having playback problems with many, many standalone players.

same min/ave/max: Better allocation of data per field/frame, same filesize with CBR...

CBR 2520 is equal to 2-pass VBR 2520/2520/2520 (TMPGEnc), if one uses manual GOP ("Force picture type setting"). With CCE, it's not possible to manually tell the encoder what GOP to use on different scenes, that's why it's possible that a multipass VBR 2520/2520/2520 might be better than CBR 2520.

[Donovan]

Thanks for the pointers above - will check them out.

In the mean time, I did 4 encodes last night using TMPGEnc. My source is analog (8mm) PAL captured using Pinnacle Studio 7 (720x576), rendered as an AVI using the S7 codec and every frame in the AVI is (I believe) a key frame. AVI file size is 623,808 Kb (2 min 48 sec's).

4 Files encoded as follows:
* 1. CBR at 8000kbps with I-frames only (~6 minutes to encode)
* 2. 2-pass VBR at 8000kpbs min/max/avg with I-frames only (~12min)
* 3. CBR using standard GOP at 8000kpbs (~55 min)
* 4. 2-pass VBR using standard GOP at 8000kpbs min/max/avg (~1:50)

All encoded files resulted in the same file size - 175,414 Kb.

The I-frame only encodes were inferior to the standard GOP encodes - obvious visible pixelation, even on a monitor. There was no (noticeable) difference between the CBR and 2-pass VBR encodes with the same GOP's.

The biggest factor for me would be encoding time and for this reason my vote would have to be for option 3 - half the time to encode as 4.

Now, what is the best GOP? Obviously not I-frames only (thanks DJRumpy - you made me think and do some tests and the result already is going to be a better DVD).

[snowmoon]

To really see the power of 2-pass try the following.

2-pass VBR with min=1500,avg=4000, max=9000. This should really show off the fact that once you go past a point, you cannot really teall the difference on most scenes. This file should be close to indistinguishable and half the file size.