Minimum bitrate question...

[DD51]

After reading a thread made about changing the minbitrate with DVD-RB I decided to test this out.
Here's what it looks like:

-----------------This is with min bitrate 500
[14:09:49] Phase I, PREPARATION started.
- CCE SP 2.70.2.4 encoder selected.
- "Movie Only" mode is enabled.
- VTS_01: 2,285,487 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 196,160 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 97.6%
- Overall Bitrate : 5,062/4,049Kbs
- Space for Video : 4,044,200KB
- HIGH/LOW/TYPICAL Bitrates: 5,770/3,006/4,049 Kbs
[14:12:02] Phase I, PREPARATION completed in 3 minutes.

-----------------This is with min bitrate 0
[14:13:03] Phase I, PREPARATION started.
- CCE SP 2.70.2.4 encoder selected.
- "Movie Only" mode is enabled.
- VTS_01: 2,285,487 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 196,160 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 97.6%
- Overall Bitrate : 5,062/4,049Kbs
- Space for Video : 4,044,200KB
- HIGH/LOW/TYPICAL Bitrates: 5,770/3,006/4,049 Kbs
[14:15:18] Phase I, PREPARATION completed in 2 minutes.

Well as you can see the bitrate are EXACTLY the same.
My question is why?
I thought the final results would be different.

Can someone explain why that is?
Sorry that I just don't get it :helpful:

Thanks in advance

[hallway]

You could speculate the at no point in the movie does the bitrate dip below 500Kb/s. Or maybe I'm interpreting this wrong... Nowhere in the movie does the bitrate go low enough that going below 500Kb/s is necessary. Is that more accurate (to the real gurus) ??

[DD51]

Just tried another movie to see...here are the results

----------------- min bitrate 0
[15:15:26] Phase I, PREPARATION started.
- CCE SP 2.70.2.4 encoder selected.
- "Movie Only" mode is enabled.
- VTS_01: 3,034,783 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 267,000 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 71.2%
- Overall Bitrate : 3,623/2,898Kbs
- Space for Video : 3,939,782KB
- HIGH/LOW/TYPICAL Bitrates: 3,124/1,669/2,898 Kbs
[15:18:16] Phase I, PREPARATION completed in 3 minutes.
-----------------min bitrate 500
[15:19:16] Phase I, PREPARATION started.
- CCE SP 2.70.2.4 encoder selected.
- "Movie Only" mode is enabled.
- VTS_01: 3,034,783 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 267,000 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 71.2%
- Overall Bitrate : 3,623/2,898Kbs
- Space for Video : 3,939,782KB
- HIGH/LOW/TYPICAL Bitrates: 3,124/1,669/2,898 Kbs
[15:22:19] Phase I, PREPARATION completed in 3 minutes.

Maybe you're right that it never hit below 500...ah well :stupid:

[jdobbs]

The minimum bitrate would not affect the HIGH/LOW/TYPICAL bitrates. Those are all "average" bitrates (for different segments). Changing the minimum bitrate would only change the distribution of the available bits. In other words if you lowered the minimum, and there was a section that needed less... the extra bits saved would be used for a higher demand area -- but the average would still remain the same.

[DD51]

Thanks for the explanation...I appreciate that you took the time to explain it....thanks

[apfraats]

Not only that, I have tested MIN_BITRATE=0 and saw a TOTAL CHANGE in BITRATE distribution that is especially usefyull at lower averages.

The MIN_BITRATE is an encoder paramter.

At 500 you tell the encoder not to go below 500 bits/sec.

At 0 you tell the encoder to use the ENTIRE ROOM from 0 to MAX_BITRATE that is set (with RB-OPT) or calculated by DVD-RB.

The graphic such as shown with bitrate-viewer changes OVERALL.

Because there is a room of 500 bit/sec to ADD to overall BITRATE DISTRIBUTION.

This means the graph looks different in all places, not only in the lower ranges.

I have tried and studied this with difficult DVD's having low averages say about 3000-3500 and it greatly improves results.

For example at the same point the encoder does not use 2800 Kb/s3ec, but just 2600 KB/ssec with MIN_BITRATE=0, and so MORE BITRATE is availbale for the demanding parts.

Especially using agressive VBR (bias=0), this can be the difference between annoying blocking and no blocking at all.

At higher average bitrates the impact is less, but I decided to give the encoder maximum room for making it's own decisions (CCE) and use a MIN_BITRATE of 0.

It simply yields better results, and does have more benifits as using 999 passes for CCE !

Be aware that some encoders even don't honor a MINIMUM bitrate setting !!!
CCE however does honner it.

As some people complain about BLOCKING of CCE, try using MIN_BITRATE=0 and see the difference.

Use BITRATEVIEWER as a comparision tool on output off CCE when using MIN_BITRATE=0 and USING MIN_BITRATE=500.
You'll see different graphs, clearly showing different bitrate distributions of the encoder.

To be short: A MINBITRATE=0 not only infuences the BITRATE at 500 or less, but influences the total bitrate distribution in GENERAL !


Espsecially usefull for lower average bitrate to begin with, as I stated.

[DD51]

Especially using agressive VBR (bias=0), this can be the difference between annoying blocking and no blocking at all.

So should I be lowering my VBR Bias??
Right now it's set at the default:
VBR Bias: 26
Qual Prec: 16
VBR Passes: 2

Thanks for any comments

[apfraats]

There is much very much discussion about this.

As I think FULL VBR at especially LOW AVERAGE BITRATE is the best, I recommend a VBR_BIAS of 0.

I never have seen a less demanding scene suffer by this setting.

If it was really too agressive you would notice it in the less demanding secnes.

But always the more demanding scenes are blocking or have troubles.

Some people are complaining about CCE'
s tendency for blocking.

Well I solved it just using TWO IMPORTANT SETTINGS, ESPECIALLY AT LOWER AVERAGE BITRATES:

1) vbr_bias=0 , resulting in maximum adaptation of bitrate.
2) MIN_BITRATE=0 , resulting in a better bitrate distribution.

CCE is very very good in bitrate adaptions. HC is much less. HC tends to have a respond time between the high demanding scnene and bitrate adjustment, which really messes things up.

CCE is much more precise, looking to what's comming next and adjusting bitrate at the precise correct moment.

So a FULL VBR setting is justified for CCE.

[DD51]

many thanks for your feedbacks...I guess I have some testing to do.

thanks again.

[Mr. Monte]

Has anyone else did what apfraats did and seen better results?...I did notice Jdodds lowered the minimuim in the latest relase from 500 to 300..but why not set it to 0 then?

[magic144]

apparently in the past, some standalone players had a problem with CCE's output if the min bitrate was set too low - as I understand it, jdobbs started distributing RB with a default min of 500 to prevent such a problem, but I don't know how widespread this issue was

[SpazzHH]

apparently in the past, some standalone players had a problem with CCE's output if the min bitrate was set too low - as I understand it, jdobbs started distributing RB with a default min of 500 to prevent such a problem, but I don't know how widespread this issue was

Actually, the 500 min bitrate was instituted when CCE 2.70 was first released because alot of people had problems with it crashing all the time on certain sources(HBO white noise for one). Most standalone players won't have a problem with a low minimum bitrate, but if you decide to go below the new default, you should probably test out a disc on your player, just to be safe. Going below 300 could possibly cause a problem on some players. As a software author, I'm sure jdobbs feels that it's better to be safe than sorry.

[Mr. Monte]

As a software author, I'm sure jdobbs feels that it's better to be safe than sorry.

I'm sure he feels that way

[magic144]

ahh yes, SpazzHH is right - sorry for the misinformation about standalones

not myself today, have had to return to work and have therefore got a nasty headache :-)
(and no immediate access to the program's changelog which would have told me this)

I will try not to propagate such fables in the future! I knew jdobbs was doing something to err on the side of caution tho - as would I with a product of such widespread popularity :-)

[Boulder]

A low vbr bias value may cause blocking in dark scenes, because the lower the bias value is, the more bits are stolen from them.

[Boulder]

HC tends to have a respond time between the high demanding scnene and bitrate adjustment, which really messes things up.

Would you care to tell us in what movie and at what approximate position? If this is true, I'm sure hank315 would like to know it so he could do something about it.

[apfraats]

I just noticed it in fast moving pictures. If a fast moving scenes comes up and goes down very fast , so a short action scene, the first few images (press puase and pic. forwards step by step) blocks a bit, and then the blocking goes away. It's a bit like the bitrate for picture X depends too much on that for X-5 for example. So picture X-5 gets blockking and X get's too much bitrate, as if there is some kind of latency involved.

And in complex scenes with short and strong switching of bitrate you sunddenly see a blocking on picture to picture changes.

It's like the total graph such as shown in bitrateviewer should be shifted to left or right in some little degree. I tend to believe that HC is some pictures behind the truth picture it should compress, but it can be the other way around.

I know that CCE implements a kind of 'look ahead' mechanism to predict correct bitrates needed. It looks that HC adapts it's bitrate a little too late, or maybe even too early.

I have seen action scenes were the last pictures were ok, and then a new sequence of fast moving picture begins and the first few were blocky.

I don't exactly know what is related to what, because it's pretty complex and to be honest I don't know a .... about encoding internally.

But the complete orchestra doens't play the same tune, for sure.

Some instruments are a few 'cycles' behind or in front of others.

To be more precise I would have to do in depth testing with special sample clips I don't have and which costs a llllllooooootttttttsssss of time.

I sure see other behaviour than while using CCE. With CCE , if blocking occurs, it's always in the most demanding picture changes. You clearly see this when looking picture by picture (frame by frame). HC blocks at other moments in the sequence were you just won't expect it. CCE's blocking is straightforward. There were the changes from frame to frame are the biggest, the blocking occurs the first if in lack of bitrate.

So it looks that HC has some shifted bitrate distribution (x-axis) comparing to CCE.

It's however difficult to tell, because the encoders have total different charisteristics.

Do a movie with CCE and one with HC, and you'll see two different graphs with other Q's (bitrate viewer) and shape of graph.

I you wanne try to see what I notice, try a movie with a complex scene of more and less difference in pictures following each other and compress them pretty heavy (50% or more) and compare both samples.

In some way, CCE's blocking seems to go hand in hand with picture to picture differences (not having a scene change detection, so an inserted I-frame), and HC tends to be not synchronous in blocking compared to picture to picture changes.

At too low bitrates everything blocks, because it's not posiible to represent changes from picture to picture anymore preventing macro-blocking, there simply isn't enough 'mathematical power' for the lower bitrate to represents changes within a macroblock screenwide, so the macroblock becomes visible as an entity of it's own.

I'm not saying HC is such a bad encoder, I just noticed it, as a point for improvement.

Then however the question is how honest is it to compare a multi-developer , multi-year development process to a relatively short term single developer process ????

I deeply respect HANK's job on the HC encoder, cause I'm not able to build it myself in the next few years. I even don't wanna try...... Already have a headache just thinking about it.... :D

[apfraats]

A low vbr bias value may cause blocking in dark scenes, because the lower the bias value is, the more bits are stolen from them.

Never had this issue.

It also can't be so, while VBR_BIAS just changes DYNAMIC BEHAVIOUR of bitrate_allocation, and NOT the average bitrate in any way.....


So imagine a complete dark scene that lasts for the whole movie.

The average bitrate will be equal for VBR_BIAS=0 and VBR_BIAS=MAX

Only if CCE 'undershoots' when lowering bitrate this can be a real problem.

I have NEVER seen this happening although.

But I'll try to especially look for HEAVY AKTION, HIGH MOTION SCENES, directly followed by a dark low bitrate low motion scene.

the VBR_BIAS would only affect the moment at which the change from high motion, high aktion scenes stops and are folowed by dark low bitrate scenes. If the encoders has an undershoot by lowering bitrate very fast then this copuld be a problem.

I will watch out for these especially, but untill now I have NEVER seen this problem in practise with CCE.

Then there is a FADE ON STATIC SCENE OPTION, that's currently not availbale in the front end of DVD-RB. This option CAN improve fades on static scenes, so you have not to mistake a fade on a static scene with the example I mentioned above, as CCE has a special, although currently not used, setting for this in particulair as it comes to problems.

[Boulder]

I didn't say that the average bitrate changes. With a low bias, the dark scenes will get less bits and the more active ones get more. With a higher bias, the bitrate difference between them is less, thus the dark scenes will have some more bits allocated in them.

[Curmudgeon76]

Apfraats,

I'm using RB Pro 1.04 and CCE SP 2.7 and in my CCE settings I only have settings for Quality Precision, VBR Bias (which I changed to zero) and Number of VBR Passes. Where in the program is the setting that lets you specify a minimum bitrate?

[manono]

It's in the Options section of the Rebuilder.ini file, Curmudgeon76.
I didn't say that the average bitrate changes. With a low bias, the dark scenes will get less bits and the more active ones get more. With a higher bias, the bitrate difference between them is less, thus the dark scenes will have some more bits allocated in them.
Yeah Boulder, I suspect you're right about that. However, the downside may be that static or dark scenes may sometimes get more bits than they might actually need, and complex scenes may block up more quickly as they'll be bitrate starved sometimes. Of course, it could be argued that the eye can't tell when complex scenes don't look so good, and it's only we anal encoders that go around pausing movies and advancing frame by frame to check the quality.

I'm one of those that uses a zero bias. You may remember an earlier thread where I mentioned seeing heavy blocking in Saving Private Ryan during an extended scene at night by candlelight where you'd see a head surrounded by black. I fixed it by raising the minimum bitrate, and I'm pretty sure (although I didn't test) that your method would have fixed it also, although probably by raising the bias above 25 (or whatever the default is). But the price might well have been that the famous beach invasion scene and the tank fight near the end would have looked much worse. I'm not sure what the moral of the story is, except that you sometimes have to adjust the settings to fit the material.

[rendez2k]

Apfraats,

I'm using RB Pro 1.04 and CCE SP 2.7 and in my CCE settings I only have settings for Quality Precision, VBR Bias (which I changed to zero) and Number of VBR Passes. Where in the program is the setting that lets you specify a minimum bitrate?

In rebuilder.ini (in the DVDRB install folder), add MIN_BITRATE=0

[Boulder]

I'm not sure what the moral of the story is, except that you sometimes have to adjust the settings to fit the material.
That's probably one reason why you can adjust the local bitrates in CCE after the vaf file has been created. It would also have been a solution for the SPR problem.

[Curmudgeon76]

Thanks for the info guys, checked the Rebuilder.ini file and added "min_bitrate=0" under the options section.

Is there any way to actually tell in RB if the new minimum bitrate setting is being applied? I looked in the status log window and it shows the high/low/average bitrates but it doesnt specify if the min is 500, 300, 0, etc.

[jdobbs]

You could look at the ECL file. Look for the vbr_brate_min parameter. But -- if you have it set in REBUILDER.INI, it's set. Oh, ye of little faith.

[apfraats]

At first I used RB-OPT for this AFTER the PREPARE fase.

But JDOBBS pointed out to me it will also do to set

MIN_BITRATE=0

in the REBUILDER.INI file.

Watch out, reusing older project files, as I did myself, because they overwrite the entire REBUILDER.INI file !!!

So if you want to be 'smart' as I tried, and use already defined project files, you lose this setting again.....

So define youre project files manually from scratch AFTER adding the line MIN_BITRATE=0 to REBUILDER.INI.

Then DEFAULT a MINIMUM BITRATE of 0 is passed to the encoder.

The actual output bitrate will (untill I see otherwise) NOT reach zero, but youre overall bitrate distribution increases greatly especially at low averages.

That 500 minimum is taken into account for basic mathematics done by the encoder and also infuences bitrates at other parts of the stream that even don't come near this minimum. That 500 minimum so steals bitrate unnecessary.

Although JDOBBS stated has got reports of problems with LOW bitrates, I never have experienced them in practise, using 5 different DVD-players.

I think besides encoder versions with bugs there should not be any issues with a minimum bitrate at 0, using 2.70.2.4.

Other encoders, such as HC can't even have a minimum bitrate setting, so they are probably 0 by default.

Therefore many people complain about CCE's blocking, but in fact that's not the encoder problem but a parameter setting problem most og the time.

I have notices much improvement by using a MIN_BITRATE of 0.

Some people state out problems in dark scenes, but I never saw these.

All blocking seen was already in the original DVD in these scenes.

If you examine every commercial DVD you'll see a significant number of DVD's already have bad or less quality parts, looking FRAME BY FRAME......

But CCE was generally acussed of blocking, no wonder if you use 500 bits/sec minimum setting.

I have a DVD encoded with 172 bits/sec parts and it plays wothout problem.