Is CBR really CBR ?

[Bob01605]

I recently converted an 82 minute cartoon feature to SVCD for my grandson. I selected CBR to save time with a bitrate of 2460 KBps and 192 sound to fill two 80 min CD-R's. When I played the SVCD in PowerDvd and turned on the information option I was surprised when the bitrate VARIED from about 1.6 MBps to over 3.0 MBps. I thought this was a Constant Bit Rate - CBR ? PowerDVD says it varied ?

I do understand that CBR varies bits within each FRAME according to the Image Quality Priority - more bits to complex parts as the number gets lower - but why is PowerDvd reporting quite VARYING bitrates each second for a CBR encode ?

Bob

[Labersack]

Have you also tried to check the movie with BitrateViewer (http://www.tecoltd.com/bitratev.htm)?
I don't trust PowerDVD...

[DSPguru]

i can assure you that the audio bitrate IS cbr.


Cheers,
Dg.

[Clixo]

if we can believe in what bitrate viwer reports cbr is NOT cdr i just mabe a few tests using CBR and in everycase i get vbr results.
exemple;:


Num. of picture read: 40683
Stream type: MPEG-2 MP@ML VBR
Resolution: 480*480
Aspect ratio: 4:3 Generic
Framerate: 23.98
Nom. bitrate: 1602800 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 10
Pic. structure: Frame
Field topfirst: Yes
DCT type: Frame
Quantscale: Linear
Scan type: ZigZag
Frame type: Progressive
Notes:

this was the result file of this encode:

Image Quality: 10
VAF file creation: On
Video Encoding Mode: CBR
Avg. Bitrate: 1603

i realy dont know if bitrate viewer is giving a good report cause sometimes i get bitrates higher than 3000 b when i get everytime the max bitrate setted by the defaults values of d2s

[Bob01605]

I just tested the movie cartoon that I mentioned above and like Clixomano I got VBR results on this CBR encode. Bitrate Viewer reports as below ..

Num. of picture read: 59602
Stream type: MPEG-2 MP@ML VBR
Resolution: 480*480
Aspect ratio: 4:3 Generic
Framerate: 29.97
Nom. bitrate: 2432800 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 9
Pic. structure: Frame
Field topfirst: No
DCT type: Frame
Quantscale: Linear
Scan type: ZigZag
Frame type: Interlaced
Notes:
----------------------------------------------------------
In addition bitrate viewer reported that the PEAK bitrate at any one point was 3812 kbps!! but the average for the entire part one of the movie( 59602 frames ) was 2873 kbps which I realize is combined audio, video and any "overhead" in the mpg file. Do you guys think this is a problem with BitRate Viewer incorrectly reporting this bit rate as VBR? - Or is this caused by some CCE peculiarity in the way in encodes in CBR?

Bob

[dvd2svcd]

Maybe you get VBR because the audio and video is muxed as VBR in bbMPEG. But that shouldn't mean a thing in the video stream. However, in the next release you can change that.

Did you try to load just the MPV file?

[movmasty]

a cbr video is constant bitrate inside the buffer time,
es. every 5 seconds 10mbps.
then one second could be 1.5, and another 2.5
in fact in a vbr video bitrate changes in a range of 20 times and more,
not only 1.5/2.........

[Clixo]

@dvd2svcd : the loaded test file is the mpv stream

[ux-3]

How could CBR be constant on a low level? When a complete picture is encoded, more bits will be required, when only changes are recorded, far less will do. Movmasty's suggestion makes good sense: When the buffer is filled at 2x, it can be drained much faster, but not for long. So when youz find a very high bitrate, that should only be a burst, and never last near that "buffer time".

[mkanar]

The SVCD standard clearly states its video encoding standard as VBR MPEG-2 and not CBR, even optionally. Of course, it doesn't hurt to encode the video in CBR mode, as long as it gets retagged as VBR in the end.

I can't vouch for CCE, but I know that TMPGEnc's CBR mode attempts to keep the datarate as CBR, but that the information is actually encoded as VBR. Even with this, I'm pretty sure that TMPGEnc has to pad various frames in order to maintain CBR, although I'm not totally certain on this... if I recall, the older versions of TMPGEnc had a checkbox to pad the video if the video bitrate didn't maintain CBR.

Anyway, if the encoder doesn't think it needs to use all of the bits for a particular set of frames, then who am I to argue? :) Doesn't just about every single mpeg-2 decoder support VBR, except maybe in the case of a super-low bitrate below 300?

Why even have the option in DVD2SVCD's next version to encode as CBR? That isn't SVCD compliant, but maybe there is some benefit that I don't understand.

Thanks!

[m3taPT]

I agree with mkanar. Why wonder and lose precious ripping time on something thats useless and crappy? :devil:

[sandchar99]

mkanar:
Why even have the option in DVD2SVCD's next version to encode as CBR? That isn't SVCD compliant, but maybe there is some benefit that I don't understand.

m3taPT:
I agree with mkanar. Why wonder and lose precious ripping time on something thats useless and crappy?

I am sorry. I use CBR all the time, There is a benefit. I use it for the following reasons:

1) I encode at a high bitrate, ususally 2400 (video) or greater. I don't mind filling up three CDRs. It is almost as good as 4-5 pass VBR at that bitrate and 5 times as fast.

2) 1 pass VBR is OK but your not saving precious bitrate when the average is at ~2400 and, like me, Q is set at 4 or less. You ARE losing precision in calculating your final file size, often ending up with only a partially filled CD.

If you are looking for quality and speed and are going to spread it over 3 CDs anyway, who cares if the you save bits using 1 pass VBR when the scene is dark/low action. In fact, the reason I returned my APEX 800 was that the player froze when the bitrate dropped too low (anything lower than 1000).

[m3taPT]

Everything you said is true, i get ur point and its valid. But im a quality freak, and cbr or cq just cant withstand the quality revealed with a cce 5 pass (3cd too). ;)

[sandchar99]

Agreed

4-5 pass VBR is THE best. I, too, am a quality freak. But if your player plays non-spec SVCD, ie total bitrate greater than 2723 (or whatever) audio + video, fill up three CDs.

CBR. Save time on your encodes. Save money by preserving your motherboard/processor by not running it for 10-15 hours every evening.

:)

[m3taPT]

sandchar99: You completed what i said PERFECTLY. ;)

I only NOT use vbr 4-5 when the dvd source is not good.. old movies for example. For the rest.. long live vbr 4-5.

[markrb]

I really don't understand why people think CBR is inferior in quality to VBR when the same bitrate is used for Max and the CBR rate. Bits is bits. 2500kbps whether CBR or VBR is still 2500Kbps. What VBR gives you is disc space by not allocating bits where it isn't needed. Some scenes may only need 1/4 or less of the bits to keep up the quality while others need more.
Now if you were to state that a 120 minute video on 2 cd's using VBR looks better then the same video using CBR I would agree with you completely, but if you don't restrict CBR to that same 2 CD's there would be almost no, if any, difference and in fact there are cases where CBR will outperform VBR since the encoder can and does make mistakes on the low side. This cannot happen with CBR.

Having said all that Mpeg-2 is a VBR video method. It was developed as such and encoders like CCE and TMPG do there best to make a Quasi CBR and not a completely true CBR. On the other hand Mpeg-1 is a CBR video and the same is true of it and Quasi VBR. Now why the range was reported as so great I couldn't say since it should perform better then that.

Mark

[chainsaw135]

Yeah i have to agree with markrb on that one, a bit is a bit and the fact is i use vbr only because of the amount of disks i wanna use not because it looks better because cbr dosent look worse if not limited as markrb stated. There has been numerous threads on this matter over the past few months and tests that have been done the proof is in the pudding:) and even with out tests a bit is a bit is a bit.

[m3taPT]

Originally posted by chainsaw135
There has been numerous threads on this matter over the past few months and tests that have been done the proof is in the pudding:)

Exactly. Due to that same rotten pudding, cbr@2500 it the ONLY way cbr is bearable. CQ is also too slacky, did more than 60 tests, reading threads on the forum, and only replied to a very few cause i dont think its worth the bother to anyone. (looking at a huge pile of "CQ tests")

Now, if you ask me, cbr@2500 or vbr... dammit, i like to control the size of my end pudding. I'd hate to have to use 4cds just for 5 extra minutes. And no cutting on the audio, if its less than 224, then its not close to the original.

[chainsaw135]

Well i guess your eyes see different then mine, which is fine the fact that you say cbr is good only when you reach 2500 is a false statement, i've done cbr at 1800 that looked just fine to me, either way i've done plenty of my own tests and my view stands as posted.

[m3taPT]

If you say that, then yes, im sure my eyes see different than yours.

[mkanar]

IMHO, some niche users have reason to utilize CBR encoding and by all means, they should!

However, I 'believe' that padding a video stream with meaningless bits just for the purpose of maintaining CBR rather than VBR. If the encoder can use the bits, then by all means it should. However, TMPGEnc for one will sometimes not use all of those bits, even in CBR mode. When this happens, TMPGEnc offers the 'padding' option which adds 100% meaningless bits. As we all know, CCE works very differently than TMPGEnc and perhaps it is able to put those extra bits to use in CBR mode.

So you've encoded a video stream in CBR mode, but the SVCD standard calls for VBR. Therefore, bbMPEG simply tags the CBR stream as VBR while remuxing the audio, video, and other data. The tags are now different, but the video stream is still the same video stream that was encoded in CBR. CBR marked as VBR equals same quality of that same CBR stream marked as CBR.

I'm simply afraid that some users that encode in CBR will use the advanced mode and set bbMPEG to mux in CBR mode, because that seems to make sense to them.

blah blah, I think we're all pretty much in agreement about things, but we just have to explain ourselves, no? :)