RB v1.26 bitrate redistribution

[archaeo]

@jdobbs:
Just wondering how the Base_Q is determined in the new feature... Is it done by using an OPV prediction pass with a given sample size, or a set value?

I just ran a quick test and ticked the enable bitrate redistribution, and RB came up with a Base_Q = 31. Not knowing where this value came from, I ran the same project through RB-Opt with 'calculate optimal Q' chosen, and the Q it gave me was 48.

Is the Base_Q set at a particular value in RB?


thanks

[jdobbs]

I used a routine I had already set up in OPV prediction. It generates an initial Q value based upon the desired output size and frame count. It wouldn't be exact (of course -- that takes a few passes) but gets you close enough to be within a reasonable distance of the output Q so you're getting a reliable bitrate distribution profile. Originally my plan was to use a fixed value, but I decided this would be better based upon Sharc's notes in this thread (http://forum.doom9.org/showthread.php?t=122351&page=10).

The Base_Q will change with each disc.

By the way. Currently the redistribution is applied only against the main feature. I have it set up, though, so I can have it applied against extras as well (if I decide that's a good path to take).

[Sharc]

@jdobbs:
Am I correct in assuming that the matrix specified as "Main Feature Matrix" is used for the determination of the Base_Q value?
As mentioned before, the Q depends largely on the matrix for a fix target size.

[archaeo]

OK thanks. So it is calculated... and as long as the calculated Base_Q is in the 'ballpark', the distribution profile won't be markedly different from one done using an exact Q prediction pass routine.


I used a routine I had already set up in OPV prediction. It generates an initial Q value based upon the desired output size and frame count.

And I assume that this routine also take into account the custom matrix that is selected in the advanced options?

By the way. Currently the redistribution is applied only against the main feature...

Good to know :) I could see the value to having it as an option to apply to extras as well.

[Sharc]

Oh I think I misunderstood.
The Base_Q in DVD-RB 1.26.0 is a rough estimate which does not yet consider the actual matrix. Correct?

[Sharc]

Here a comparison between DVD-RB 1.26.0 and RB-Opt for redistribution.

Matrix used is FHE, same as the original DVD.

RB-Opt calculated a Q factor of 58, corresponding to a DVD-5 target, for redistribution.
DVD-RB calculated a Base_Q of 31 for redistribution.

Sample size is 25% in both cases.

The results are similar, but as expected the Q=58 produced a somewhat higher swing, because at Q=31 the redistribution is not yet in the "saturated" range for the FHE matrix. Still, I don't think that one would notice a difference when watching the movie.

If I had used a lower bitrate matrix like CCE default, I would expect that the results would be very much the same for DVD-RB and RB-Opt, because at Q=31 the redistribution is typically in the "saturated" range, for the CCE default matrix.

("Saturated" means that changes in Q have little impact on the redistribution profile.)

P.S.: Could someone approve my former attachements in the RB-Opt thread and Redistribution thread?

[jdobbs]

Not sure what movie you're using, but I'd have to guess 31 would be closer to the actual Q factor needed. Run an OPV prediction and see what the end Q is calculated to be. I wouldn't think that you'd actually want to get into the "saturation" range... you want to stay where the encoder is using it's best judgement for the source being encoded.

[Sharc]

I will do this, and just noticed a minor issue: I can select both "Enable Redistribution" and "One pass VBR" at the same time in the RB menu. They should be exclusive, I believe.

[Sharc]

Here the results for OPV:

Movie is The Departed/PAL, Matrix is FHE.

DVD-RB: Q final = 60 (31, 52, 60), 4400 frames sample size (2%)
RB-Opt: Q final = 58 (from earlier tests), 2200 frames sample size (1%)

High bitrate matrices will generally end up in very high Q values.

[jdobbs]

I will do this, and just noticed a minor issue: I can select both "Enable Redistribution" and "One pass VBR" at the same time in the RB menu. They should be exclusive, I believe.They are... if you select OPV the Redistribution is ignored. I guess I should disable it.

[jdobbs]

Here the results for OPV:

Movie is The Departed/PAL, Matrix is FHE.

DVD-RB: Q final = 60 (31, 52, 60), 4400 frames sample size (2%)
RB-Opt: Q final = 58 (from earlier tests), 2200 frames sample size (1%)

High bitrate matrices will generally end up in very high Q values.
What happens if you use a standard matrix? That sure seems to be a high Q factor for something with a bitrate averaging in the mid 3000's...

Maybe I missed something earlier in the thread, but why would you want to use a matrix designed for a high bitrate when you are in this range?

[Sharc]

What happens if you use a standard matrix? That sure seems to be a high Q factor for something with a bitrate averaging in the mid 3000's...

Maybe I missed something earlier in the thread, but why would you want to use a matrix designed for a high bitrate when you are in this range?

That's another story: I used the original matrix in order to demonstrate that the combination of the original matrix with a certain (typically low) Q will closely "reproduce" the profile and file size of the original disk. I reported this here:
http://forum.doom9.org/showthread.php?p=1012203#post1012203

Secondly, if you do a standard multipass VBR with CCEAQM=1 you will often see the matrix switching to 1/2 CCE default which is +/- similar to FHE.

[Fishman0919]

Secondly, if you do a standard multipass VBR with CCEAQM=1 you will often see the matrix switching to 1/2 CCE default which is +/- similar to FHE.

But that is per GOP when the encoder feels it's needed or thinks it will be beneficial to the encoding. A matrix like FHE is design for high bitrate (5000k and up), using it on a bitrate in that range will most likely not yeild result as good as the default or even the Standard MPEG2 matrix

[Sharc]

Yes, agree.

[Sharc]

ok, here the OPV results for CCE default matrix, same movie:

DVD-RB: Q final = 19 (31, 19, 18 => 19), 4400 frames sample size (2%)
RB-Opt: Q final = 17 (from earlier tests), 2200 frames sample size (1%)

... and, btw:
RB-Opt using Q=17 with CCE default matrix yields exactly the same distribution profile as with FHE and Q=58.

[Boulder]

But that is per GOP when the encoder feels it's needed or thinks it will be beneficial to the encoding. A matrix like FHE is design for high bitrate (5000k and up), using it on a bitrate in that range will most likely not yeild result as good as the default or even the Standard MPEG2 matrixRemember that you need to consider the compressibility of the source along with the available bitrate. You can't make any accurate judgments based on the bitrate alone.

[linx05]

I have the new DVD Rebuilder version with the Bitrate Distribution. Now here are the questions:

1) How do I know when to know the best possible time to use it?

2) Is it good to leave it enabled all the time (supposing all the bugs have been ironed out)?


EDIT: 3) Does it make a difference if the DVD is a movie or episodic disc?

EDIT: 4) What difference does it make to change the hidden setting "Redist_Percent=" ?

[gurkan]

@jdobbs
Does the redistribution take settings like "steal space from extras" and "half d1" in consideration before the q-value is predicted?

[jdobbs]

It couldn't take "Half Space for Extras" into account -- since that is a reallocation of the result (just like the original bitrate) and therefore would be a contradiction. But it would take "Half-D1" into account.

[jdobbs]

I have the new DVD Rebuilder version with the Bitrate Distribution. Now here are the questions:

1) How do I know when to know the best possible time to use it?

2) Is it good to leave it enabled all the time (supposing all the bugs have been ironed out)?


EDIT: 3) Does it make a difference if the DVD is a movie or episodic disc?

EDIT: 4) What difference does it make to change the hidden setting "Redist_Percent=" ?1. Let's wait and see what results are posted from the beta. But I've been doing all mine with it set so I can see how well it works.

2. If it turns out that it improves the picture in the reports -- it could be a good thing to leave on.

3. It shouldn't be used with an episodic disc because it currently only works on the largest VTS. But, I have a version I'm using for testing that has a flag that allows you to use it across all VTSs.

4. The larger the sample, the more accurate the distribution, and the longer it takes. But you'll probably find that it is very close anyway, even with the default 10%.

[linx05]

Thanks for the replies. I had a feeling it wasn't working for episodic discs.

EDIT: If I did a prepare phase, it did what it should do (along with distribution) and then went into the preview/edit tab and changed a few bitrates for the credits for example, would this have a negative effect on it?

I am still a little fuzzy on this after reading Boulders thread again.

[Boulder]

Currently the method does work on episodic discs if the different episodes are in the same VTS.

[jdobbs]

Thanks for the replies. I had a feeling it wasn't working for episodic discs.

EDIT: If I did a prepare phase, it did what it should do (along with distribution) and then went into the preview/edit tab and changed a few bitrates for the credits for example, would this have a negative effect on it?

I am still a little fuzzy on this after reading Boulders thread again.
If you use the preview/edit to change bitrates, you are overriding the decision made by redistribution.

[linx05]

It would be good to have it both ways. But such is life :)

[archaeo]

Well, I would like to report one test project with a sizing problem using the new beta feature... For this test I did a comparison in which I first ran a project through DVDRB's redistribution feature, and then ran the same project w/ the same parameters thru RB-Opt (v.29) redistribution using 'calculate optimal Q'. The result was that DVDRB's final project size came in at 4.20 Gb, and RB-Opt's redistribution final size came in at 4.34 Gb. All the initial parameters were set up the same for both projects. The main difference I saw was with the base_Q value - DVDRB calculated it at 23, and RB-Opt Q calculated it at 40 using 'calculate optimal Q' feature. I used a 10% sample size for RB-Opt. The disparity in base_Q results appears to be where the sizing difference is coming from.


For these I applied a custom matrix in both (4000+). I need to add that I ran the same project thru DVDRB using the standard matrix (thinking that saturation was a problem), and it was still undersized. I used one filter, undot(), and used 2 passes in CCE.


Here's DVDRB's log:
------------------------
[20:58:33] Phase I, PREPARATION started.
- DVD-RB v1.26.0
- AVISYNTH 2.5.6.0
- CCE 2.70.2.12 encoder selected.
- AVS Filters are enabled.
- "Adaptive Quantizer Matrices" is enabled.
- "Movie Only" mode is enabled.
- Source: LAST_KING_OF_SCOTLAND
- VTS_01: 2,659,504 sectors.
-- Scanning and writing .D2V & .AVS files
-- Processed 176,993 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 85.8%
- Overall Bitrate : 5,368/4,295Kbs
- Space for Video : 3,870,030KB
- Redistributing using Base_Q: 23
- HIGH/LOW/TYPICAL Bitrates: 5,877/1,178/4,295 Kbs
[21:06:22] Phase I, PREPARATION completed in 8 minutes.
[21:08:21] Phase II ENCODING started
- Creating M2V for VTS_01 segment 0
- Creating M2V for VTS_01 segment 1
- Creating M2V for VTS_01 segment 2
- Creating M2V for VTS_01 segment 3
- Extracting Video for VTS_01 segment 4
- Extracting Video for VTS_01 segment 5
- Extracting Video for VTS_01 segment 6
- Extracting Video for VTS_01 segment 7
- Creating M2V for VTS_01 segment 8
- Creating M2V for VTS_01 segment 9
- Extracting Video for VTS_01 segment 10
- Extracting Video for VTS_01 segment 11
- Extracting Video for VTS_01 segment 12
- Creating M2V for VTS_01 segment 13
- Creating M2V for VTS_01 segment 14
- Creating M2V for VTS_01 segment 15
- Extracting Video for VTS_01 segment 16
- Extracting Video for VTS_01 segment 17
- Extracting Video for VTS_01 segment 18
- Creating M2V for VTS_01 segment 19
- Extracting Video for VTS_01 segment 20
- Creating M2V for VTS_01 segment 21
- Creating M2V for VTS_01 segment 22
- Creating M2V for VTS_01 segment 23
- Extracting Video for VTS_01 segment 24
- Creating M2V for VTS_01 segment 25
- Creating M2V for VTS_01 segment 26
- Creating M2V for VTS_01 segment 27
- Creating M2V for VTS_01 segment 28
- Creating M2V for VTS_01 segment 29
- Creating M2V for VTS_01 segment 30
- Creating M2V for VTS_01 segment 31
- Creating M2V for VTS_01 segment 32
- Creating M2V for VTS_01 segment 33
- Creating M2V for VTS_01 segment 34
- Creating M2V for VTS_01 segment 35
- Creating M2V for VTS_01 segment 36
- Creating M2V for VTS_01 segment 37
- Extracting Video for VTS_01 segment 38
- Extracting Video for VTS_01 segment 39
- Extracting Video for VTS_01 segment 40
- Creating M2V for VTS_01 segment 41
- Creating M2V for VTS_01 segment 42
- Extracting STILLS for VTS_01 segment 43
[21:44:26] Phase II ENCODING completed in 36 minutes.
[21:44:26] Phase III, REBUILD started.
- Processing VTS_01
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Rebuilding seg 1 VOBID 1 CELLID 2
- Rebuilding seg 2 VOBID 1 CELLID 3
- Rebuilding seg 3 VOBID 1 CELLID 4
- Rebuilding seg 4 VOBID 1 CELLID 5
- Rebuilding seg 5 VOBID 1 CELLID 6
- Rebuilding seg 6 VOBID 1 CELLID 7
- Rebuilding seg 7 VOBID 1 CELLID 8
- Rebuilding seg 8 VOBID 1 CELLID 9
- Rebuilding seg 9 VOBID 1 CELLID 10
- Rebuilding seg 10 VOBID 1 CELLID 11
- Rebuilding seg 11 VOBID 1 CELLID 12
- Rebuilding seg 12 VOBID 1 CELLID 13
- Rebuilding seg 13 VOBID 1 CELLID 14
- Rebuilding seg 14 VOBID 1 CELLID 15
- Rebuilding seg 15 VOBID 1 CELLID 16
- Rebuilding seg 16 VOBID 1 CELLID 17
- Rebuilding seg 17 VOBID 1 CELLID 18
- Rebuilding seg 18 VOBID 1 CELLID 19
- Rebuilding seg 19 VOBID 1 CELLID 20
- Rebuilding seg 20 VOBID 1 CELLID 21
- Rebuilding seg 21 VOBID 1 CELLID 22
- Rebuilding seg 22 VOBID 1 CELLID 23
- Rebuilding seg 23 VOBID 1 CELLID 24
- Rebuilding seg 24 VOBID 1 CELLID 25
- Rebuilding seg 25 VOBID 1 CELLID 26
- Rebuilding seg 26 VOBID 1 CELLID 27
- Rebuilding seg 27 VOBID 1 CELLID 28
- Rebuilding seg 28 VOBID 1 CELLID 29
- Rebuilding seg 29 VOBID 1 CELLID 30
- Rebuilding seg 30 VOBID 1 CELLID 31
- Rebuilding seg 31 VOBID 1 CELLID 32
- Updating NAVPACKS for VOBID_01
- Rebuilding seg 32 VOBID 2 CELLID 1
- Rebuilding seg 33 VOBID 2 CELLID 2
- Rebuilding seg 34 VOBID 2 CELLID 3
- Rebuilding seg 35 VOBID 2 CELLID 4
- Rebuilding seg 36 VOBID 2 CELLID 5
- Rebuilding seg 37 VOBID 2 CELLID 6
- Rebuilding seg 38 VOBID 2 CELLID 7
- Rebuilding seg 39 VOBID 2 CELLID 8
- Rebuilding seg 40 VOBID 2 CELLID 9
- Rebuilding seg 41 VOBID 2 CELLID 10
- Rebuilding seg 42 VOBID 2 CELLID 11
- Updating NAVPACKS for VOBID_02
- Rebuilding seg 43 VOBID 3 CELLID 1
- Updating NAVPACKS for VOBID_03
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
- Correcting VTS Sectors...
[21:52:11] Phase III, REBUILD completed in 8 minutes.

Done.
_______________________

[jdobbs]

The difference in Q couldn't have any affect at all. The total amount of space stays the same (within a few sectors) between a regular encode and a reallocated encode... it just gets distributed differently. The Q value isn't used in the encode, only in determining how to spread the available sectors.

So that just indicates that the encoder is not reaching the specified bitrate in the encode.

[archaeo]

Oh yes, you're right, it's only used in the bitrate distribution calculation... I'm wondering why then, when using the same parameters for each project, RB-Opt's redistribution process allows it to come in right on the money? In other words, what difference in RB-Opt's redistribution process would allow the encoder to reach the specified bitrate?

[Sharc]

The only explanation I would have is that RB-Opt produced a significantly higher swing (by it's higher Q) than DVD-RB. See my previous posts and graphs in this thread.
Hence the encoder may run less into a saturation with RB-Opt's redistribution profile.

Edit:
I just noticed that you have CCEAQM enabled. In my experience this can produce sizing problems when used with 2 passes only. I always use 3 passes with CCEAQM=1.
Why RB-Opt hit the target size better may -- as said before -- be related to the higher swing which also has an effect on when the matrix is modified by CCEAQM.

[Boulder]

Maybe the calculations are simply different? With RB-Opt's redistribution, I've always got a similar result to a regular DVD-RB encode.

[Sharc]

They are certainly different. This becomes most evident for high bitrate matrices when you get Q in the order of 30 with DVDRB as opposed to Q in the order of double that value (60) with RB-Opt.

I understand that DVDRB estimates the Base_Q based on number of frames etc., whereas RB-Opt makes the estimation of the Q by repeated trials using the actual matrix -- similar to the OPV process.
The DVD-RB method is faster though, however the RB-Opt method produces a Q-estimate which is closer to the one that corresponds to the target size.
DVD-RB and RB-Opt produce similar Q estimates for the standard matrix, however the Q estimate may differ significantly (by a factor of 2) for high bitrate matrices according to my experience.

[Sharc]

Here another example.
- The matrix of the original is FHE.
- Matrix for redistribution is CCE default.
- a) RB-Opt calculated Q =10
- b) DVD-RB calculated Base_Q = 24
- Redistribution sample size set to 25% in each case.

As expected, the higher Q (24) of DVD-RB introduced a higher swing, however the Q which corresponds to a DVD-5 is actually 10, i.e. same as would be used for OPV.

This example is one of the (rare?) cases where the redistributed bitrate exceeded the original bitrate for some of the cells.
I assume that DVD-RB would reset these peaks to the bitrate of the original which may finally be the reason for undersizing (?). In such case the undersizing would be higher for b) than for a).

Btw., the huge swing brings me back to the question if further (marginal) improvement would be possible by a final matrix reallocation, see
http://forum.doom9.org/showthread.php?p=1013444#post1013444

[jdobbs]

Just MHO, but I think we may be putting the cart before the horse.

Instead of comparing the two (DVD-RB and RB-Opt), I think it would be more beneficial to do tests that might help decide whether there is any real advantage to the redistribution on non-CBR/limited-VBR sources. Then if it looks like there is we can start optimizing.

As for CBR and limited-VBR sources I think it's already decided. So my concentration would probably be on examining the bitrate of the source (not the segments, but the picture level) and doing the redistribution automatically.

...peaks to the bitrate of the original which may finally be the reason for undersizingThat may be possible... I'll take a look at it. The allocated bitrate should never exceed the peak bitrate of the original. It won't in the encoding (because the max_bitrate will limit it) -- but I'll have to look and see if there is the possibility of bits being lost there. Probably not, because the peak is going to be significantly higher than the average (which you graph is displaying, except on CBR).

Also, looking at the way is distributed in your graphs -- I wouldn't think the difference in swing between the two distribution methods is really enough to be significant.

[jdobbs]

Oh yes, you're right, it's only used in the bitrate distribution calculation... I'm wondering why then, when using the same parameters for each project, RB-Opt's redistribution process allows it to come in right on the money? In other words, what difference in RB-Opt's redistribution process would allow the encoder to reach the specified bitrate?Are you using non-standard matrices in your encodes?

[jdobbs]

Btw., the huge swing brings me back to the question if further (marginal) improvement would be possible by a final matrix reallocation, see
http://forum.doom9.org/showthread.ph...44#post1013444I think Robot1 is right there. You have to run the redistribution pass on the matrix that was selected -- otherwise the Q wouldn't match the matrix and the redistribution might be incorrect to begin with. Something I didn't think of is that when DVD-RB does the Q check, it only uses the "Main Feature" matrix -- because it treats the encode like an OPV pass. But when the 2-pass encode is completed, it uses the specified matrices for encoding. That's why I asked archeao if he were using alternate matrices on the disc that undersized.

[Sharc]

I think Robot1 is right there. You have to run the redistribution pass on the matrix that was selected -- otherwise the Q wouldn't match the matrix and the redistribution might be incorrect to begin with.

No question here, agree.

The idea was rather if it would make sense to re-allocate the matrices based on the final redistributed profile, just before starting the subsequent multipass encoding phase.
I have done this manually in a test for a segment that got a really low bitrate allocated by the redistribution, and found that by re-allocating the "low bitrate matrix" manually the quality of the picture improved marginally (less macroblocking). Well, just an idea. May be I need to do more tests.

[jdobbs]

DVD-RB does select the matrix based upon the reallocated bitrate, because the ECL write is done after redistribution. So that much is ok. Except, of course, that the reallocated bitrate was determined without the matrix. That may be why encoder saturation could be more likely.

The problem is that at the point of redistribution, you don't know yet what the redistributed bitrate will be yet... so you can't use it to determine a matrix to use for the redistribution pass -- it's a "chicken before the egg" scenario. I'm wondering if it may be best to force the "Main Matrix" matrix across the board when a redistribution was done.

I have doubts as to whether the matrix originally selected by DVD-RB should be used in the redistribution with RB-Opt either, because there are some significant bitrate differences. I'm not sure if Robot1 changes it, but I don't think so.

[Sharc]

....But when the 2-pass encode is completed, it uses the specified matrices for encoding.

Does it use the matrices according to the redistrubuted bitrate? Means if before redistribution the cell bitrate is say 2700 and the redistribution pass would set it to 1900, would then the "very low bitrate" matrix be employed for the multipass encode?

Edit: We were just posting at the same time. Your last post clarified my qestion above. Thanks

[jdobbs]

Yes. But that bitrate (the 1900 in your example) was allocated based upon redistribution with a Q and a different matrix... that's the problem (whether you do it with RB-Opt or DVD-RB).

[Sharc]

Agree.

[robot1]

In the graph above, I think the value calculated by RB-opt is higher than the original bitrate. In this case, RB-Opt doesn't use it, but uses the original bitrate, and the saved bitrate is spreaded among the other cells (and I think DVD-RB acts in the same way). This behaviour can be changed in RB-Opt.ini, but I don't recommend to change it.

If there are different matrices in the segments, RB-Opt uses the matrix of the "average segment" for the prediction, and then uses the actual matrices of every segment for the redistribution pass.
Anyway, I'm convinced that if you want to use redistribution, you should use the same matrix for the whole movie.

("average segment" is the segment whose bitrate is more similar to the average bitrate of the movie)

[Boulder]

Instead of comparing the two (DVD-RB and RB-Opt), I think it would be more beneficial to do tests that might help decide whether there is any real advantage to the redistribution on non-CBR/limited-VBR sources. Then if it looks like there is we can start optimizing.One thing that comes to my mind immediately is that doing the redistribution will nullify any effects of a possible bias setting in the original encode. I think that the bias is one reason why the redistributed bitrate swings a lot compared to the original.

[jdobbs]

Good point. That's definitely possible.

[robot1]

Anyway with an average bitrate over 4.000 I don't think you will see any visual difference between a regular and a redistribuited encoding. Redistribution could be useful for lower encoding, I think.

[jdobbs]

Anyway, I'm convinced that if you want to use redistribution, you should use the same matrix for the whole movie. I agree. Otherwise you're very likely negating any advantage you might gain from the redistribution.

[archaeo]

Are you using non-standard matrices in your encodes?


Yes, I used the high (4000+) matrix to encode with, for 'main feature' , 'low', 'very low' and 'extras'.

[jdobbs]

That probably explains it then. I'm working on a fix for that.

[archaeo]

Anyway with an average bitrate over 4.000 I don't think you will see any visual difference between a regular and a redistribuited encoding. Redistribution could be useful for lower encoding, I think.

Yes, true in this case, as I wasn't able see a noticeable difference between these two. But in response to a question earlier in this thread by linx05 (where he asked if it was a good idea to leave it enabled 'all the time'), I thought I'd throw a non CBR hi bitrate source at it to see how it would work out in this case. Since sizing did become an issue with this particular sample, it seemed to help answer that question.

[robot1]

Probably I've done less tests than yours. From my tests, the redistribution has never damaged image quality (but sometimes it hasn't improved it).
I think an advanced user could leave always on the redistribution, looking at the results and tweaking the cells with bitrate spikes using the segment editor.
But, for a normal user, and a normal encoding (not CBR or limited VBR), the standard DVD-RB mode could be really fine, expecially if the average bitrate is over 3.500

[Sharc]

One thing that comes to my mind immediately is that doing the redistribution will nullify any effects of a possible bias setting in the original encode. I think that the bias is one reason why the redistributed bitrate swings a lot compared to the original.
I see the "nullification" of the bias as a clear advantage of redistribution. I imagine that if one has plenty of space -- like on a DVD-9 -- one might be tempted to increse the bias. More even so because the maximum bitrate is limited anyway by the mpeg/DVD standard or by encoder saturation. so why not simply boost the less demanding segments on a comfortable DVD-9.
The situation changes when one wants to reduce such a high-bias DVD-9 to a DVD-5. Then it becomes essential for which scenes to spend the high bitrates and where one can tolerate lower bitrates. Here comes the benefit of redistribution.

[Sharc]

In the graph above, I think the value calculated by RB-opt is higher than the original bitrate. In this case, RB-Opt doesn't use it, but uses the original bitrate, and the saved bitrate is spreaded among the other cells ....
This makes sense to me.

.....(and I think DVD-RB acts in the same way).....
Not sure. May be jdobbs will tell. I thought that DVD-RB will just ensure that the instantaneous bitrate will never exceed that of the original, but it won't touch the average cell bitrate.

Anyway, I'm convinced that if you want to use redistribution, you should use the same matrix for the whole movie.
Means you recommend to use one single matrix for initial Q-estimation, then for the redistribution pass itself and for the encoding?
I agree insofar as this will preserve the concept of "constant quality" best.