Could VBR ever be better than CBR??

[DJRumpy]

Curious results on the I-Frame testing.

Here's an interesting link regarding I P & B frames if yer' interested. It sound like higher motion sources would benefit from B frames, more than simply using I frames alone.

http://www.disctronics.co.uk/technology/video/video_mpeg.htm

I had no idea you could get such a high compression ratio using only I frames.

I never play with the GOP structure. Some swear by it, claiming to produce miraculous results. I stick with the standard. I only download VCD, and never used it myself, while SVCD, and DVD formats look just fine to my eyes. Besides that, who knows what standalone I'll have in two years? You could always experiment with some of the KVCD (KCVD?) templates. A quick search of the forum should net you a link. He's constantly advertising them.

[snowmoon]

B frames allow the most compression since it allows macroblocks to be re-used from almost anywhere in the current GOP. B frmaes also are the most processing and memory dependant since you must decode every other frame it pulls from before you can decode the frame.

P frames can only use macroblocks from before it in the current GOP

I frames allow no external macroblocks, in essence they are not much better than JPEG compression.

So a mixed GOP generally gives the best combination of size, decoding CPU use and compression. KVCD has an unruley B frame only GOP with a length of 48. You can see why that might improve compression getting those pesky I and P frames out of the way it places an undue burden on the decompression engine of most DVD players. When you have bendwidth to spare it can be a great idea to shorten your GOP to get a less compressed result, but a more "accurate" since encoding erors can build up in a GOP.

Quality and size also depend alot on the encoder too. TMPGenc seems to do a much better job at B frames than the other encodres. CCE's overall result is outstanding despite being locked into a max B frame length of 2 and a max GOP of ~21 ( only 15 in the GUI ).

[DJRumpy]

Snow, any idea how many B frames can safely be added to a group, without exceeding most players capabilities to render due to increase in overhead?

[A.C.E.]

B frames allow the most compression since it allows macroblocks to be re-used from almost anywhere in the current GOP

Actually, B-frames refer only to their neighbors, but the prediction is bidirectional (unlike P-frames which can refer only to the prior I or P). Consider the imaginary GOP structure:

I1 B1 B2 P1 B3 B4, I2 B5 B6 P2 B7 B8, . . .

B1 = I1, B2
B2 = B1, P1
B3 = P1, B4
B4 = B3, I2

This illustrates an "open" structure in which B4 is allowed to use a frame in the next GOP as a prediction reference. Had this been a "closed" GOP, B4 would act like a virtual P.

any idea how many B frames can safely be added to a group, without exceeding most players capabilities to render due to increase in overhead?

Really it's the encoder that bears the cost, as it needs to hold everything between each pair of I-frames in order to construct the Ps and Bs necessary to complete each GOP.

From the decoder's point of view, I-frames are the only "real" frames it has to deal with; Ps and Bs are more like blueprints that tell the decoder how to shift blocks of memory around in order to construct a new picture out of an old one. If the GOP length is limited it's to make sure fresh I-frames come along regularly enough to prevent decoding errors from propagating indefinitely rather than for reasons of speed or memory.

[kwag]

...any idea how many B frames can safely be added to a group, without exceeding most players capabilities to render due to increase in overhead?

2 is optimal. 3 gives smaller file size ( using VBR ). Above 3, there's no use.

-kwag

[vitualis]

@ kwag: I don't think that was what DJRumpy was asking.

@ ACE:

Really it's the encoder that bears the cost, as it needs to hold everything between each pair of I-frames in order to construct the Ps and Bs necessary to complete each GOP.

Actually, it is very important for the decoder as well. Stand-alone players aren't PCs with a vertiable excess of memory. They have very limited amounts of memory to do what only what they have to do. Since B frames a bidirectional, the decoder will have had to decoded all of that data and to hold it to reconstruct the correct frame sequence. This may overload the buffer of some players if you have many more B frames or much longer GOPs than what the player expects ("expects" as per standard DVD, VCD and SVCD).

Regards.

[A.C.E.]

Since B frames a bidirectional, the decoder will have had to decoded all of that data and to hold it to reconstruct the correct frame sequence.

This is correct with respect to an MPEG encoder (B-frames are constructed out of sequence and need to be held until the entire GOP is written) but with respect to an MPEG decoder, it's not.

An MPEG decoder only needs to store two pictures at any one time: the most recently decoded I-frame and the P or B frame that modifies it. According to ISO/IEC 13818-2, 2 MB of memory is enough to decode MPEG-2 MP@ML (720x480, 4:2:0) as well as provide VBV buffer space, a bitmap overlay plane (subtitles), display output buffering, and the rest[1].

This may overload the buffer of some players if you have many more B frames or much longer GOPs than what the player expects.

Not at all. The decoder only works with one frame at a time, two if prediction is used, so a GOP could be of infinite length and the decoder wouldn't know the difference. An authoring system like DVD or SVCD might impose a limit on GOP length, but MPEG-2 does not.
-------------
[1] Wai-Man Lam and Ligang Lu, "Memory reduction for HDTV decoders," IBM Journal of Research and Development, July 1999.

[snowmoon]

But can't B frames also come out of order? So the decoder may still have to decode more than just 3 frames since it really has to decode the stream until it finds the next frame to display.

2mb is a pittance of memory since each frame of 720x480@4:2:0 contains 675k of display data so 2mb would hold 3 frames of output and that does not even cound for overhead. This is fine for standard streams, but for non-standard it's pushing it would you not agree?

That was my understanding. I shoudl re-read those papges again.

[A.C.E.]

2mb is a pittance of memory since each frame of 720x480@4:2:0 contains 675k of display data so 2mb would hold 3 frames of output and that does not even cound for overhead. This is fine for standard streams, but for non-standard it's pushing it would you not agree?

In compressed format a CCIR-601 I-frame occupies 345K, a P-frame 34K and a B-frame 5.1K on the average, so you could fit a 675K display buffer, an I-frame, a P-frame and two B-frames into barely more than one meg of RAM.

All decodes are made to the display buffer so the encoder never has to deal with more than one uncompressed frame at a time. If you wanted to exhaust the decoder's memory with a perverse GOP you'd have to figure out how to queue up more than 200 pending Bs, which is probably impossible.

[crahak]

Oh my gawd, is this ever a long thread. There are both good and bad points to CBR/VBR. I personnaly like multipass VBR better, but there are many factors that come in play anyways, and many arguments. It takes time, but do your own tests on some shorter scenes with different settings and see for yourself what you like... Or read lenghty threads with people fighting :P (They want to help, and that is nice, still) Anyways, good luck

[kwag]

@ kwag: I don't think that was what DJRumpy was asking.

If DJRumpy was refering to B's between I an P frames, then my answer was correct. If he was refering to total number of B's per GOP, then my answer was wrong. So IBBP is better than IBBBP as far as quality, but not compression wise. And IBBB(insert more B's here)P is useless.
Maybe that's more clear.

Regards,
-kwag

[DJRumpy]

It's amazing how many different discussions have gone on under this thread....

Kwag, I was referring to the total number.

Ace: Does this mean a decoder acts much like a film projector, projecting (encoding/decoding) the current frame at hand (plus or minus the frames adjacent to the current frame of course).

If you step through the GOP, the key frame is decoded, and the next frame is a B frame, the decoder holds both the key frame, the current frame (B Frame), and the next frame in memory only? I always assumed it worked between keyframes, holding the entire GOP until the next keyframe was accessed.

[A.C.E.]

Does this mean a decoder acts much like a film projector, projecting (encoding/decoding) the current frame at hand (plus or minus the frames adjacent to the current frame of course)

That's a good analogy. A film projector. Read frame, decode frame, display frame, repeat. Motion estimation is the process used to determine what each P and B frame should contain, but by the time the decoder sees them they've been reduced to little more than "fixup lists" with respect to the current contents of the display buffer -- move block X three pixels left and one pixel up, overlay this partial block to cover the "hole" left by that block's movement, replace block Y with this new one, etc.

I always assumed it worked between keyframes, holding the entire GOP until the next keyframe was accessed.

To the extent that B-frames can occur out-of-sequence with respect to the next I or P it's logical that you'd buffer one or two of them to restore the display order, i.e.

I P B B --> I P B B
1 4 2 3 --> 1 2 3 4

but the decoding would still be frame-centric and sequential as opposed to the entire subgroup at a time.

A B-frame can have at most two dependencies, one past and one future, referring only to intra-coded blocks in the next or previous frame and never to other (nested) past or future references. At the instant a B requires a past reference that frame will already be sitting in the display buffer, and a forward reference would be fetched from the next (compressed) frame and decoded in-place as if it were a part of the current frame. When the next frame becomes the current frame only its forward references need resolved from the next compressed frame, and so forth. The decoder thus maintains an orderly, linear decode sequence without regard to GOP structure (in fact, GOPs are purely optional in MPEG-2).

[vhelp]

Just to add a little humar into the thread. . . he, he...

I am not afraid to admit that I don't understand a guDAMN thing about those
Ps and Bs and Is and GOPs you'al R talking about! ...wish I did, but for
the moment, it escapes me.

But, if ONLY, I knew/understood what you'all R talking about, I'd would love
to creat some kind of MPEG-2 encoder, if only to so for example, CVD or something
in that nature. Nothing full-fledge, just something you can drag your AVI's
into, and click a few settings.
I've ben looking for support in the Delphi programing language, but haven't
found anything yet course, I would make it FREEWARE!!

Anyways, just wanted to vent out (humarously) my great sence of imagination,
he, he...

I got GOPS, you got GOPS. . .

-vhelp

[medievil]

Back to the original discussion. Here is something to ponder:
If CBR was Really Better than VBR, Why Are ALL Commercial DVD's Encoded as VBR? Surely not to save space.
All My own dvd's are VBR with a Min 0, Max 9800mbs and the average always tends to hover in the 1.5-2mbs range.
Whats it all boil down too? CBR is a waste. Why anyone would use CBR is beyond me. even CCE's one pass VBR produces more efficiant results. :P

[vitualis]

I believe that the original question was on whether VBR could be better than CBR if the max. bitrate of VBR was the same as CBR...

I think that it has been argued fairly convincingly, yes, though the improvements are probably minor, if not irrelevant in this specific scenario.

Regards.

[A.C.E.]

The original question was whether VBR was better than CBR at SVCD bitrates. In my opinion* the answer is no.

MPEG at low bitrates is prone to several different kinds of artifacts. The most common of these, in order of annoyance, are mosquitos (little dots that appear within an 8-pixel radius of sharp, contrasty edges), aliasing (a jagged appearance along the edge of diagonal lines), contouring (random off-color squares in areas of regular tone) and the dreaded macroblock (clipping distortion that occurs whenever the peak bitrate exceeds the maximum bitrate).

All of these artifacts are related to the degree of intra-block compression required to achieve the target bitrate. DCT is lossless by itself, so the intra-blocks are scaled according to a quantization matrix designed to discard information at frequencies our eyes aren't likely to notice. But the tighter the compression, the more dramatic the scaling, the less accurately the block will be reconstructed by inverse DCT until it reaches the point of no return (i.e. the entire intra-block is set to the average value of its pixels).

The only way to prevent these artifacts is to have a maximum bitrate above the transparency bitrate for the frame format you're coding for. MPEG-2 is transparent at CCIR-601 frame sizes above 10 Mbps, so we can estimate the critical bitrate for other frame sizes proportionally:

Generic MPEG-2, independent of authoring scheme
(bitrates equivalent for PAL/50 and NTSC/60)   
-------------------------------------------------
                       Nominal       Yield (mins)
Frame	   NTSC	     Transparency  ------------
Format	  Resolution  Bitrate (1)   DVD-R  CD-R
---------  ----------  ------------  -----  -----
1/4-D1	   352 x 240     2.4 Mbps     320    49
1/2-D1	   352 x 480     4.9 Mbps     160    24
2/3-D1	   480 x 480     6.7 Mbps     118    18
SQUARE D1   640 x 480     8.9 Mbps      88    13
D1	       704 x 480     9.8 Mbps      80    12
CCIR-601    720 x 480    10.0 Mbps      78    12
----------
(1) Video stream only, not inclusive of audio

MPEG can't distinguish between signal and noise, so the dirtier the source the higher the bitrate required to maintain a constant level of quality. Provided the peak bitrate remains below the maximum we'll never see a macroblock even if other kinds of artifacts are present, but once the picture starts to break down no amount of bit-cadging, GOP tweaking, Q customization or multipass encoding is going to make up the difference.

The bitrate for SVCD is so constrained that all VBR can buy you is more recording time at approximately the same quality. If 2.5 Mbps isn't enough to reproduce the picture without artifacting, it's not going to look any better at a lower average bitrate. It might even look slightly worse considering all the scenes will be scaled to fit the bitrate rather than only those that actually need it.

By the same token, CBR above the transparency bitrate is a waste of space. Beyond a certain point the program isn't going to look any better, it's just going to occupy more storage -- which defeats the purpose of compressing it in the first place.

If the program is short enough to fit on a CDR at the SVCD maximum bitrate, the only way you're going to improve upon that is to increase the bitrate or reduce the data rate. Nothing else is going to squeeze enough bits out of the picture to make an appreciable difference.

* Just my $0.02, offered for what it's worth.

[regain]

I believe that the original question was on whether VBR could be better than CBR if the max. bitrate of VBR was the same as CBR...

I think that it has been argued fairly convincingly, yes, though the improvements are probably minor, if not irrelevant in this specific scenario.

No, not convincing, at least not for me because I believe my own eyes and I have done several encodes with these two settings and comparing them when max bitrate of VBR = CBR the VBR encodes never surpass CBR in image quality, at best equivalent and at times somewhat worse. Yes, I use tmpgenc and as always in my encoding practice (VCD, SVCD, DVD at whatever bitrates - low, high, superbit etc) I always turn on "motion search precision" (MSP) to highest quality setting. Some may argue that MSP at highest setting will negate the advantage of VBR, but I say this actually prove the point that "VBR could never be better than CBR if its max bitrate = CBR" provided your setting is right - e.g have MSP at highest quality in Tmpgenc.

The original question was whether VBR was better than CBR at SVCD bitrates. In my opinion* the answer is no.

MPEG at low bitrates is prone to several different kinds of artifacts...
-snipped of an excellent informative insightful article-

Now I am convinced by what A.C.E says.

[vitualis]

The original question was:

If my VBR encoding has a maximum bitrate setting of 2520, and my CBR setting is also 2520, I can't see how VBR can be better, since with CBR you're giving it the maximum bitrate all the time.

I don't think that the stuffed you posted is necessarily relevant A.C.E. Furthermore, there is more to the quality of a MPEG encoding than just bitrate.

@ regain: I have always stated throughout this entire thread that the difference in quality in the above scenario will be minor, probably completely unnoticeable. I have also always stated throughout this entire thread that if you are in the situation of doing the above, to simply encode in CBR.

However, with all other things being equal, a multipass VBR encoding of the same max. and average bitrate (essentially, multipass CBR) WILL theoretically yield better quality.

It has been explained at least half a dozen times in this thread why this is so by a number of different people. I suggest you read the IBM paper that was linked to previously for more details on how it is definitely so in the particular scenario of fades.

@ all: please read the ENTIRE thread!

Regards.

[Mocha]

If I want to convert a DIVX to mpeg2 svcd file, and the movie is a non-action film(people mostly standing around talking) What type of settings should I use? If VBR 2 pass...what type of min,avg,max settings should I use? Is highest quality motion search precision overkill, or will normal suffice? Is motion estimate search(fast) the same as low quality(fast)?

If I setup TMGENc to CBR ,highest quality motion search precision, a 582MB Divx file would take 32 hours to decode!!!!! IF motion search precision( I will call this MSP from now on) is set to motion estimate search(fast) the conversion would take 7 hours.

[vitualis]

@ Mocha: your question doesn't really have anything to do with the discussion of the thread. Try starting a new thread.

Regards.

[Oracle]

My vote is for CBR under the conditions of this thread

Quote the first post

If my VBR encoding has a maximum bitrate setting of 2520, and my CBR setting is also 2520, I can't see how VBR can be better, since with CBR you're giving it the maximum bitrate all the time.

VBR will never be better under these conditions.

+my 2 cents

[vitualis]

How about actually reading the entire thread?

Before the discussion in this thread and the linking to a number of relevant articles (e.g., the IBM paper), I would have agreed with you. But it seems obvious once you think about it harder and actually read the literature, the in the specific situation above, VBR could theoretically do better.

Two short summaries of my points:
http://www.vcdhelp.com/forum/viewtopic.php?p=346959#346959
http://www.vcdhelp.com/forum/viewtopic.php?p=347124#347124

The actual IBM article was linked curtesy of DJRumpy I believe.

Regards.

[Oracle]

read the thread.

read the IBM Article.

plus.

quoting directly from the link

The general conclusion is that the second-pass VBR sequences visually appear to have a higher overall quality than the ones coded with CBR. For VBR to visually outperform CBR, a mix of "easy" scenes and "difficult" scenes is always required. If all scenes were the same (easy or difficult), the VBR results would be equal to those for CBR. The principle of VBR relies on taking bits from easy scenes and spending them on the difficult ones instead. In visual evaluations by different viewers, it was found that the visual quality of an entire video sequence is judged by the minimum quality across the whole sequence. This minimum quality is usually found in the easiest scenes, as coding artifacts are the most noticeable there. A good VBR performance is thus founded on removing bits safely from the easier scenes (i.e., without noticeably distorting their quality). These bits are then redistributed over the more difficult scenes, such that the entire video is perceived to have a constant quality.

Check the highlighted bits

and remembering that in this case

If my VBR encoding has a maximum bitrate setting of 2520, and my CBR setting is also 2520, I can't see how VBR can be better, since with CBR you're giving it the maximum bitrate all the time.

An Example a DVD rip
Assuming we are encoding SVCD 480x576 PAL

480x576x25 =6912000 Pixels a second

as a comparsion DVD-
720x576x25 =10368000 Pixels a second.

say the DVD was averaging 6mbit/s

6912000/10368000 x100= 66% so we need 66% of the bitrate of the DVD to achive the same bitrate per pixel !

66% of 6Mbit/s =3.96Mbit/sec this nowhere near 2520!
even if the DVD average was 5mbit this would be around 3.3Mbit!


Taking infos directly from the IBM link

A good VBR performance is thus founded on removing bits safely from the easier scenes (i.e., without noticeably distorting their quality).

Now if you dont have any redundant bitrate as in this case how can VBR remove bits safely from easier scenes without noticably distorting the quality, especially when MAX & AV are the same.

[DJRumpy]

Your forgetting the original question. MIN/AVG/MAX is all 2520, so no frames would be shorted for bits. This is where the motion detection comes into play. Multipass VBR offers better motion detection than CBR. All things being equal (Bitrate in this case), VBR would produce better quality.

[A.C.E.]

read the thread.
read the IBM Article.

I read the thread. I read the paper. This is what I think:

All things being equal, if you have a bandwidth of 2.5 Mbps available to you, there's no reason you can't code 3-pass VBR at 2500/2500/2500 and get the prediction performace of multi-pass encoding along with the more gentle compression ratio of CBR. In fact, it would probably be very difficult to tell the difference between the two because the only bits the encoder could discard would be the ones related to complex motion (such as the oft-repeated fade) that don't amount to very much by themselves.

quoting directly from the link

The principle of VBR relies on taking bits from easy scenes and spending them on the difficult ones instead... A good VBR performance is thus founded on removing bits safely from the easier scenes (i.e., without noticeably distorting their quality). These bits are then redistributed over the more difficult scenes, such that the entire video is perceived to have a constant quality.

In order for a VBR encoder to maintain an average bitrate, every bit it spends on a difficult scene has to be taken away from an easy scene, right? Otherwise it's no different than CBR.

But if the transparency bitrate for some sequence is 3.35 Mbps and the encoder can't exceed 2.5 Mbps, once it reaches that bitrate it has to throw the rest of what it takes from the simple scenes away -- no matter how badly the difficult scenes need them -- because if it didn't, it would exceed the maximum bitrate by a wide margin.

In visual evaluations by different viewers, it was found that the visual quality of an entire video sequence is judged by the minimum quality across the whole sequence.

The bottom line is that VBR or CBR, single-pass or multi-pass, if the maximum bitrate is 2.5 Mbps and a particular scene requires 3.5 Mbps to reproduce, you're going to get some nasty macroblocks even if those fades look fabulous.

[DJRumpy]

The bottom line is that VBR or CBR, single-pass or multi-pass, if the maximum bitrate is 2.5 Mbps and a particular scene requires 3.5 Mbps to reproduce, you're going to get some nasty macroblocks even if those fades look

Your not stating anything new. In this case, both would look like crap

[A.C.E.]

DJRumpy: Riiight. That's the inevitable, inescapable, irrefutable point.

In order for VBR to kick CBR's ass you need a maximum bitrate above the transparency bitrate for the frame format you're coding to: If 1/2-D1 is transparent at 5 Mbps, a VBR recording at 1250/2500/5000 will look far superior to a CBR at 2500 even though they have the same average bitrate. But if the maximum bitrate is 2500, VBR at 2500/2500/2500 will look no better that CBR at 2500, and VBR at 625/1250/2500 will look substantially worse.

The SVCD bitrate is so limited that you just can't do better than CBR in any visually perceptible way. VBR will make the low-motion scenes look as good as they can get, but the high-motion scenes will still suffer artifacting proportional to the deficit in bitrate. And if "the visual quality of an entire video sequence is judged by the minimum quality across the whole sequence," once that picture starts to show contours or macroblocks the VBR vs. CBR debate is over. Both lose.

And if the discussion then becomes about how VBR loses only slighty less than CBR because, macroblocks aside, the scene transitions theoretically look better... I'll leave that discussion alone.

[DJRumpy]

I vote we shoot this thread in the head, and put it out of our misery...

:P

[snowmoon]

The SVCD bitrate is so limited that you just can't do better than CBR in any visually perceptible way. VBR will make the low-motion scenes look as good as they can get, but the high-motion scenes will still suffer artifacting proportional to the deficit in bitrate. And if "the visual quality of an entire video sequence is judged by the minimum quality across the whole sequence," once that picture starts to show contours or macroblocks the VBR vs. CBR debate is over. Both lose.

ACE: I Agree with most of your other statements, but this one I'll have to disagree with. Using CCE one-pass VBR mode produces exceptional results compared to an equally sized CBR encode. I'm talking in the 2100-2300kbps range for an average. Often times one pass vbr will even beat multi-pass ( don't ask me why, probably becuase the avg bitrate is lower than the "transparncy" point ).

Good discussion though, I'm even learning new things.