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

[Boulder]

I ran a test on Cold Feet, season 5, disc 1. After the redistribution, RB-Opt suggested new bitrates which were all negative. Here's the ecl file DVD-RB created: http://www.megaupload.com/?d=Y5Z23D3U

A suggestion to HC and QuEnc related parts: the ability to use more than one encoder as in DVD-RB. It will make redistribution faster by a fair bit.

I was able to reproduce the "clicking on the VOBID causes values to go all crazy". It happens after the redistribution pass has been done and the new values are accepted. Then I just clicked once on the VTS I had done the redistribution on and it happened.

[gurkan]

Tried RB-opt for the first time, the new distribution function being the main reason.
Must say that I thought it was terrific.
IMHO I think that BIG3 used to produce better results than DVD-RB when it came to dealing with CBR-sources. Nice to see that combined with RB-opt this is no longer true.:thanks:

BTW, DVD-rb complained about "item.m2v" during rebuild. I assumed this was a temp-file created for the opv, so I just deleted it and tried it again and it seemed to work.

[robot1]

BTW, DVD-rb complained about "item.m2v" during rebuild. I assumed this was a temp-file created for the opv, so I just deleted it and tried it again and it seemed to work.
Yes, you can delete the file. I've already fixed this little bug for next version.
Anyway, consider bitrate redist is in early beta stage.
Use it for a VobID (or a set of VobID linked in a VTS)without the "autosized" flag, and as last step before rebuilding. Opening the rebuilder.inf again in RB-Opt could cause problems. Next version will fix these bugs.

IMHO I think that BIG3 used to produce better results than DVD-RB when it came to dealing with CBR-sources. Nice to see that combined with RB-opt this is no longer true
We have to thank Boulder for the idea :)

[jdobbs]

IMHO I think that BIG3 used to produce better results than DVD-RB when it came to dealing with CBR-sources.Well, just MHO -- but I still think that if you have a CBR source the best you can do is a bitrate that is equal to the one used in CBR... otherwise you'd have to be getting the additional missing detail out of the cosmic ether. DVD-RB sets the max to the CBR rate because anything higher would probably only amplify the error (blockiness).

But, as I always say, too each his own.

[Boulder]

Well, just MHO -- but I still think that if you have a CBR source the best you can do is a bitrate that is equal to the one used in CBR... otherwise you'd have to be getting the additional missing detail out of the cosmic ether. DVD-RB sets the max to the CBR rate because anything higher would probably only amplify the error (blockiness).

But, as I always say, too each his own.As I wrote in that redistibution thread, the method tries to minimize the extra distortion caused by recompression. This is achieved by using an optimal bitrate curve instead of the one provided by the original encode.

There is a big difference between encoding at q3 and q5, be it recompression or encoding from a lossless source, and this is what may happen if the original, CBR-based distribution of bits is used. The method I suggested shifts the bits so that every cell is encoded at roughly the same quant.

@robot1: you need to edit your post a bit: as last step before rebuilding-->as last step before encoding:) I've never unchecked "autosized" before doing the redistribution, does it still change the avg bitrates or do the pass but leave them unaffected?

[jdobbs]

This is achieved by using an optimal bitrate curve instead of the one provided by the original encode. Ok. I get what you're saying. It's not the maximum bitrate -- but the distribution between segments that is the problem. What I don't understand is why using OPV alone wouldn't solve it, since it redistributes bits between segments based upon quality.

[Boulder]

OPV does solve the problem but it has its problems, unpredictability being one of them. Doing the redistribution pass has the best of both worlds, the constant quality from OPV and the accuracy from a multipass encode. Of course, the downside is the extra time it takes, but a modern CPU doesn't need that long to do the extra pass.

Also the option to include several VTSs/VOBIDs (coming up sometime, I assume) to the redistribution improves quality. There are series DVDs in which every episode is in its own VTS which are the same size regardless of the complexity of the content. The redistribution will fix this issue, OPV cannot do that.

[gurkan]

anything higher would probably only amplify the error

I guess this is the part I don't understand.
I know that this is a rather crippled analogy, but if you save a jpg-picture with
the same low quality-setting twice, the result would be inferior to saving it the
second time with a better quality-setting.
And if there is an excess of bits laying around in, let's say a slow out of
focus scene in one vob-id, then why not use it for a fast moving detailed scene in
another vob-id instead?

[FredThompson]

OPV window is showing up when the "Save Settings" button is pressed. It should not do this unless OPV is requested.

[robot1]

OPV window is showing up when the "Save Settings" button is pressed. It should not do this unless OPV is requested.
Could you check if there is a short segment encoded in OPV, even if the main segment is VBR ?
Could you send me the rebuilder.inf and the rebuilder.ecl (modified and original) - my email adress is in the readme.

[FredThompson]

Nothing was encoded. I did the preparation phase then tried to reduce the global total by 3M. I'll have to recreate this for you. Give me a day. It's after 5AM and I have been up all night. Time for some sleep.

[gurkan]

Pulled up the sample to 100% to increase accuracy. This managed to recreate the bug Boulder mentioned before.
during encode the reported bitrates look fine but when they're summarised in the final state they turn into negatives.

[robot1]

Pulled up the sample to 100% to increase accuracy. This managed to recreate the bug Boulder mentioned before.
during encode the reported bitrates look fine but when they're summarised in the final state they turn into negatives.Thank you for your report.
This bug is fixed for next release (I think I will release it tomorrow).
With 0.26 beta, please use at maximum a sample of 50%.

[gurkan]

Thanks for the quick updates.
BTW, since the opv is only used as an analyze-pass to get the right bitrates, does it really matter what I set as Q Factor?

[Boulder]

No, it doesn't matter. I recommend a value that doesn't make the bitrate bang the maximum constantly because it will distort the curve. I usually use Q30, sometimes Q40 if the material is high-motion and/or interlaced.

[jdobbs]

Not sure if I'm understanding completely... But if you're using CCE's OPV to do a first pass it definitely makes a difference if your are not close to the bitrate. Here's a quote from the CCE manual:

... a video information file should be
recreated when you made a substantial change in bitrate setting. The
change of bitrate setting may not cause an error, however a renewed
information file will bring the better results in limited number of encoding
passes. When an average bitrate is increased twice or more or
decreased less than half, it is better to recreate the video information
file.

[Boulder]

The vaf file isn't used in anything in the redistribution pass, the only function is to gather information to tweak the bitrate. The actual encoding happens normally.

[gurkan]

Would you consider Terminator 2 dir. cut PAL high motion? It´s one of my favourite reference-movies. Doing it right now on q30. I know it´s not cbr but it´s one of the movies that to my eyes looked better in big3´s hands. Thought that the optimal bitcurve on 8gb vs 4.37 would differ a bit. Plus that the raw-material changes after the first encode.

[robot1]

Anyway I think that using the right Q value (the one you would use for an opv disc) would give the maximum quality, as encoding is a non linear process.
If time doesn't matter, you could use a Q prediction before the redistribution step.
Anyway, if you want to use 100% sample, wait for next version, ore use this test build:
http://www.savefile.com/files/661393
I'd be glad to receive feedback about the quality you get.

[gurkan]

Cheers! Will try it out.

[gurkan]

Bitrates don't come back negative with the new build. =)

[jdobbs]

The vaf file isn't used in anything in the redistribution pass, the only function is to gather information to tweak the bitrate. The actual encoding happens normally.I guess I don't understand what you're doing then. So you don't perform the second part of a two part (OPV/VBR) encode?

[Fishman0919]

The vaf file isn't used in anything in the redistribution pass, the only function is to gather information to tweak the bitrate. The actual encoding happens normally.

Yes for that "Q" setting or bitrate...or something real close... if the bitrate is changed quite a bit. The .vaf from the OPV is pretty useless.

[Boulder]

I wrote a small FAQ which I will post in the redistribution thread. I think we should discuss the method there to keep this thread cleaner.

The thread is here : http://forum.doom9.org/showthread.php?p=992511

[Sharc]

Anyway I think that using the right Q value (the one you would use for an opv disc) would give the maximum quality, as encoding is a non linear process.
If time doesn't matter, you could use a Q prediction before the redistribution step.


That would suggest to include in RB-Opt as a first step a (say 1%, does not take much extra time) Q prediction automatically and to base the bitrate redistribution on that initial Q estimate rather than on some fix value.

[robot1]

Updated version:
RB-Opt v0.27 beta (http://www.savefile.com/files/673077)

Changelog:
Fixed bugs and improved "Bitrate Redistribution" (now you can use 100% sample size).

Added Support to HC and QuEnc in "Bitrate Redistribution".
For HC and QuEnc the Q parameter is in CCE scale (is divided by 10). Example: to use Q=4.5 in HC you have to insert 45.

Various minor bug and cosmetic fixes.

[robot1]

That would suggest to include in RB-Opt as a first step a (say 1%, does not take much extra time) Q prediction automatically and to base the bitrate redistribution on that initial Q estimate rather than on some fix value.
You can predict Q value for CCE:
set the vobid as OPV.
Save and start prediction.
When you have found the Q value, cancel saving, and set again the vobid as VBR.
Start the bitrate redistribution, using the Q value found.

It's not very simple... on request I could automatize these steps.

[Sharc]

Thank you, yes, that's how I did it manually to find the "correct" Q for the subsequent redistribution.

Anyway, if you would find the time to automate these steps in a coming release I think that RB-Opt would be the first solution to solving the imminent and much discussed file size problem (undersized / oversized) of OPV, with all the benefits of encoding speed, quality and now even file size accuracy.

An encouragement rather than a request :)

[~bT~]

1st try using v0.27 and spot on 4.36GB! I had previously done the same DVD and it was undersized. Lets see how the next one goes..

[gurkan]

I'm curious if it's possible to make a variable Quantizer Characteristics. Or at least make the setting changeble betwen the segments.

[robot1]

I'm curious if it's possible to make a variable Quantizer Characteristics. Or at least make the setting changeble betwen the segments.
For every VobID, you can change the Quantizer Characteristic in the CCESettings window. I don't think it's necessary to have a variable quantizer characteristic for two reasons:
1) I don't see a straight relationship between quantizer characteristic and other parameters (length, bitrate)
2) Default value often works well.

[~bT~]

on request I could automatize these steps.Yes pls! :thanks:

[archaeo]

Have tested two discs now with v27b using bitrate redistribution, and both have been right on the money. Very pleased with this feature. I have been going with a 3% sample size for initial Q prediction, and a 15% sample for the actual redistribution step.

The automation step would be a plus, but can you retain the sampling size choice for both steps?

[~bT~]

^ I've just done the 2nd one. Also spot on. Sample size for Q=2% and for RD=20% without filters.

[Sharc]

I have tested v0.27 using bitrate redistribution with 0.5% for initial Q estimation and 33% sample size for the actual redistribution. I used avamat6 (aka AutoQ1) matrix.
=> Target size was hit on the spot. Quality is excellent.

The significant difference for some of the segments between the original average bitrate and the new bitrate after the redistribution is amazing: The orignal size reduction was about 62%, same for all segments of course. After the redistribution the reduction for the individual segments was between 11% (end credits, bold white letters on black background) and 83% (demanding scenes). Just as an example, the end credits were given an original average bitrate of 3350 kbps, after the redistribution the average rate was 603 kbps with no noticeable loss of quality.

These results underline Boulder's idea. Thanks Boulder for sharing your experience, and thanks robot 1 for implementing it in RB-Opt.:)

[~bT~]

Its seems like whichever way u do it, the combo of both hits on target. Good stuff!

[gurkan]

For every VobID, you can change the Quantizer Characteristic in the CCESettings window.

I wasn't aware of this. No reason to implement something that's already there. :-)

I'm backing up a movie with a ridiculousley low bitrate (to keep the commentary-track). All the segments look fine with a certain quantizer characteristic, except for one. And changing the setting for all would make the other segments look bad.

Making a variable quantizer would probably be virtually impossible anyway, since beauty's in the eye of the beholder.

[robot1]

The automation step would be a plus, but can you retain the sampling size choice for both steps?
I'm working to add this feature to next release.

[archaeo]

I'm working to add this feature to next release.

:) excellent

[tom942]

If I want try bitrate distribution with HC, could I use as Q value the one that I get with CCE for OPV?.

For instance, if I get Q=16 with CCE, could I use that value with HC?.

And will you implement OPV for HC in the same way that you did it for CCE?

Thanks :).

[robot1]

If I want try bitrate distribution with HC, could I use as Q value the one that I get with CCE for OPV?.

For instance, if I get Q=16 with CCE, could I use that value with HC?.

And will you implement OPV for HC in the same way that you did it for CCE?

Thanks :).
For HC you have to use the value in the same scale of CCE: if you want to use 1.6, you have to insert 16.
Anyway, the optimal Q in CCE will not be the optimal Q for HC.
I've implemented the optimal Q finding in HC. Next version will be ready in a couple of days.

[tom942]

For HC you have to use the value in the same scale of CCE: if you want to use 1.6, you have to insert 16.
Anyway, the optimal Q in CCE will not be the optimal Q for HC.
I've implemented the optimal Q finding in HC. Next version will be ready in a couple of days.

Okey. Then I'll wait to try your next release :).

BTW, I have just done a CCE test with Casino Royale R2 with two AC3 tracks and menus with motion, following Boulder's suggestion from the other thread (except I have used Avamat6) and the image quality is :eek:, with an average bitrate of 3223 kbps. The bitrate in some segments changes near 1000 kpbs :).

[robot1]

Here is the new release
RB-Opt v. 0.28 (http://www.savefile.com/files/693580)

Changelog:
Added Automatic Q find in "Bitrate Redistribution" (works also for HC).
New setup dialog.

[~bT~]

thanx mate! will test it out over the weekend. cheers!

[Rippraff]

Thanks robot1. :)

Small typo by the way. ;)

Cu Rippraff

[robot1]

:)
typo fixed for next release.

[Sharc]

Thanks robot1 for the new version.

Suggestion:
When changes have been made and pressing the "EXIT" button without "Save settings" before, a warning should be displayed "Exit without Saving? Yes / No". Otherwise there is a risk that the changes will be lost.

[jdobbs]

Maybe I'm a little confused. I wanted to do some testing with the redistribution method... but when I save it and compare the ECL file to the original, it doesn't seem to change???

[tom942]

I'm using latest DVD-RB free. I would like to know if it is possible to use with HC a diferent matrix than MPEG (like AVAMAT6) or a diferent DC when it does the OPV prediction and later the BD.

Would it be a good idea to implement something similar to "CCE settings" but for HC?. Another button where you could set the matrix, dc, bias..., and even pass some arguments?

Regards and thanks for this great "little" app :)

[Rippraff]

Using custom matrices is a feature which is only available in the Pro version.
Thinking of jdobbs' well deserved donations I hope this (http://forum.doom9.org/showthread.php?p=727052#post727052) is still valid.

Cu Rippraff