RB-Opt v0.23 BETA a tool to change titles bitrate, CCE parameters and AVS scripts.

[jdobbs]

@robot1

Thanks for your continued work.

I'd keep the INI file as the user wanted it. I'd say matrix selection for HC would be a very useful feature, but since jdobbs is considering adding "intermediate" matrices (see here (http://forum.doom9.org/showthread.php?p=1058876#post1058876)), it might be less of a "requirement". Though for tweakers on the cell level, I suspect that it will still appeal greatly.

RegardsI've added the additional matrix selections (now it has HIGH, MED HIGH, MED, LOW, and VERY LOW) and they will be in the next release.

[blutach]

@jdobbs - thank you :)

I am in the same boat as Sharc: right now I often need to run a preliminary Prepare Phase, just to find out what matrices to use in the "real" Prepare Phase. What he requested would save me some time (~20 minutes... my CPU is slow.)Why not use a bitrate calculator to get into the ball park to begin with? I use Videocalc (http://www.videohelp.com/tools/VideoCalc).

Regards

[robot1]

I am in the same boat as Sharc: right now I often need to run a preliminary Prepare Phase, just to find out what matrices to use in the "real" Prepare Phase. What he requested would save me some time (~20 minutes... my CPU is slow.)
As I stated above, you don't need to run the prepare phase again if you use HC. Simply change the matrices selection in DVD-RB: it will use the new ones.
If you use CCE or AQE, you have to change the matrices in RB-Opt.

[kumi]

@blutach: thanks for the Videocalc recommendation.

@robot1: d'oh, sorry... sometimes it's hard to keep track of where DVD-RB stores all it's settings.

[robot1]

Download here (http://www.savefile.com/files/1159994)

Changelog:
- Fixed a bug with HC redistribution.
- Better control of values in Q prediction phase, as suggested by Boulder.
- New HC settings window, to tweak some of the HC parameters. Notice: the matrices selected in RB-Opt will be used for Q prediction and redistribution. DVD-RB will use the matrices selected in its menu.
- Added a new hidden value, to set the lower average bitrates:
with the default
min_bitrate=0
RB-Opt uses:
850 for HC
900 for ProCoder
1150 for CCE
The value 900 for ProCoder is the lowest accepted by the program.
The other are the lowest accettables, in many test (thanks to Sharc for testing).
If you want to override this behaviour, insert a custom min_bitrate value.
The minimum bitrate is set *after* saving and displaying the redistribution log, if you want to check, you can find the actual value in the tweak cell dialog.

[~bT~]

^ Ty Ty Ty!

[blutach]

Thanks robot1

Regards

[kumi]

Fabulous, thanks.

[robot1]

For a stupid mistake introduced while coding, the matrix selection in HC settings wasn't updated at all.
In previous versions, if you changed a matrix in CCE settings, in some circustamcies, the selection wasn't taken in account for redistribution (the program used the matrices selected in Rebuilder.ecl - you had to save before redistribution).

Download (http://www.savefile.com/files/1169343)

[HKT3020_1]

Probably a stupid question but is it possible to have an updated step by step guide with images.
I'm sure there are a few others like me who seem intimidated by working with a new program alongside DVD-RB. :rolleyes:

[rendez2k]

Probably a stupid question but is it possible to have an updated step by step guide with images.
I'm sure there are a few others like me who seem intimidated by working with a new program alongside DVD-RB. :rolleyes:

I'd like this too. Probably a stupid question but can't you now edit reduction %'s in the new segment viewer? What extra features am I missing by not using RB-Opt?

[mikenadia]

Trying to understand optimal Q, I noticed this.
I am going to redistribute bitrate between two VOB_ID (one significant cell each) but with very different individual optimal Q.
ID-1. optimal Q:50 original bitrate:1854 ; nb frames:3524
ID-2. optimal Q:82 original bitrate:1185 ; nb frames:6571
Optimal Q for the combination based on 100% opv_sample_size (computed by RB-opt):71.
I assume that is the optimum.
Then both VOB are encoded, new sizes are computed and new bitrates are assigned on a pro-rata basis (no loss of bits).
ID-1.encoded bitrate (Q=71):1310 reassigned birate:1352 (1310*1.032)
ID-2.encoded bitrate (Q=71):1409 reassigned birate:1454 (1409*1.032)
The reassignement factor (no loss of bits) is bigger than 1,therefore that the actual optimum Q is less than 71.
If we compute back the individual optimal Q with the new assigned bitrates, they should be equal or close.They are not because of the pro-rata basis reassignement.
May be a reassignement based on empirical data, I do not know...
The actual optimum Q (trial and error) is between 68 and 69.
ID-1. encoded bitrate (Q=69):1346 reassigned birate:1354
ID-2. encoded bitrate (Q=69):1445 reassigned birate:1453
I agree that it is not a big difference but room for thought.
The same issue exists (if it is an issue) if you reassign one VOB-ID after bitrate distribution (because it is also done on a pro-rata basis).:)

[robot1]

Probably a stupid question but is it possible to have an updated step by step guide with images.
I'm sure there are a few others like me who seem intimidated by working with a new program alongside DVD-RB. :rolleyes:
My english is not so good to write a comprehensible step by step guide. If there is a volunteer, I could help.

[robot1]

Trying to understand optimal Q, I noticed this.
I am going to redistribute bitrate between two VOB_ID (one significant cell each) but with very different individual optimal Q.
ID-1. optimal Q:50 original bitrate:1854 ; nb frames:3524
ID-2. optimal Q:82 original bitrate:1185 ; nb frames:6571
Optimal Q for the combination based on 100% opv_sample_size (computed by RB-opt):71.
I assume that is the optimum.
Then both VOB are encoded, new sizes are computed and new bitrates are assigned on a pro-rata basis (no loss of bits).
ID-1.encoded bitrate (Q=71):1310 reassigned birate:1352 (1310*1.032)
ID-2.encoded bitrate (Q=71):1409 reassigned birate:1454 (1409*1.032)
The reassignement factor (no loss of bits) is bigger than 1,therefore that the actual optimum Q is less than 71.
If we compute back the individual optimal Q with the new assigned bitrates, they should be equal or close.They are not because of the pro-rata basis reassignement.
May be a reassignement based on empirical data, I do not know...
The actual optimum Q (trial and error) is between 68 and 69.
ID-1. encoded bitrate (Q=69):1346 reassigned birate:1354
ID-2. encoded bitrate (Q=69):1445 reassigned birate:1453
I agree that it is not a big difference but room for thought.
The same issue exists (if it is an issue) if you reassign one VOB-ID after bitrate distribution (because it is also done on a pro-rata basis).:)
In the first step, as you have very different Q factors between the two VobID's, RB-Opt has done an estimate of the Optimal Q (on a linear basis). Obviously it cannot be exact - as Q relation with bitrate is not linear, and it has calculated the bitrate as 1352 and 1454.
For your trial and errors you have found the effective optimal Q as 68 or 69, and the optimal bitrates as 1354 and 1453.
As RB-Opt was wrong for only 1 or 2 kbps, I think the guesstimate was excellent.

[mikenadia]

You are right. Thanks for your program.:)

[mikenadia]

Robot1, we agree that the reassigned bitrate distribution is not too sensitive to optimal Q.
Therefore, may be it is possible to speed up the process when you redistribute bitrate among different VOB-ID (specially Extras).
If I am doing it for 10 VOB_ID , it computes optimal Q for each VOB_ID, going through reiterations (till the size is within 1%).For small VOB-ID, it may involve 6 iterations for each VOB_ID .
May be,compute size for each VOB_ID, use your algorithm to compute aggregate Q (and its corresponding size), and then go through a second iteration.That may require only 3 iterations (beacause the aggregate file is larger).
I know that I can keep the 1% for main movie and 5% for Extras, but my strategy is to compute optimal Q for all the VOB_ID (Main Movie and Extras with Half_D1,therefore not transferring unecessary bitrate to Extras).:)
End of discussion for me.
P.S. In Extras, I have the Main Movie in 4:3 split in 25 significant VOB-ID.

[robot1]

Therefore, may be it is possible to speed up the process when you redistribute bitrate among different VOB-ID (specially Extras).
If I am doing it for 10 VOB_ID , it computes optimal Q for each VOB_ID, ...
If different VobIds are in the same VTS, you can already speedup the process.
In the main dialog window, use the "Vob-Id link" option to join all the VobIDs. In this way RB-Opt will act as if there is just one larger VobID, and perform a single redistribution process.
If VobIDs are in different VTS it's impossible to have a single process.

[mikenadia]

I tried that before (and tried it now) but I could not make it work.
I am using DVD Rebuilder 98.2 (may be that's why?).
I am trying to link VTS1-VOB_ID1 (with only one cell inside) and VTS1-VOB_ID3 (with only one cell inside) .Same VTS.
I tried to select at the same time VTS1-VOB_ID1 and VTS1-VOB_ID3 using the CTRL or Shift Key but I am not lucky.
I select in the list VTS1-VOB_ID1 ,click on the "VOB-ID Link" button and I have the follwing warning :"This VOB-ID can't be linked .It is the only VOB_ID of the set.

Thanks for your help and patience.Newbie at work.:)

[robot1]

I am trying to link VTS1-VOB_ID1 (with only one cell inside) and VTS1-VOB_ID3 (with only one cell inside) .Same VTS.

Try unchecking the "Hide Vob-Ids of insignificant size". You should find also the VobID n.2, and link all in the VTS.

[ercofra]

I've found a bug with CCE SP2 and OPV, with 4:3 PAL movies:
the .m2v file created by RB-Opt 0.36 during OPV prediction has a black bar at the bottom; I've found that the problem is in the .ecl file created by RB-Opt, it's missing these settings:
ve_src_roi.x=0
ve_src_roi.y=0
ve_src_roi.w=720
ve_src_roi.h=576
ve_dst_roi.x=0
ve_dst_roi.y=0
ve_dst_roi.w=720
ve_dst_roi.h=576


These settings specifies the "region of interest" coordinates of input and output files; without them, CCE SP2 assumes a frame size of 720x480, and the original frame of 720x576 (for PAL) is cutted at the bottom.
You can check this by manual loading in CCE SP2 the ECL file created by RB-Opt during OPV prediction, go to "Encoder setting - Area setting... - Input/Output file", and look at the "region of interest" coordinates, they are 0x0, 720x480; after manual adding the above settings, try to load again the ECL file, now the "region of interest" coordinates are correct (0x0, 720x576); manual encoding with the fixed ECL produces a correct .m2v file with full frame size.
The consequence of this bug, is that the Q factor is always under estimated and the resulting DVD is oversized (5 GB!), because the REBUILDER.ECL has the correct settings, and the final .m2v is encoded correctly, but with a bad predicted Q.
Thanks for your great program.

[robot1]

I've found a bug with CCE SP2 and OPV, with 4:3 PAL movies
Thank you for your detailed bug report. I will try to solve tomorrow, or in the next few days.

[mikenadia]

=== Running prediction on VTS 2 - VobID 2
*** Warning: sample selected too small
*** Using 26.71% sample size.

--- Initial Q: 107
--- Pass 1. Testinq Q factor: 107
--- Desired sample size: 21172 KB
--- Waiting for encoder...
--- Obtained sample size: 1420 KB (-93.3% error)
--- Pass 2. Testinq Q factor: 1
--- Desired sample size: 21229 KB
--- Waiting for encoder...
--- Obtained sample size: 1420 KB (-93.3% error)
--- No change in Q for next iteration
*** Using Q factor 1

[robot1]

As you can see in your log, the encoded size of the segment with both q=107 and q=1 is 1420KB (expected size is 21.172KB).
As you can have q lower than 1, RB-Opt uses q=1.
Anyway I think you should check your input, as in normal conditions it's impossible to have the same output with q=107 and q=1.

[mikenadia]

Thanks;). Bad rip. Only black frames (284 Mg !) in that VOB. I should have checked.
P.S. I found that bad rip ,thanks to you , and because I was looking at the temporary log of optimal Q computation.It may be useful to have in the final log the optimal Q for each VOB and the aggregate one.Thanks again.

[robot1]

Here is the new build:
RB-Opt v 0.37 (http://www.savefile.com/files/1341148)

Changelog:
Bugfix: fixed wrong OPV prediction for CCE SP2 and Pal 4/3 movies, as reported by ercofra.

Added more info in the redist.txt file after redistribution (with actual bitrates stored).

Added a new parameter in the .ini file: redist_BIAS (values: 0 - default redistribution; 100 - no redistribution)
The "redistribution_bias" parameter limits the min_cell_bitrate for example to 55% of the DVD-RB standard value, and the max_cell_bitrate to 1/55% = 182%
More examples
bias min_cell_bitrate max_cell_bitrate
0 0 (infinite) i.e. full redistribution
50 50% 200%
60 60% 167%
75 75% 133%
100 100% 100% ie same as DVD-RB "original" means no redistribution.

Probably a BIAS between 50 and 65 would be a good choice.

Anyway, with RB-Opt you can always tweak the redistribuited bitrates, without losing the benefit of redistribution for other cells (I often tweak the end credits cells after redistribution)

[blutach]

Thanks robot1.

Regards

[Fishman0919]

Thank You robot1

[gurkan]

Hello. I've managed to create another one of these (http://forum.doom9.org/showthread.php?p=1011198#post1011198). Is there a way of not using q 1 as base for redistribution estimation in second pass?
Maybe using 2 or 3? The source is fullscreen and interlaced pal, so I'm pretty sure the end result is gonna be quite a high q.

[robot1]

What is the q value found in the first pass?

[gurkan]

=== Running prediction on VTS 1 - VobID 1
--- Initial Q: 39
--- Pass 1. Testinq Q factor: 39
--- Desired sample size: 3800602 KB
--- Waiting for encoder...
--- Obtained sample size: -371475 KB (-109.8% error)
--- Pass 2. Testinq Q factor: 1
--- Desired sample size: 3804214 KB
--- Waiting for encoder...

[robot1]

If in the first pass it finds 39, it's impossible to go down to 1.
I think the problem lies in CCE or in the source. Even if RB-Opt would not allow q=1 (and why, if it's a possible value? ... it's another problem of CCE), I don't think you would get a right final q.

[gurkan]

Ok. Thanks for the info and a great app. Added second pass info to my post if it's of any interest.
By the way, you don't think it could be because I used 100% sample? I'm going to try a smaller value and see if it makes any difference.

added:
Yep. This is what I get on the second pass with 25% sample. Looks like an improvement.

=== Running prediction on VTS 1 - VobID 1
--- Initial Q: 39
--- Pass 1. Testinq Q factor: 39
--- Desired sample size: 968990 KB
--- Waiting for encoder...
--- Obtained sample size: 991390 KB (2.3% error)
--- Pass 2. Testinq Q factor: 40
--- Desired sample size: 968966 KB
--- Waiting for encoder...

[Boulder]

Looks like CCE crashes in the example where it jumps from Q39 to Q1.

[gurkan]

@ Boulder

CCE does complete the first pass and no error message was seen before the one of the second pass. Maybe I should have a look at the filesize and see if it's playable. I'll try it when I get home from work.

[Boulder]

CCE simply exits during the encode and doesn't give any warnings or error messages. The problem has been discussed in this thread earlier.

[gurkan]

@ Boulder

Sorry, must have missed it.

[mikenadia]

I think I had related issues with HC.
http://dvd-rb.dvd2go.org/modules.php?name=Forums&file=viewtopic&t=1365

http://dvd-rb.dvd2go.org/modules.php?name=Forums&file=viewtopic&t=1363

Thx for the new version.

[~bT~]

Thanx!

[robot1]

=== Running prediction on VTS 1 - VobID 1
--- Initial Q: 39
--- Pass 1. Testinq Q factor: 39
--- Desired sample size: 3800602 KB
--- Waiting for encoder...
--- Obtained sample size: -371475 KB (-109.8% error)
--- Pass 2. Testinq Q factor: 1
--- Desired sample size: 3804214 KB
--- Waiting for encoder...
I missed your second pass info.
The result you find (negative) is very strange.

Ok. Thanks for the info and a great app. Added second pass info to my post if it's of any interest.
By the way, you don't think it could be because I used 100% sample? I'm going to try a smaller value and see if it makes any difference.

Are you using 100% sample in REDISTRIBUTION or in Q PREDICTION?
Q Prediction is a multi-pass algorithm to find the Q value which gives, with only 1 effective pass, a final size similiar to a multipass encoding. Having a 100% sample is a nonsense, as you would have at least two full pass - you have no benefit and could perform a multipass encoding.
In Q Prediction the sample should be not over 3-4%, to have sense.
Regards

[gurkan]

Thank you. I was not aware of this. I was doing a 100% sample q prediction.

[ercofra]

Here is the new build:
RB-Opt v 0.37 (http://www.savefile.com/files/1341148)


This download link don't work for me, I've tried several times, but with no luck..

Alternative links?

Thanks

[jdobbs]

Interesting. I just clicked on it in your post and it worked for me.

I just loaded it on my site. Try this link. (www.jdobbs.net/Freeware/RB-Optv0.37.zip)

[ercofra]

Interesting. I just clicked on it in your post and it worked for me.


Still don't work for me, Internet Explorer refuses to connect to the site, I don't know why..

Try this link. (www.jdobbs.net/Freeware/RB-Optv0.37.zip)

Your link is OK, thanks jdobbs!

[robot1]

Interesting. I just clicked on it in your post and it worked for me.

I just loaded it on my site. Try this link. (www.jdobbs.net/Freeware/RB-Optv0.37.zip)

Thank you.
I've updated the first post with your link.

[Rippraff]

By the way, you'll always find the latest version in the link at the bottom of the first post in this thread.

Even if you're not a german speaking person, I'm pretty sure you'll find the attachment. ;)

Cu Rippraff

[mikenadia]

Sometimes, in the same VTS, I have some VOB non interlaced, others interlaced.
Can I link them and if yes, on what criteria, should I use "ConvertToYV12()" or "ConvertToYV12(interlaced=true)" in the linked VOB-ID.
Thx

[robot1]

You should not link interlaced and non interlaced VobID's

[ercofra]

I've tried a backup with OPV and CCE SP2 and I've found there's still a little bug but I don't know if it affects prediction; in the ecl file created during prediction there's a little mistake in this line:

ve_dst_roi.h=720 (correct is 576 for PAL and 480 for NTSC)

This specifies the destination height for the "region of interest", 576 for PAL, and 480 for NTSC (720 is the width).

[Boulder]

robot1,

could you make Rb-Opt 100% compatible with the current HC release? It requires the *PROGRESSIVE statement in the ini file if the source is flagged as progressive. Otherwise it'll use the hybrid mode which is not optimal for progressive sources.

[robot1]

robot1,

could you make Rb-Opt 100% compatible with the current HC release? It requires the *PROGRESSIVE statement in the ini file if the source is flagged as progressive. Otherwise it'll use the hybrid mode which is not optimal for progressive sources.
Yes, I will do soon.
Should I also use the nosmp switch if multiple encoding is selected?