PDA

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


Pages : 1 2 [3] 4

Boulder
18th April 2007, 04:10
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
19th April 2007, 21:06
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
19th April 2007, 21:18
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
20th April 2007, 02:04
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
20th April 2007, 06:17
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
20th April 2007, 10:21
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
20th April 2007, 10:34
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
20th April 2007, 16:22
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
22nd April 2007, 04:55
OPV window is showing up when the "Save Settings" button is pressed. It should not do this unless OPV is requested.

robot1
22nd April 2007, 08:25
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
22nd April 2007, 10:12
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
22nd April 2007, 10:36
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
22nd April 2007, 12:15
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
22nd April 2007, 21:22
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
22nd April 2007, 21:24
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
22nd April 2007, 21:36
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
22nd April 2007, 21:40
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
22nd April 2007, 21:46
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
22nd April 2007, 22:47
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
22nd April 2007, 22:50
Cheers! Will try it out.

gurkan
23rd April 2007, 00:09
Bitrates don't come back negative with the new build. =)

jdobbs
23rd April 2007, 00:11
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
23rd April 2007, 01:51
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
23rd April 2007, 06:27
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
23rd April 2007, 08:16
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
26th April 2007, 23:16
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
26th April 2007, 23:18
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
27th April 2007, 09:43
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~
28th April 2007, 03:20
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
28th April 2007, 08:05
I'm curious if it's possible to make a variable Quantizer Characteristics. Or at least make the setting changeble betwen the segments.

robot1
28th April 2007, 09:37
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~
28th April 2007, 10:56
on request I could automatize these steps.Yes pls! :thanks:

archaeo
28th April 2007, 13:50
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~
28th April 2007, 14:00
^ I've just done the 2nd one. Also spot on. Sample size for Q=2% and for RD=20% without filters.

Sharc
28th April 2007, 14:19
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~
28th April 2007, 15:02
Its seems like whichever way u do it, the combo of both hits on target. Good stuff!

gurkan
28th April 2007, 19:37
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
28th April 2007, 20:02
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
28th April 2007, 20:09
I'm working to add this feature to next release.

:) excellent

tom942
4th May 2007, 16:55
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
4th May 2007, 16:59
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
4th May 2007, 17:19
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
4th May 2007, 22:33
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~
5th May 2007, 00:58
thanx mate! will test it out over the weekend. cheers!

Rippraff
5th May 2007, 02:01
Thanks robot1. :)

Small typo by the way. ;)

Cu Rippraff

robot1
5th May 2007, 09:00
:)
typo fixed for next release.

Sharc
5th May 2007, 10:17
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
5th May 2007, 18:15
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
5th May 2007, 23:41
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
6th May 2007, 01:07
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

tom942
6th May 2007, 02:43
I'm waiting a credit card that I request for send money to jdobbs among other users of the forum :). It will be my first purchase through paypal :).

Meanwhile, I just asked if it could be possible to implement it in RB-OPT :).

Regards,

Tom

jdobbs
6th May 2007, 04:09
If people started adding Pro capabilities to the freeware version there wouldn't be a lot of incentive for me to keep developing DVD-RB, would there?

tom942
6th May 2007, 18:50
@jdobbs

Donīt get me wrong. I'm agree with you, but I thought it couldnīt interfere with Pro version in the same way that already there is an option for CCE settings, so why not other for HC.

Please, I didnīt wanted to bother you. Sorry :(

robot1
6th May 2007, 19:27
DVD-RB free version doesn't use the .ecl to pass parameters to HC. It's not possible to tweak HC settings with the free version.
I suggest you to upgrade to pro, it's a great step ahead.

tom942
6th May 2007, 19:47
Thanks for the clarification :)

manolito
6th May 2007, 21:32
AFAIK the free version 0.98.2 of DVD-RB supports HC with custom matrices quite nicely. You just have to specify the desired matrix in the HC.ini file. The line in HC.ini could look like this:
*MATRIX AVAMAT7

DVD-RB free does not try to manipulate the HC.ini at all because it thinks it is dealing with QuEnc.

Cheers
manolito

tom942
7th May 2007, 00:47
@Manolito

It is what I'm doing, but I just wanted to try the new method of Bitrate Distribution with RB-OPT.

But instead of using the matrix, the DC or the bias that I've got set under HC.ini (AVAMAT6) in DVD-RB, RB-OPT uses MPEG matrix and its own DC. I mean it overrides my HC.ini, and this was the thing I asking for, nothing else.

And like RB-OPT allow to modify all these things for CCE, I just asked for something similar for HC (like a menu). The only thing that I would like is can use the settings from my HC.ini in the prediction of RB-OPT. :)

PS: Excuse my english. It is not my mother tongue. I hope to express well.

Sharc
12th May 2007, 10:41
@robot1:
RB-Opt includes a very handy AVS editor. It is applicable on a per VOB-ID basis.
Would it be possible - in a future version - to allow the AVS editing on a per cell basis as well, for example in the "tweak cells" window? This would be very handy for filtering individual scenes differently or selectively.

dirio49
14th May 2007, 00:15
@robot1
Thanks for the new version.
One suggestion.
In the redistribution, it would be nice if we had a choice to exclude some cells for the redistribution.
Like credits, that i like to just kill. with the lowest bitrate .
thanks

Sharc
18th May 2007, 06:30
I had again a case:
After redistribution and pressing OK, the new cell bitrates were not transferred to the ecl.
Not sure however if I pressed the button sequence OK => EXIT, ie skipping Save Settings.
Should I - after redistribution - always press OK => Save Settings => (Settings Saved) OK => Exit?

Boulder
18th May 2007, 08:50
I always do the save settings part, it probably is needed to save the new bitrates.

Sharc
18th May 2007, 19:29
@robot1:
When I blank the first cell of a VOB-ID by means of the DVD RB editor, the subsequent Q estimation or OPV prediction of RB-Opt fails to deliver correct results.

Trying to run the AVS editor in RB-Opt delivers the (correct) error message of unequal lengths of the avs script files -- due to the previous blanking of cells with the DVD Rebuilder editor.

When I unblank the first cell everything works correctly.

robot1
19th May 2007, 17:42
@robot1:
RB-Opt includes a very handy AVS editor. It is applicable on a per VOB-ID basis.
Would it be possible - in a future version - to allow the AVS editing on a per cell basis as well, for example in the "tweak cells" window? This would be very handy for filtering individual scenes differently or selectively.
Sorry for the late reply, I was away.
Yes, it will be possible, and I will add this feature.

robot1
19th May 2007, 17:44
@robot1
Thanks for the new version.
One suggestion.
In the redistribution, it would be nice if we had a choice to exclude some cells for the redistribution.
Like credits, that i like to just kill. with the lowest bitrate .
thanks
You should have the redistribution step, than tweak the end credits cell to the lowest possible value. The saved bitrate will be given to the other cells.

robot1
19th May 2007, 17:45
Should I - after redistribution - always press OK => Save Settings => (Settings Saved) OK => Exit?
Yes, you have always to save the settings to make changes permanent.

robot1
19th May 2007, 17:49
@robot1:
When I blank the first cell of a VOB-ID by means of the DVD RB editor, the subsequent Q estimation or OPV prediction of RB-Opt fails to deliver correct results.

Trying to run the AVS editor in RB-Opt delivers the (correct) error message of unequal lengths of the avs script files -- due to the previous blanking of cells with the DVD Rebuilder editor.

When I unblank the first cell everything works correctly.
I have to fix this. It's easy if you blank the first or the last cell, and I think that next version will have this fix. It's more troublesome when you blank a cell in the middle (but it's a very rare case).

Sharc
19th May 2007, 18:56
:thanks: for considering my proposals in a future release.

Sharc
20th May 2007, 20:42
Yes, it will be possible, and I will add this feature.
Thanks for taking this into consideration.
I imagine that it may become difficult for the OPV prediction when individual cells have different filter scrips. I would assume however that only very few cells (1 or 2) in a VOB-ID will need an individual filter script, hence the OPV prediction reliability should not be unduly affected.

~bT~
21st May 2007, 23:02
Feature Request:

Option to select starting Q factor.

Dashiell
26th May 2007, 01:59
Hey guys,

This may be a dumb question, I'm not an RB noob but I am an RB-OPT noob.

I see that you can select the CCE filters and select the "Natural Filter" without a problem, but does it actually stick? I've heard tale that it cannot be activated/used with CCE Basic. I own Basic 2.70.1.15.

Thanks!

Sharc
26th May 2007, 10:29
@robot1:
When Rebuilder assigns different -- ie bitrate dependent -- matrices to the cells within a VOB-ID, RB-Opt will ask for a manual re-assignment of a specific matrix for redistribution. Means in the subsequent encode the bitrate dependent matrix selection will be lost.
Don't know if this could be fixed in a future release.

robot1
26th May 2007, 16:43
Hey guys,

This may be a dumb question, I'm not an RB noob but I am an RB-OPT noob.

I see that you can select the CCE filters and select the "Natural Filter" without a problem, but does it actually stick? I've heard tale that it cannot be activated/used with CCE Basic. I own Basic 2.70.1.15.

Thanks!
I think CCE basic hasn't filtering capability.

robot1
26th May 2007, 16:46
@robot1:
When Rebuilder assigns different -- ie bitrate dependent -- matrices to the cells within a VOB-ID, RB-Opt will ask for a manual re-assignment of a specific matrix for redistribution. Means in the subsequent encode the bitrate dependent matrix selection will be lost.
Don't know if this could be fixed in a future release.

OPV prediction couldn't be exact if there are different matrices in the segments.
Anyway, I could disable this check only if you calculate Q factor in the redistribution step, as optimal Q isn't fundamental.

Sharc
26th May 2007, 17:08
Yes, for OPV this is definitely a problem. and one should stick to one single matrix.
For redistribution, disabling this check would be useful because redistribution normally even increases the swing of the average bitrates, hence preserving (or even automaticallly re-assigning ?) the bitrate dependent matrix selection would be beneficial to the final result, IMHO.
Thank you for considering this possibility.

Dashiell
29th May 2007, 20:45
I think CCE basic hasn't filtering capability.

Yes, this is true.

I am told, however, that the four "basic" filters contained within CCE are present in every version.

Natural, Animation, etc, etc...

Video Dude
30th May 2007, 01:24
CCE Basic has 3 filter presets: Natural Picture, Computer Graphics, and Animation.

But you can't customize or tweak the filter options. You are limited to the 3 presets only.

Snarko
30th May 2007, 16:13
This bitrate redistribution and automatic Q finding stuff is great!

I'm using HCEnc 0.21, and generally not using the MPEG default matrix. Is there any way RB-Opt could use the matrices specified in DVD-RB Pro to calculate the Q and redistribution passes, instead of always using the MPEG matrix? Or is it about as close as matters already, even if a matrix like AVAMAT6 compresses more than the MPEG matrix? Thanks.

gurkan
6th June 2007, 16:32
CCE throws me a "OPV VBV ovf frame# 124812 (01:23:12:14) I 81616 max 81327,95 rel 288,05,1,00 qsv 4,90->5,41".
This happens in the opv prediction (sample 100%) before Bitrate Redistribution, during second pass when it tries to go for Q=1.
Max Bitrate in RB-Opt settings says 8014.
Any tips on how I can avoid this kind of error?

Boulder
6th June 2007, 16:42
Set the Q value manually to something higher than Q1.

gurkan
6th June 2007, 17:22
If it's setting the q-value of the redistribution to an arbitrary guess that you mean, than sure I could do that.
But I would've really liked RB-Opt to calculate the optimal Q for me instead since I don't really trust my guesses.
Sorry if I've misunderstood you.

Boulder
6th June 2007, 20:11
Well, I don't think it really is crucial to predict the Q value for redistribution. In fact, I never do that myself when I use HC. The ratio between different segments should remain pretty much the same, although that should be tested to be sure.

Sharc
7th June 2007, 10:32
I did various tests regarding the impact of the Q-factor on redistribution with CCE.
It appears that there exists an asymptotic behaviour:

a) For very low Q factors (Q=1,2,3) the redistribution follows more or less the standard multipass VBR distribution of DVDRB
b) With increasing Q facor the redistribution deviates more and more from the standard multipass VBR curve, generally increasing the swing
c) With further increasing Q, the redistribution converges to an asymptotic redistribution which does not change much when Q is further increased.

Q-factors that correspond to the DVD-5 target size are normally in the asymptotic range of c).

In the graph below, Q=18 would approximate the DVD-5 target size. There is little change when increasing Q to 64 for setting up the redistribution profile.

The tests I did apply to CCE.

Sharc
7th June 2007, 13:29
And here another example showing the influence of Q on the redistribution, for Q=1, 12, 64.
Q=12 applies for a DVD-5 target size and produces the same profile which one would get for standard OPV.

Sharc
9th June 2007, 07:45
The Q factor for a given target size depend heavily on the selected matrix -- for example Q=9 for Avamat6, Q=18 for CCE Default, Q=58 for FHE for the same title.

After having done more tests with the selection of Q for redistribution, my recommendation is to do the redistribution with a Q factor which approximates the target size for the selected matrix or to let RB-Opt do the choice -- a small sample size of 0.5% to 1% is sufficient. With a Q corresponding to the target size, the redistribution even becomes fairly independent of the selected matrix.
All my test are with CCE.

When a low Q is selected with a high bitrate matrix like FHE, I noticed that CCE may be aborted, skipping the rest of the cell -- possibly because the bitrate becomes excessive (?).

Boulder
9th June 2007, 07:51
I actually thought that the redistibution is always done using the MPEG standard matrix. That's what is used with HC at least, no matter what you have chosen to use in DVD-RB.

Sharc
9th June 2007, 08:01
You can select any matrix for redistribution with CCE and RB-Opt, using the "CCE settings" button in RB-Opt.

I have no experience with HC and OPV for redistribution though. Unfortunately, for some odd reason, I cannot run HC in OPV mode on my system. It does not produce an OPV test file.

Sharc
9th June 2007, 08:16
Here a plot for differnet matrices.

Q always corresponding to a DVD-5 target size for the given matrix. The redistribution then appears to be fairly independent of the matrix.

Boulder
9th June 2007, 08:40
Do you have XviD or DivX5 or higher installed? HC needs an YV12 decoder to work.

Sharc
9th June 2007, 09:29
Yes, I have DivX5 and ffdshow (XviD) installed.
HC runs perfectly in multipass mode, it only fails when I want to use it for OPV or redistribution when generating the testfile for Q estimation. Seems to be something wrong with the avisynth script. I double checked it, but I did not find anything unusual.

Boulder
9th June 2007, 09:36
Could you post the script that is used for the prediction and also the ini file? You should also be able to see an error message in the HC GUI window if there is something wrong.

Sharc
9th June 2007, 10:10
Thank you for your help.

In order not to deviate from the main subject of this thread I suggest to continue this discussion in my former thread:
http://forum.doom9.org/showthread.php?t=122803.

Thanks again.

Insomniak4700
10th June 2007, 08:03
ATM, the bitrate redistribution has to be run one VTS at a time... Would it be possible to have an option to run it on multiple VOB IDs at the same time? This could be usefull for episodic discs

~bT~
10th June 2007, 09:53
ATM, the bitrate redistribution has to be run one VTS at a time... Would it be possible to have an option to run it on multiple VOB IDs at the same time? This could be usefull for episodic discs
I was going to post this request too. Not only episodic DVD's but some movies have multiple VTS' too. :)

Sharc
10th June 2007, 10:01
@robot1:
Bitrate prediction for OPV and Redistribution:

Based on the % value for the sample size, the sample size may become too small for a reliable bitrate allocation for small cells.
I would therefore suggest to base the sample size on a function like:
SampleSize=Max(percentage;number of frames)

with
percentage = the percentage as selected in RB-Opt
number of frames=500.

Means at least 500 frames (or the entire cell if it should be smaller than 500 frames) will be included in the sample. This should be adequate for a reliable bitrate estimation.

This issue has been recently addressed by jdobbs:
http://forum.doom9.org/showthread.php?p=1012292#post1012292

robot1
10th June 2007, 12:06
ATM, the bitrate redistribution has to be run one VTS at a time... Would it be possible to have an option to run it on multiple VOB IDs at the same time? This could be usefull for episodic discs
This is in my Todo-List.

robot1
10th June 2007, 12:08
@robot1:
Bitrate prediction for OPV and Redistribution:

Based on the % value for the sample size, the sample size may become too small for a reliable bitrate allocation for small cells.
I would therefore suggest to base the sample size on a function like:
SampleSize=Max(percentage;number of frames)

with
percentage = the percentage as selected in RB-Opt
number of frames=500.

Means at least 500 frames (or the entire cell if it should be smaller than 500 frames) will be included in the sample. This should be adequate for a reliable bitrate estimation.

This issue has been recently addressed by jdobbs:
http://forum.doom9.org/showthread.php?p=1012292#post1012292
I have read the thread, and right now I was coding that.

robot1
11th June 2007, 23:07
Here is the new build:
RB-Opt v. 0.29 beta (http://www.savefile.com/files/801164)

Changelog:
Used dvd-rb defined matrices in Bitrate redistribution for HC and QuEnc.
Allowed different matrices and parameters in the segments to redistribuite.
Fixed a minimum sample length for cells to encode in bitrate redistribution (default 500, can be changed in the RB-Opt.ini)
Disabled Scene Change detection for HC encoder in bitrate redistribution, to have a better size estimate.
Handling of cells set to "no reencode", "blank" or "slideshow" in DVD-RB Segment Editor
In avs editing, if the script for the first cell or the last one is different, the different cell is ignored (example: only one cell interlaced - usually the last one). It's possible to edit the .avs for all the standard cells of the VobID


Next version will have redistribution among different VTS's

~bT~
12th June 2007, 00:04
Awesome job mate! Thanx a lot!

Sharc
12th June 2007, 00:27
Thanks! Useful improvements which I will definitely try out.

archaeo
12th June 2007, 02:01
Next version will have redistribution among different VTS's

Great :) I am very appreciative of the renewed energy that you have been applying toward RB-Opt development as of late - many thanks.

Insomniak4700
12th June 2007, 02:37
Here is the new build:
RB-Opt v. 0.29 beta (http://www.savefile.com/files/801164)


Thanks robot1! While I was trying the last version yesterday I was wondering how much of an impact not using the same Q matrix would have! I can compare the two now!

TomBrooklyn
12th June 2007, 10:02
Hi,
Nice work robot1. I didn't want to read through all 16 pages of this thread, but I read in the beginning that the first beta was not supporting HC. Is it usable with HC now? Regards, TomBk

Boulder
12th June 2007, 14:44
Hi robot1,

here are some small comments regarding using HC:

1) When doing bitrate redistribution and you choose to calculate the optimal quantizer to use, the "ignore filters" option is not considered in the prediction phase. (this probably applies to all encoders)

2) In the forementioned prediction phase, you probably should use a 15-2 GOP if the source is PAL and autoGOP is selected in DVD-RB. In NTSC, 12-2 is probably the most accurate choice.

3) In the actual redistribution phase, you should use the GOP settings from DVD-RB like before, now it looks like 12-2 is used there too.

robot1
12th June 2007, 17:22
Hi robot1,

here are some small comments regarding using HC:

1) When doing bitrate redistribution and you choose to calculate the optimal quantizer to use, the "ignore filters" option is not considered in the prediction phase. (this probably applies to all encoders)

2) In the forementioned prediction phase, you probably should use a 15-2 GOP if the source is PAL and autoGOP is selected in DVD-RB. In NTSC, 12-2 is probably the most accurate choice.

3) In the actual redistribution phase, you should use the GOP settings from DVD-RB like before, now it looks like 12-2 is used there too.
These adjustments will be in next version.

robot1
12th June 2007, 17:24
Hi,
Nice work robot1. I didn't want to read through all 16 pages of this thread, but I read in the beginning that the first beta was not supporting HC. Is it usable with HC now? Regards, TomBk
RB-Opt works with HC, but some advanced options are not available for this encoder.

tom942
12th June 2007, 18:10
This question goes to Boulder or anyone that can help me.

I was reading in the help of Ammon82's AutoQ that 12 was better because it is related to the framerate,and also I've seen that when HC does CQ One pass, it selects 12-2, so why is better for 15 gop than 12?. Could you tell me where can I find info related to this?.

And why is better 10 bits of DC precission than 8 or 9?. I've done several test with SP and HC, and I've seen the image improves with 10,but, why?.

Sorry for the off-topic, if so, I'll move it to other place in the forum.

Greetings.

Boulder
12th June 2007, 19:03
I think you should post your question as a new thread in the MPEG2 encoding forum as it's a general one and doesn't deal directly with RB-Opt.

In general, a longer GOP compresses better because there are fewer I-frames. Then again, a long GOP may affect quality because there are more frames that are "constructed" using other frames as a reference. See http://en.wikipedia.org/wiki/Video_compression_picture_types for detailed info.

I very rarely use 12-frame GOPs, only when having encoder saturation. I use autoGOP with a maximum of 15 frames 99% of the time.

I'll leave the DC precision part for someone else to answer.

tom942
12th June 2007, 19:18
With affect quality, you mean a bit worse?.

What do you mean with encoder saturation?.

I move it to the other forum. BTW, thank you for the answer :).

kumi
12th June 2007, 21:54
@Boulder:

I read somewhere that pulldowned sources need special care when choosing GOP. Can you tell me how to determine when a 12-frame GOP is _necessary_?

~bT~
12th June 2007, 23:07
^ this thread may answer your questions: http://forum.doom9.org/showthread.php?t=124824

kumi
12th June 2007, 23:54
Thank you for that link. But I'm still not sure how to tell when the output of DVD Rebuilder is going to use rff flags. Where do I look?

jdobbs
13th June 2007, 03:26
If the source is 23.976. DVD-RB will reimplement the same TFF/RFF sequences as the original.

tom942
15th June 2007, 19:31
@robot1

Could you add a log with the old and new bitrate distribution in a similar way that DVD-RB does to compare the final results?

:thanks:

robot1
16th June 2007, 12:31
Here is:
RB-Opt v. 0.30 (http://www.savefile.com/files/814252)

Changelog:
Redistribution can now involve multiple VOBIDs (useful for episodic discs)
Support for HC Lumgain and Autogop parameters, through settings in RBOpt.ini
In redisitribution process, if checked "disable all filters", filters are ignored also in the Q search phase
Changed the final log in the redisitribution, to compare original and redistributed values
Improved Q finding precision for HC encoder

As always, feedbacks are welcome.

~bT~
16th June 2007, 14:11
^ Much appreciated update. :thanks:

tom942
17th June 2007, 20:27
:thanks: for the update robot 1 :)

kumi
17th June 2007, 21:51
Thanks a lot for version 0.30, robot1 :)

I have a few questions about bitrate redistribution, my apologies for using a list format:

1/ Does HC_LUMGAIN > 0 play along nicely with RBOpt's bitrate redistribution?

2/ Will bitrate redistribution work with ProCoder projects? I know I've read somewhere that OPV mode in ProCoder is broken... but can't the redistribution be done with HC or CCE?

3/ When using filters that affect Q (sharpening, denoising etc.) is it advisable to use "disable all filters"?

4/ Sharc mentioned on page 30 of this thread that "a small sample size of 0.5% to 1% is sufficient", but the RBOpt default value is set to 20%. Is it safe to use a sample size of 1% here?

Sharc
17th June 2007, 22:45
Let me comment on 4/:

There are 2 different %-age settings:
a) One relates to the redistribution of the segments
b) One relates to the estimation of Q

For a) I normally select 25% because this is in relation to the number of frames of the individual segments.

For b) I normally select 0.5% to 1% because this is in relation to the number of frames of the entire movie (or all linked VOB-IDs, respectively).

Generally speaking, I select the percentages for each case such as to grab a sufficient number of frames. I consider about 500 ... 1000 frames sufficient. Therefore the 25% for a) and the 1% for b).

robot1
17th June 2007, 23:21
1/ Does HC_LUMGAIN > 0 play along nicely with RBOpt's bitrate redistribution?

I haven't tested it much, and I'm not sure if this setting is important in OPV encoding or only in VRB encoding. Anyway, I'd set LUMGAIN at the same value used in DVD-RB.


2/ Will bitrate redistribution work with ProCoder projects? I know I've read somewhere that OPV mode in ProCoder is broken... but can't the redistribution be done with HC or CCE?

Redistribution works with EclPRO, only if you are using ProCoder 2.
Anyway, I'd use always Q=1, and the results are a bit different from the ones you get with other encoders. Need more (visual) tests for a better answer.


3/ When using filters that affect Q (sharpening, denoising etc.) is it advisable to use "disable all filters"?
There are tests in another thread. If I remember well, the results are similiar with filters enabled or disabled. If time is not an issue, leave all filters enabled.


4/ Sharc mentioned on page 30 of this thread that "a small sample size of 0.5% to 1% is sufficient", but the RBOpt default value is set to 20%. Is it safe to use a sample size of 1% here?
See the previous post by Sharc. I would not go under 10% for redistribution.

kumi
17th June 2007, 23:38
Thanks, Sharc & robot1.

I haven't tested it much, and I'm not sure if this setting is importantHave you tested, then, with CCE's AQM? This and LUMGAIN both operate in a similar fashion if I'm not mistaken, so if you have experience with AQM+redistribution it's probably valid to extrapolate to LUMGAIN+redistribution.


Redistribution works with EclPRO, only if you are using ProCoder 2. Anyway, I'd use always Q=1I see, so I should use a Q factor of 1, and disable "Calculate optimal Q"? I'd be happy to do some ProCoder 2 testing, if I can determine the right way to go about it.

Boulder
18th June 2007, 03:25
If I remember correctly, CCE's adaptive quant matrices feature is not applied when you do an OPV encode. I personally wouldn't use LUMGAIN in the redistribution at all unless a 100% sample size is used in the redistribution phase. Otherwise it'll add an uncertainty factor in the process - we are doing a constant quant encode in which the matrix has a key role what comes to final filesize and thus the final bitrate distribution among the segments.

ProCoder's problem is that the Q scale is very bad, even at the maximum quality, you often undersize. That's why you should use Q=1 and not predict it (prediction is mostly a complete waste of time in ProCoder).

kumi
18th June 2007, 10:12
Thanks for the clarification Boulder.

I've been trying to test the redistribute function, but I am running into a problem with RBOpt. It freezes after encoding the penultimate segment, with RBOpt.exe pegged at 100% CPU usage.

For reference, I am using RBOpt 0.30, DVD-RB 1.26 Pro and HC 0.21. I use Windows XP SP1 with an AMD Sempron 2600+ and 512MB RAM, with absolutely the bare minimum of services and running programs.

I open the Redistribute tab, and use these settings:
Two VobIDs selected on the left: VTS 1 - Vob-ID 1 and VTS 1 - Vob-ID 2
Sample size: 20%
Q Factor: 20
Threads: 1
Launch Encoder Minimized: yes
Calculate Optimal Q: no
Ignore all filters: no

I've also tried with Calculate Q on, Ignore all filters on, and encoder default matrix set in DVDRB. It's always the same story: RBOpt finishes encoding the next to last segment, and then the "Bitrate Redistribution" windows becomes "Not Responding" and freezes with 100% CPU. The last lines in the log read:
=== Completed encoding VTS 1 VobID 2 segment 11
Size of the segment: 38442 KB
Segment bitrate: 4952

It never starts the final VTS 1 VobID 2 segment 12. What could be the problem?

Boulder
18th June 2007, 10:28
Have you tried with minimized encoder window unchecked?

By the way, I'm not even sure if LUMGAIN is considered when you do a constant quant encode..I've never checked the matrices of a constant quant encode with DGIndex.

robot1
18th June 2007, 10:40
It never starts the final VTS 1 VobID 2 segment 12. What could be the problem?
I will check.
Meanwhile, could you test with RB-Opt 0.29 and with 0.30 selecting one VobID?
Thank you.

kumi
18th June 2007, 19:44
OK, in RBOpt 0.29, the redistribution completes successfully.

I ran RBOpt 0.30 twice (both times with "launch encoder minimized" unchecked):

Running it on only Vob-ID 1: Success
Running it on only Vob-ID 2: Freezes after penultimate segment completes.

So it appears the problem is related to the last segment of VTS 1 - Vob-ID 2 (a small cell with only 49 frames), and only in RBOpt version 0.30.

Here's my REBUILDER.INF:
http://pastebin.ca/574797

And my REBUILDER.ECL:
http://pastebin.ca/574799

robot1
18th June 2007, 22:52
OK, in RBOpt 0.29, the redistribution completes successfully.

I ran RBOpt 0.30 twice (both times with "launch encoder minimized" unchecked):

Running it on only Vob-ID 1: Success
Running it on only Vob-ID 2: Freezes after penultimate segment completes.

So it appears the problem is related to the last segment of VTS 1 - Vob-ID 2 (a small cell with only 49 frames), and only in RBOpt version 0.30.

Thank you for your tests.
I've PM'ed you a test version - hope to have solved the bug.

kumi
19th June 2007, 00:12
robot1: *ding* You've got mail

On an unrelated and somewhat unimportant note, is it possible for RBOpt to consume less RAM on startup? It eats up ~240MB of my 512MB system total, which is quite a burden when it spawns HC (which eats up another ~200MB).

EDIT: Nevermind, memory usage is fine at ~15MB, I was looking at the wrong column.

robot1
19th June 2007, 11:44
Solved the bug reported by Kumi
RB-Opt v. 0.31 beta (http://www.savefile.com/files/822335)

Added through RBOpt.ini support in redistribution for:
HC_Profile (0 fast - 1 normal - 2 best) -default best
QuEnc_Qual (0 normal - 1 high) - default high
QuEnc_Trellis (0 off - 1 on) - default off

tom942
20th June 2007, 01:32
@robot1

I don't know if it's a bug, but when HC starts the Q value prediction it sets DC precision to 12 :eek:. Later, when it starts to encode it sets it to 11 (the max value in HC, I suppose).

Is it possible that RB-OPT takes the value that is set in DVD-RB or set it through RBOPT.ini?

:thanks:

kumi
20th June 2007, 01:51
I'm seeing the same behaviour: both the Q prediction HC .ini files and the bitrate prediction item0.ini files both have:

*DC_PREC 12

But the HC GUI shows "dc prec 11". My DVDRB DC Prec is set to "Auto".

kumi
20th June 2007, 08:25
I ran a redistribution on a disc with 10 short films (1 per VTS, 1 per segment) and noticed segment 2's new bitrate is quite a bit higher than the original DVD9:

http://img261.imageshack.us/img261/3746/imagebl5.png



I'm not sure what to make of this. Common sense tells me it's more desirable to subtract bits from the source, rather than add bits ;)

robot1
20th June 2007, 10:34
I'm seeing the same behaviour: both the Q prediction HC .ini files and the bitrate prediction item0.ini files both have:

*DC_PREC 12

But the HC GUI shows "dc prec 11". My DVDRB DC Prec is set to "Auto".
Could you send me rebuilder.inf and rebuilder.ecl?
Thank you.

robot1
20th June 2007, 10:40
I'm not sure what to make of this. Common sense tells me it's more desirable to subtract bits from the source, rather than add bits ;)
http://forum.doom9.org/showthread.php?p=1014831#post1014831

The distribution graph is interesting, but we need visual test to check if redistribution gives a better visual result than a standard vbr encoding.

kumi
20th June 2007, 17:29
Could you send me rebuilder.inf and rebuilder.ecl?Sure thing. FYI: when I encode this project from DVD-RB as VBR, there is no *DC_PREC directive in the intermediate HC.INI files created, and the HC GUI reports "dc prec 9" for all of the segments.

REBUILDER.ECL
http://pastebin.ca/579264

RFBUILDER.INF
http://pastebin.ca/579270



we need visual test to check if redistribution gives a better visual result than a standard vbr encoding.I will run some comparisons and report my findings. Is the max_reduction variable in rbopt.ini responsible for limiting bitrates to a percentage of the original?

EDIT: Nope, I guess it isn't. Also, I just noticed that DVD-RB won't accept +100% compression levels on any segments, and seems to set any that have "overshoot" to 100% compression when you start an ENCODE phase. But the saved bits aren't redistributed back to the other segments, so I think this is a problem (and might cause undersizing?)

robot1
20th June 2007, 21:27
Download here:
RB-Opt v. 0.32 beta (http://www.savefile.com/files/826263)

Fixed the bug reported by Tom942 and Kumi: in some circustancies, the DC Precision for HC was wrong.
Added in RBOpt.ini support for HC_AutoDC (0 Disabled - 1 Enabled)

robot1
20th June 2007, 21:31
I will run some comparisons and report my findings. Is the max_reduction variable in rbopt.ini responsible for limiting bitrates to a percentage of the original?

EDIT: Nope, I guess it isn't. Also, I just noticed that DVD-RB won't accept +100% compression levels on any segments, and seems to set any that have "overshoot" to 100% compression when you start an ENCODE phase. But the saved bits aren't redistributed back to the other segments, so I think this is a problem (and might cause undersizing?)
You have to change also a setting in the Rebuilder.ini
Anyway, as you stated above,
Common sense tells me it's more desirable to subtract bits from the source, rather than add bits
I suggest you to leave
max_reduction=100
in RB-Opt.ini, so you don't have problems, and will get the right size because RB-Opt redistribuite the saved bits.
I tell you more: if I get a 100% reduction, I'd tweak the cell, lowering its bitrate, to give more room to other cells. Else, you can set the cell at "no compression" in DVD-RB

Sharc
20th June 2007, 21:54
EDIT: ...... But the saved bits aren't redistributed back to the other segments, so I think this is a problem (and might cause undersizing?)
I think this is on jdobbs' agenda:
http://forum.doom9.org/showthread.php?p=1014800#post1014800

Sharc
20th June 2007, 21:59
.....I tell you more: if I get a 100% reduction, I'd tweak the cell, lowering its bitrate, to give more room to other cells.
Or set max_reduction=90, for example, to have it done automatically?

robot1
20th June 2007, 22:12
Or set max_reduction=90, for example, to have it done automatically?
Probably it should work, but I haven't tried.
max_reduction is a very beta setting, and I haven't played much with it.

You have to check the exact reduction (and bitrate) in the tweak cell dialog, because the log in the redistribution reports the calculated bitrate. The check against max_reduction is performed later, when you press the OK button.

Sharc
20th June 2007, 22:15
I see, thanks. I will try.

kumi
21st June 2007, 01:23
robot1, thanks a lot for version 0.32 :cool:

I finished a visual comparison of a CBR-ish DVD, pitting HC VBR versus RBOpt redistributed (the graph I posted above). The source is Korean Academy of Film Arts - My Beautiful Short Stories Vol. II, 'Naui Areumdaun Danpyeon Vol.II' (2007) R0:

As opposed to other 8 segments, segments 1 and 2 are shot on old handhelds (8mm, perhaps) with tons of noise, grain, and film speckles/dust. The VBR versions are positively swimming in blocks, compared to the redistributed versions.

Looking at segment 8, where VBR bitrate minus redistributed bitrate is greatest, the VBR version of segment 8 is a bit better than the redistributed version. A little bit less mosquito noise and macroblocking. The other seven segments I consider pretty much a tie.

So huge thumbs up for redistribution on this particular disc, one with a high variance in original video quality from segment to segment. I look forward to testing now on more common VBR-encoded one-movie type discs.



I suggest you to leave max_reduction=100 in RB-Opt.ini, so you don't have problems, and will get the right size because RB-Opt redistribuite the saved bits.OK, I understand now. Redistribution writes to the Reduction= and Video_Sectors= in REBUILDER.INF. If a segment overshoots the original bitrate, RBOpt redistributes the saved bits exactly like you said. The sum of Video_Sectors remains about the same before and after redistribution, which was my clue it's saving bits correctly.

It's confusing, because the values reported in the Bitrate redistribution log do not account for the Reduction= safety mechanism. Could you add some extra info in the log to segments that get 'Reduced'?

More importantly, why doesn't RBOpt write the correct vbr_brate_avg values to REBUILDER.ECL? In cases of overshot bitrate, the values before reduction are written, instead of the actual, compensated bitrates:

Actual rebuilder.ini Percent
Segment Bitrate vbr_brate_avg Deviation
------------------------------------------
01 5251 5251 0%
02 5724 6495 +13%
03 3069 3069 0%
04 2880 2880 0%
05 2972 2972 0%
06 3688 3688 0%
07 3023 3023 0%
08 2360 2360 0%
09 3749 3749 0%
10 2503 2503 0%

Can this be done automatically by RBOpt?


- - -
P.S.: I noticed RBOpt adds lines containing "no_move=0" to REBUILDER.ECL. Just curious, what does that do?

Sharc
21st June 2007, 06:40
@kumi
Just for my understanding: Is "Actual bitrate" in your table the bitrate of the final ecnode? Means for segment 2 the encoding was done correctly at the reduced (original, 100%) bitrate, and the +13% overshoot is only a matter of the rebuilder.ecl?

kumi
21st June 2007, 06:46
Yes, exactly.

tom942
21st June 2007, 09:20
Thanks robot1. I'm going to try it.

robot1
21st June 2007, 10:06
OK, I understand now. Redistribution writes to the Reduction= and Video_Sectors= in REBUILDER.INF. If a segment overshoots the original bitrate, RBOpt redistributes the saved bits exactly like you said. The sum of Video_Sectors remains about the same before and after redistribution, which was my clue it's saving bits correctly.

It's confusing, because the values reported in the Bitrate redistribution log do not account for the Reduction= safety mechanism. Could you add some extra info in the log to segments that get 'Reduced'?
Yes, you are right. I haven't changed the log because I want to show what would be the ideal bitrate for a given Q for that cell.

More importantly, why doesn't RBOpt write the correct vbr_brate_avg values to REBUILDER.ECL? In cases of overshot bitrate, the values before reduction are written, instead of the actual, compensated bitrates:

Actual rebuilder.ini Percent
Segment Bitrate vbr_brate_avg Deviation
------------------------------------------
01 5251 5251 0%
02 5724 6495 +13%
03 3069 3069 0%
04 2880 2880 0%
05 2972 2972 0%
06 3688 3688 0%
07 3023 3023 0%
08 2360 2360 0%
09 3749 3749 0%
10 2503 2503 0%

Can this be done automatically by RBOpt?

RB-Opt should write the same bitrate in Rebuilder.ecl and Rebuilder.inf. Do you find different avg_bitrates? Can you post Rebuilder.inf/ecl and the .original ones?


- - -
P.S.: I noticed RBOpt adds lines containing "no_move=0" to REBUILDER.ECL. Just curious, what does that do?
It's a swicth for CCE SP 2.70.

kumi
21st June 2007, 18:54
Here you go, .ECL/.INF before and after redistribution:

http://www.savefile.com/files/828723

tom942
21st June 2007, 21:15
I think I found a little bug.

I've been testing CCE SP OPV and when you set sample size to 3% and try for instance with HVS-Better o Jawor's 2CD matrices, CCE fails and reports a Q=1. Meanwhile if you set it to 2% or 4%, the prediction works fine.

Sharc
21st June 2007, 21:36
It seems to me as if the reduction to the original bitrate (100%) does not work as it should when the redistributed bitrate exceeds the original.
For example, I got the following values (max_reduction=100) for cell 5:

Original: 5668 (measured with DGIndex)
Redistributed: 6368 (from log and rebuilder.ecl)
Actual encoded: 6161 (measured with DGIndex)

There seems to have been some reduction from 6368 to 6161, but not to 5668 (100%) as I would have expected.

I did a new redistribution pass with max_reduction=90. After pressing OK at the end of the redistribution pass the rebuilder.ecl still indicated vbr_brate_avg=6368. I did not do the encode, though.

kumi
21st June 2007, 22:15
I'm not seeing a discrepancy when I measure bitrates with Elecard StreamEye or when I simply look at .M2V file sizes:

vbr_brate_avg Original Original Encoded
deviation DVD9 .m2v DVD9 .m2v .m2v Original Re-encoded
from 100% Bitrate Bitrate Bitrate DVD9 .m2v .m2v
Segment Reduction (Elecard) (DVD-RB) (Elecard) Filesize Filesize
-------------------------------------------------------------------------------
02 +13% 5732 5724 5719 382MB 387MB

I think DGIndex uses a different method of bitrate estimation than DVD-Rebuilder. Have you compared the original DVD9 .M2V filesize to the re-encoded one? In my case they're very similar, and so are the bitrates as reported by Elecard.

EDIT: Hmm, in my case DGIndex 1.4.9 reports 100% bitrate (5723), not 113% bitrate (6111).

Sharc
21st June 2007, 22:31
Thanks for the hint. May be it's related to the method of bitrate measurement. I will check again with other methods.
Still, what makes me wonder a little is that I measured the original disk and the final RB-encode using the same method (DGIndex) and got different results.

kumi
21st June 2007, 22:37
I just edited my post with my DGIndex results. Maybe your bitrate discrepancy is caused by the way DVD-RB uses a common framerate to ensure hybrid discs come out OK.

Edit: also, you might want to check if DGIndex is misreporting with a normal, less-than-100%-Reduction segment. Just encode it straight from DVD-RB and check the reported bitrate against the vbr_brate_avg value.

Edit 2:Testing the .M2V created from an ENCODE phase might not be enough: you might have to complete REBUILD phase and then demux the .M2V. Then compare it against the original .M2V (demuxed from the source disc.)

Sharc
21st June 2007, 22:52
I just did your "Edit1" and found no discrepancy ....

I also made a comparison between the *.VOBs of the original and the REBUILD (assuming that DGIndex reports the video bitrate and not the muxed bitrate).

Edit: Mmmm..., I was probably using version RB-Opt v0.30 or 0.31 in this case. Could be that the reduction has not yet been implemented in the earlier versions..... Sorry for the confusion.

robot1
21st June 2007, 23:35
Thank you for your tests.
I've found the bug: there is a line of code in which i set the bitrate without checking for the max. I'm testing right now, and will post a new version tomorrow.

Sharc
21st June 2007, 23:38
Thanks robot1. No hurry. Time to go to bed now .....

Sharc
22nd June 2007, 23:39
RB-Opt v0.32b:
The max_reduction is reset to 100 each time I restart RB-Opt, means the setting in the RBOpt.ini is not permanent. Is this so by intention?

The DVD Estimated Size under Global Options seems to be wrong (too low).

robot1
23rd June 2007, 00:18
RB-Opt v0.32b:
The max_reduction is reset to 100 each time I restart RB-Opt, means the setting in the RBOpt.ini is not permanent. Is this so by intention?

No, it should be saved, and RB-Opt doesn't modify it in my tests.
Probably it's a dumb question, but have you edited the .ini before running RB-Opt?


The DVD Estimated Size under Global Options seems to be wrong (too low).
The DVD Estimated size in Global options is the same reported in the main window. It's an estimate, so it can't be exact, but I'd like to receive feedbacks on the final size of the encoded project.

Sharc
23rd June 2007, 00:39
Probably it's a dumb question, but have you edited the .ini before running RB-Opt?
At least I thought so. I will doublecheck next time.....


The DVD Estimated size in Global options is the same reported in the main window.
Hmm... I don't get any size info in the main widow since v0.30 or so (?)
In the Global options I get 1609769 sectors. I noticed this "undersize" before, but the final size came out correctly(about 2245000).
Anyway, I will wait for the current encode to finalize.

kumi
23rd June 2007, 01:31
I've noticed this discrepancy also. Three examples (these are values reported by both programs):

Encode DVDRB DVDRB RBOpt RBOpt
Type Size Compression% Est. Size Compression%
-----------------------------------------------------
VBR 4.32GB 67.9% 4.30GB 100%
RBOpt 4.18GB 65.5% 4.16GB 96.46%

VBR 4.32GB 67.9% 4.30GB 100%
RBOpt 4.26GB 66.9% 4.24GB 98.51%

VBR 4.32GB 52.7% 3.56GB 100%
RBOpt 4.32GB 52.7% 3.56GB 100%


I'm still waiting for my encodes to finish so I can say whether the size is actually misreported or not.

Sharc
23rd June 2007, 07:20
Here my final results:
DVD-RB in Editor Window: 4.34 GB (= 4444 MB)
RB-Opt in Global Options: 3184 MB, 1609769 target sectors
NERO burning: 4448 MB

So the final size of the encode was perfect.
The error seems to be in the RB-Opt reporting.

Sharc
23rd June 2007, 08:21
@robot1:
Suggestion: The "min_redist_frames=" parameter (or a similar one) should perhaps also be applied to the Q estimation. Otherwise very few frames may be grabbed from small VOB-IDs for the Q estimate.

robot1
23rd June 2007, 09:48
@robot1:
Suggestion: The "min_redist_frames=" parameter (or a similar one) should perhaps also be applied to the Q estimation. Otherwise very few frames may be grabbed from small VOB-IDs for the Q estimate.
It's a good suggestion. I will correct this.

RB-Opt in Global Options: 3184 MB, 1609769 target sectors
NERO burning: 4448 MB


Could you send me the rebuilder.inf and rebuilder.ecl (and, if changed, also the .original) to my email? The email is in the readme file.


I've noticed this discrepancy also. Three examples (these are values reported by both programs):


Encode DVDRB DVDRB RBOpt RBOpt
Type Size Compression% Est. Size Compression%
-----------------------------------------------------
VBR 4.32GB 67.9% 4.30GB 100%
RBOpt 4.18GB 65.5% 4.16GB 96.46%


I'm not sure about the second row. In the first one you report the size estimated by DVD-RB and RBOpt. What is in the second one?

kumi
23rd June 2007, 18:49
Sorry, that chart wasn't very clear. The first row are the reported sizes of a D2VAVS created straight from DVD-Rebuilder in VBR mode. The second row are the reported sizes of the same D2VAVS after redistributing bitrates in RBOpt.

I finally finished three test projects. I used a PREPARE phase in DVD-RB, then RBOpt to redistribute bitrates. Then I recorded the estimated sizes in DVD-RB and RBOpt.
Estimated Estimated Actual
Size in Size in Size of
DVD-RB RBOpt Output
-------------------------------
4.18GB 4.16GB 4.18GB
4.26GB 4.24GB 4.26GB
4.32GB 3.56GB 4.32GB

It seems that DVD-RB reports final sizes more accurately than RBOpt, in line with what Sharc was experiencing.





Something I'm regularly encountering with redistribution, in ProCoder and HC projects, is a chronic undersizing of the output. In the above table, you can the size of the first project was 4.18GB. I've even seen one ProCoder project come out to 4.07GB.

In none of these cases was the encoder saturated, so I guess the reason is the lack of granularity of the Q scale? ProCoder CQ seems to be especially flaky in this regard.

Since you're on a roll, robot1, I would like to request a fix for the undersizing issue ;) Maybe RBOpt could do something like this:

1/ Before redistribution, RBOpt estimates size. For example: 4.32GB.
2/ User initiates redistribution on some segments.
3/ RBOpt calculates the final output size is now less than 4.32GB.
4/ RBOpt increases the redistributed segments' bitrates by a certain percentage, to bring the estimated size back to 4.32GB.

Sharc
23rd June 2007, 19:54
@kumi:
The reason for my "undersizing" could be traced to my preprocessing: Removing of Extras, and 25% reduction on the remaining Extras which RB-Opt didn't account for correctly.
A cosmetic reporting problem only. as it did not affect the final size of the encode. Robot1 is going to fix it.

kumi
23rd June 2007, 20:19
Yes I understand. For me, RBOpt reports too-low "Estimated Size" values with 00% Steal Space settings, and no preprocessing. But yeah, you're right: it doesn't affect actual output size.

But apart from that cosmetic problem, there is the other undersizing issue in my last post, that does result in actual undersized output. Have you ever seen one of your redistributed projects come out undersized?

robot1
23rd June 2007, 20:22
The size estimation routine in RB-Opt was written many versions ago, and it should work well with the free version of DVD-RB.
Nowdays, with DVd-RB Pro, it's clear that the size estimation is worse than the one in DVD-RB (I'm working to fix it), but, as mentioned by Shark, it's an'estetical problem.
The internal routines don't take that size in account, but the Total Video Size %, which should always be 100 and is related to the DVD-RB calculated output.

The undersizing problem could be caused by the reduction going over 100% in redistribution.
Could you check in Rebuilder.inf if there are segments with Src_Video_Sectors lower than Video_Sectors?
If this case applies, the new version should take care of that problem.

Boulder
24th June 2007, 15:24
Would it be possible to have the CQ_BFACTOR and CQ_PFACTOR options in the redistribution phase? It would be useful IMHO, since the normal 2-pass encode usually shows that I- and P-frame quantization is nearly the same while the B-frames have a somewhat higher quantizer, the multiplier being usually 1.5-2.0.

robot1
24th June 2007, 15:27
Would it be possible to have the CQ_BFACTOR and CQ_PFACTOR options in the redistribution phase? It would be useful IMHO, since the normal 2-pass encode usually shows that I- and P-frame quantization is nearly the same while the B-frames have a somewhat higher quantizer, the multiplier being usually 1.5-2.0.No problem to add those parameters.
What should be the default values, according to your experience?

Boulder
24th June 2007, 15:32
I would probably use 1.05 for PFACTOR and 1.6 for BFACTOR, they are close to what I've seen lately. The actual ratio depends a lot on the material but I'd say these ones are from an average encode.

kumi
26th June 2007, 00:21
I have 2 requests for future RBOpt versions, I hope you can consider them:


First:
Add a no_reencode_threshold directive to rbopt.ini. So, for example, if rbopt.ini contains no_reencode_threshold=95, any segment with a calculated redistributed bitrate of 95% or more would have Action=3 set in REBUILDER.INF. no_reencode_threshold=0 would disable this feature.


Second:
Provide a way to export (and import) a project's segment bitrates. I ask for this because calculating redistribution with ProCoder 2 is a dicey affair. Sometimes the redistributed bitrate values are very different to those calculated with HC or CCE (or QuEnc, apparently (http://forum.doom9.org/showthread.php?p=1018585#post1018585)). It would be helpful if we could redistribute bitrates with HC/CCE/QuEnc, change the DVD-Rebuilder project type to ProCoder, and then apply the previously calculated values with RBOpt. A possible workflow would be:

1/ Run a PREPARE phase (VBR) in HC Mode.
2/ Redistribute bitrates in RBOpt.
3/ Use the new "Export bitrates" RBOpt function.
4/ Switch the DVDRB Mode to ProCoder, and re-run PREPARE phase.
5/ Use the new "Import bitrates" RBOpt function with the file created from step 3/.

AFAIK, you could probably pull this off by recording just four variables from the .ECL/.INF files:

vbr_brate_avg
Action
Reduction
Video_Sectors

Fishman0919
26th June 2007, 01:12
I have 2 requests for future RBOpt versions, I hope you can consider them:


First:
Add a no_reencode_threshold directive to rbopt.ini. So, for example, if rbopt.ini contains no_reencode_threshold=95, any segment with a calculated redistributed bitrate of 95% or more would have Action=3 set in REBUILDER.INF. no_reencode_threshold=0 would disable this feature.


Second:
Provide a way to export (and import) a project's segment bitrates. I ask for this because calculating redistribution with ProCoder 2 is a dicey affair. Sometimes the redistributed bitrate values are very different to those calculated with HC or CCE (or QuEnc, apparently (http://forum.doom9.org/showthread.php?p=1018585#post1018585)). It would be helpful if we could redistribute bitrates with HC/CCE/QuEnc, change the DVD-Rebuilder project type to ProCoder, and then apply the previously calculated values with RBOpt. A possible workflow would be:

1/ Run a PREPARE phase (VBR) in HC Mode.
2/ Redistribute bitrates in RBOpt.
3/ Use the new "Export bitrates" RBOpt function.
4/ Switch the DVDRB Mode to ProCoder, and re-run PREPARE phase.
5/ Use the new "Import bitrates" RBOpt function with the file created from step 3/.

AFAIK, you could probably pull this off by recording just four variables from the .ECL/.INF files:

vbr_brate_avg
Action
Reduction
Video_Sectors

Correct me if I'm wrong... but one of big benefits to redistribution is using the info provided by the encoder for that movie... see how that encoder deal with the video... if you are using HC,QuEnc or CCE to get the info. Who's to say that would be how Procoder would deal with it. Would it real be any benefit?

Just my 2 cents

kumi
26th June 2007, 02:29
I'm asking for the second feature because I get wierd filesizes sometimes in ProCoder CQ mode. My comparisons with HC and CCE on a few redistributions have shown ProCoder (@ Q=1) always results in wilder bitrate swings. I can live with that, and perhaps that's just the optimal configuration for ProCoder. But in one my projects, a segment resulted in an extremely low bitrate; completely different from HC and CCE. And sure enough, it looked like crap. I'll make sure and post an example next time I encounter this.

I just don't trust CQ mode. I would rather live with marginally suboptimal bitrate distributions, that occasionally encounter a segment with extremely high or low bitrates.

Boulder
26th June 2007, 03:23
It shouldn't matter whether you use CCE, HC or QuEnc to do the redistribution as Sharc had noticed in his tests. In fact, when I do the redistribution manually (when dealing with my DVB captures), I use CCE for doing the redistribution pass and then HC for the final encode. The reason why I do this is that CCE is somewhat faster which will save me some time.

robot1
26th June 2007, 18:19
RB-Opt v. 0.33 beta (http://www.savefile.com/files/843117)

Changelog:
Better Size estimation with DVD-RB Pro
Fixed the max_reduction setting in RBOpt.ini
Added HC_PFACTOR (default 1.00 - suggested 1.05) and HC_BFACTOR (default 1.00 - suggested 1.6) options for HC through RBOpt.ini
Used the min_redist_sample value also in Q search phase (to avoid bad predictions on very small VobID)

robot1
26th June 2007, 21:21
I have 2 requests for future RBOpt versions, I hope you can consider them:

First:
Add a no_reencode_threshold directive to rbopt.ini. So, for example, if rbopt.ini contains no_reencode_threshold=95, any segment with a calculated redistributed bitrate of 95% or more would have Action=3 set in REBUILDER.INF. no_reencode_threshold=0 would disable this feature.

I could add a no_reencode_threshold, acting in this way:
if the segment reduction is over the threshold, and there are no filters (the .avs is standard), I could set it as No reencode in the rebuilder.inf


Second:
Provide a way to export (and import) a project's segment bitrates. I ask for this because calculating redistribution with ProCoder 2 is a dicey affair. Sometimes the redistributed bitrate values are very different to those calculated with HC or CCE (or QuEnc, apparently (http://forum.doom9.org/showthread.php?p=1018585#post1018585)). It would be helpful if we could redistribute bitrates with HC/CCE/QuEnc, change the DVD-Rebuilder project type to ProCoder, and then apply the previously calculated values with RBOpt. A possible workflow would be:

1/ Run a PREPARE phase (VBR) in HC Mode.
2/ Redistribute bitrates in RBOpt.
3/ Use the new "Export bitrates" RBOpt function.
4/ Switch the DVDRB Mode to ProCoder, and re-run PREPARE phase.
5/ Use the new "Import bitrates" RBOpt function with the file created from step 3/.

AFAIK, you could probably pull this off by recording just four variables from the .ECL/.INF files:

vbr_brate_avg
Action
Reduction
Video_Sectors
It's a complex process. I'd use a
redistribuite_with_HC
(or redistribuite_with_QuEnc)
switch in RBOpt.ini
If the switch is on, and the encoder is CCE Basic or Procoder (and possibly QuEnc and AQE), it uses HC for redistribution.
I'd use HC because I think it's CQ mode is better than the QuEnc one.
Feedback welcome.

kumi
26th June 2007, 21:57
I could add a no_reencode_threshold, acting in this way:
if the segment reduction is over the threshold, and there are no filters (the .avs is standard), I could set it as No reencode in the rebuilder.inf

Hmm, my DVD-RB Filter Editor is always populated with #comments and P:, I:, E:, F: conditionals. Not all of the PREPARE phase .avs files would have filters applied, but they would still have extra lines added to them. If there's no work-around for that it's no big deal, I think what you suggested would be fail-safe.



I'd use a redistribute_with_HC (or redistribute_with_QuEnc) switch in RBOpt.ini

I hesitated to ask for something like that, since I thought it would cause you too much work to switch all the different parameters in the .ECL/.INF files.

I also thought of asking for RBOpt to automatically "remember" the last set of bitrates after clicking "Save Settings". And then having an additional function to "Restore Last Bitrates". IMHO that might be more flexible than an rbopt.ini setting.

kumi
26th June 2007, 22:12
A silly question: in the OPV Prediction window, what is the purpose of the "Check Quality" and "Save" buttons? They always seem to be grayed out and inactive.

Oh, and what is the "Safety Margin" for? :stupid:

Sharc
26th June 2007, 22:38
Check Quality:
You can watch the encoded sample and then decide to go ahead - or not - with the OPV encode.

edit: ... and did you enter the path for the Media Player in the Setup?

Safety Margin:
You can set it to 1% or so if you are afraid of possible OPV oversizing :devil:

Sharc
26th June 2007, 23:21
.... Add a no_reencode_threshold directive to rbopt.ini.....
Just for my understanding: Is there another reason for this apart from saving time?

kumi
26th June 2007, 23:54
Ahh... I forgot about the media player path setup. Thanks.


Is there another reason for this apart from saving time?

Well, that is my main concern. Especially if robot1 can code it in a manner that avoids the tedious process of adjusting a bunch of segment bitrates downwards to meet the TargetSectors value after nudging certain segments up to 100% (i.e. no re-encode.)

robot1
27th June 2007, 20:39
Hmm, my DVD-RB Filter Editor is always populated with #comments and P:, I:, E:, F: conditionals. Not all of the PREPARE phase .avs files would have filters applied, but they would still have extra lines added to them. If there's no work-around for that it's no big deal, I think what you suggested would be fail-safe.
It's easy to ignore comments.
A standard .avs should have only:
comments
loadplugins
mpeg2source
trim
converttoyuy2
AudioDub(BlankClip())
If there are other filters, than the clip has to be encoded.




I'd use a redistribute_with_HC (or redistribute_with_QuEnc) switch in RBOpt.ini

I hesitated to ask for something like that, since I thought it would cause you too much work to switch all the different parameters in the .ECL/.INF files.

I also thought of asking for RBOpt to automatically "remember" the last set of bitrates after clicking "Save Settings". And then having an additional function to "Restore Last Bitrates". IMHO that might be more flexible than an rbopt.ini setting.
It's much easier my solution... really simple to implement (and I think solves the problem with the encoders unable to perform a CQ encoding).


Well, that is my main concern. Especially if robot1 can code it in a manner that avoids the tedious process of adjusting a bunch of segment bitrates downwards to meet the TargetSectors value after nudging certain segments up to 100% (i.e. no re-encode.)
(When there are no bugs) the program always adapts the size of the other segments (set as "Autosize"), to meet the TargetSectors.

kumi
27th June 2007, 21:08
You're the boss :) Any way you choose to implement redistribute_with_whatever would be very much appreciated. Thanks for listening.

Oh, call me stupid... I just discovered last night what Autosize does. :p Duhhh...

I still think a no_reencode_threshold, and/or a "No Reencode" checkbox in the GUI would be useful.

Sharc
28th June 2007, 19:13
In he standard script the mpeg2source() is presently not editable in order to protect it from unintentional changes.
Could it be made editable (as an option), for example to allow insertion of the cpu=x parameter?

robot1
28th June 2007, 22:32
In he standard script the mpeg2source() is presently not editable in order to protect it from unintentional changes.
Could it be made editable (as an option), for example to allow insertion of the cpu=x parameter?
Yes, I had the same issue.
Will be in next version.

Sharc
30th June 2007, 19:38
Thanks, robot1.
It has really been your RB-Opt which has encouraged and enabled me to do all the tests about redistribution and eventually to prove to myself and demonstrate to others the benefit of Boulder's suggestion. :)
:thanks:

dynamis
9th July 2007, 01:30
silly question, but i gotta ask! does this mean that with Bitrate Redistribution i could do less vbr passes, say 2, instead of 3? :) my thinking is some of the calculations of how much bitrate to put where has been done already. or does Bitrate Allocation just determine how much to allow for a particular segment to keep video quality consistent across all segments?

also, since i never seem to know completely how OPV and multi-pass work, i will ask: does it matter that Bitrate Redistribution cannot be done with an OPV encode? i care more about quality than filesize, but if i can save some time..... should multi-pass with Bitrate Redistribution give me better results than OPV in most cases?

thanks robot1, Boulder, Sharc, and others for all your work to make my backups look better!

Boulder
9th July 2007, 11:37
If CCE's adaptive quant matrices feature is enabled, I would use 3 passes, otherwise two. The redistribution feature only redistributes the bits between the different segments, not inside them.

Doing an OPV encode is pretty much the same as doing the redistribution followed by a multipass VBR encode. The difference is that the resulting filesize is accurate with the redistribution, which is usually not the case in OPV encodes.

stereo
9th July 2007, 13:00
@Boulder

Do you mean that if CCEAQM=0, you would use the initial .vaf pass + 2 passes, meaning 3 passes altogether?

Boulder
9th July 2007, 13:01
If CCEAQM=0, I would do vaf+1 pass so the total is two passes. If CCEAQM=1, then vaf+2 passes=3 passes.

stereo
9th July 2007, 13:34
OK, thanks, Boulder.

I normally do 1+3 vbr passes (I almost never use CCEAQM=1), but last night I was playing around with RB-Opt 0.33 (just learning how to use the new features), and like dynamis I was wondering if my normal 1+3 passes hadn't become somewhat overkill.

stereo
9th July 2007, 16:10
Sorry, this is probably a stupid question:

After doing the initial linking of VobIDs in the main (first) window, the Q prediction (second window) and the redistribution passes (third window), I get the message "=== Done. Press OK to save the results. Warning: original bitrates will be overwritten". I then press OK, and the redistribution window closes, sending me back to the first RB-Opt window. My question is: Should I still press "Save settings" or just press "Exit" in this first window?

Boulder
9th July 2007, 17:00
You should save the settings.

robot1
9th July 2007, 17:16
... I get the message "=== Done. Press OK to save the results. Warning: original bitrates will be overwritten". I then press OK, and the redistribution window closes, sending me back to the first RB-Opt window. My question is: Should I still press "Save settings" or just press "Exit" in this first window?
I will change the text for next version.

stereo
9th July 2007, 17:48
OK, thanks both of you.

I figured, I should save, and thats what I did. I just wasn't sure.

So far, the new RB-Opt seems great, but I'll have to do some more testing / viewing to see if the encodes are improved.

dynamis
10th July 2007, 00:50
...The redistribution feature only redistributes the bits between the different segments, not inside them...

so if the total bitrate of VTS 2 (main feature) is 3900Kbps and VTS 2 (extras) is 2400, the total average of each will still be the same, 3900 and 2400? will bitrate go from one VTS to another? i've seen menus and extras come out with higher bitrates after redistribution and started to wonder where that extra bitrate was coming from because the total avg bitrates were now higher. is that normal? is that good? :P

also i was wondering why CCEAQM=1 would need the extra pass. i just read about CCEAQM in another thread. i've never used it before, but if i understand correctly, it can provide better video quality at the cost of compatibility with certain yard sale dvd players :P i'm thinking about using this together with Bitrate Distriburion, so i would like to know how the extra pass help things. thanks.

Boulder
10th July 2007, 03:26
so if the total bitrate of VTS 2 (main feature) is 3900Kbps and VTS 2 (extras) is 2400, the total average of each will still be the same, 3900 and 2400? will bitrate go from one VTS to another? i've seen menus and extras come out with higher bitrates after redistribution and started to wonder where that extra bitrate was coming from because the total avg bitrates were now higher. is that normal? is that good? :PIf both VTSs are included in the same redistribution pass, the average bitrates will change. If they are redistributed separately, the average bitrates will remain the same.
also i was wondering why CCEAQM=1 would need the extra pass. i just read about CCEAQM in another thread. i've never used it before, but if i understand correctly, it can provide better video quality at the cost of compatibility with certain yard sale dvd players :P i'm thinking about using this together with Bitrate Distriburion, so i would like to know how the extra pass help things. thanks.IMHO, the adaptive quant matrices feature needs the extra pass because the first actual pass after the vaf file creation will have a lot of changes in the matrices. I do not think that CCE can do an optimal distribution of matrices in the first pass and do an optimal allocation of bits at the same time. This is why I feel it should be given the second VBR pass - to do some fine adjustments. Also, in some cases when the compressibility of the video is very high, using only one VBR pass causes undersizing which is fixed by a second VBR pass.

dynamis
10th July 2007, 03:52
wow.. thanks Boulder! one last question, if i may, before i try some encodes. in your opinion, should menus or extras be redistributed? i'm thinking it depends... i've only tried calculations on a few movies, but so far i've kinda noticed that movies with lower Q factors seem to give bits to menus and extras and those with higher Q factors seem to take bits away. but then again... i rarely watch extras. i just throw them in if i have room and usually shrink them down with dvd shrink leaving the movie untouched. thank you.

Boulder
10th July 2007, 04:13
I usually uncheck Autosized for all menus and lower their avg bitrates and then do a redistribution pass with all menu-related items selected - or simply use MenuShrink on them.

Using extras in the same redistribution pass as the main movie really depends on your decision, if you rarely watch them, I don't think that it makes much sense to have the extras there. They usually need more bits than the main movie because they are interlaced.

dynamis
10th July 2007, 04:28
i will check out MenuShrink. thanks again, Boulder.

Sharc
10th July 2007, 14:44
IMHO, the adaptive quant matrices feature needs the extra pass because the first actual pass after the vaf file creation will have a lot of changes in the matrices......

I have seen frequent changes of the matrix in standard multipass VBR mode with CCEAQM=1. Did you or anyone experience frequent changes happening in redistribution mode as well? I wonder because the redistribution sets the segment bitrates according the the "Q-plus-matrix combo" and hence I wouldn't expect frequent changes happening during the encode afterwards.
I have so far not been using CCEAQM=1 in redustribution mode at all because I felt that changing the matrix dynamically would somehow conflict with the constant Q idea. So I doubt if CCEAQM=1 will have any benefit- but as I said I have not made any comparative tests.

Boulder
10th July 2007, 15:39
The adaptive quant matrices are not used in OPV mode, and this applies to HC's LUMGAIN option as well. However, I don't think it is a problem to use either option in the multipass encode, I've been using LUMGAIN 4 all the time.

The redistribution just makes the quality equal, the encoder can then decide what to do with the bits. For example, HC's LUMGAIN mode lowers the quant matrices coefficients in darker GOPs whereas CCE apparently makes its decisions based on the amount of motion (not sure though).

Sharc
11th July 2007, 03:10
I understood that CCE switches matrix to a higher bitrate matrix (1/2, 1/4) when the quantization gets very low and encoder runs into saturation. That's why I assumed that CCE would have no reason to switch the matrix after it has done the redistribution based on a fixed Q which would normally not let the quant drop to very low values. Anyway I might have to do some tests later.

Boulder
11th July 2007, 03:29
You may run into saturation even with redistribution. After all, if some segment is allocated less bits, some segment(s) must get those bits that are left over. If the average bitrate is high enough, there is a chance of saturation.

stereo
12th July 2007, 10:56
@Boulder (or robot1)

In your post #697 you write

If both VTSs are included in the same redistribution pass, the average bitrates will change. If they are redistributed separately, the average bitrates will remain the same.

Does this mean that it's possible to

1. adjust bitrates between movie and extras placed in let's say VTS_01 (4.500 Kbps. avg.) and VTS_02 (3.500 Kbps. avg.), just as one would normally do
2. complete a redistribution pass on VTS_01 (excluding VTS_02) (reaching the message "=== Done. Press OK to save the results. Warning: original bitrates will be overwritten")
3. Press OK, but without saving the settings in the main RB-Opt window
4. complete a new redistribution pass on VTS_02 (excluding VTS_01)
5. Press OK + Save settings + close RB-Opt

This method should ensure that

a. the initially adjusted average bitrates in VTS_01 and VTS_02 would be kept at 4.500 and 3.500 Kbps. respectively, while
b. the two separate redistribution passes would optimize the distribution within each VTS, without tampering with theses initially asigned bitrates (4.500 and 3.500 Kbps. respectively)

This would be just perfect. But am I correct in assuming that the above workflow would be possible (and constitute the correct method)?

Sorry for all these long questions...

Boulder
12th July 2007, 11:04
Yes, you are correct. The average bitrates of the two VTS's will remain at what you have set them to. It doesn't matter if you saved the settings between the two redistribution passes, I would save them in case something went wrong in the second redistribution pass (on VTS_02).

stereo
12th July 2007, 11:13
damn you're fast :D thanks a lot!

EuropeanMan
13th July 2007, 16:21
hi guys, my first time posting in this section...

i have been using DVD-RB for nearly 6 months now with CCE...nothing else (meaning, none of the other encoders)...and wish to continue doing so.

many of my movies in my collection are interlaced, TFF...these dVD9s are usually film2pal conversions. i live in the Usa...and these dvd9s are now ntscd..so basically i have interlacing...maybe i am not making any sence yet.

i'm wondering a few things...IF i use

AssumeTFF()
FieldDeinterlace()

will the results become deinterlaced, and what other settings of DVD-RB do i need to change to make sure my end-product is without all those interlaced lines...or is there something better to use filters-wise or settings...

2) on those interlaced films, is it recommended to use LSF for example ? will MT also work in the the aVS filter box...along with setmemorymax(1024)

3) i had used a script to take the frame rate back to 24.975 (no, not above 2 lines...i used leakkernelbob & repal)...but audio was off...is there any solution for this?

4) re: matrices...I'm still reading up on this...my question regarding this...is there a general place (ie: avisynth.org where u can get all the filters) where i can find other matrices that people have come up with?

5) I realise that OPV use comes with the assurity that one will not always atttain 4.35gb...but undersizing will occur when we have high compressibility...so i usually do 3 passes...with filters use for avs...am i correct in thinking OPV is NOT good for this?

thanks in advance for any help...

jdobbs
13th July 2007, 17:21
1. Are these commercial sources?

DVD-RB properly handles telecined sources and you don't have to do anything special. iVTC is something that is only required for "hard telecined" source -- which are very rare.

2. I would never recommend adding AssumeTFF() -- let DVD-RB reproduce it in the same format as the original. If you input from a BFF source and put that line in, your output will be hosed. FieldDeinterlace() should in most cases only be used if your primary playback device is going to be a PC.

3. ???

4. You'll find almost all of theim posted in this forum in one place or another. Rockas' RME includes a bunch, I think.

5. My recommendation is to use multiple passes in pretty much every circumstance.

manono
13th July 2007, 17:37
Hi-
i'm wondering a few things...IF i use

AssumeTFF()
FieldDeinterlace()

will the results become deinterlaced
Yes, and it's a very bad idea as you'll make the blending much worse.
2) When I unblend a bad PAL2NTSC conversion, I also sharpen it. And I use SetMTMode(2) with both the RePAL filter and with LSF.
3) If the audio became out of synch, it's not because of the RePAL filter, which gives you video after unblending exactly the same length as the source. Must be for some other reason, like maybe you encoded it incorrectly. You can't use RePAL within DVD-RB anyway, as the framerate changes.
4) They went matrix crazy in the XviD forum a few years back. I don't know why you'd be interested in amateurs' matrix creations, though, when there are so many available off retail DVDs, created by professionals. I know of no place with a collection of good MPEG-2 matrices. HCEnc comes with a big collection of both good and bad ones. And here's LiGH's collection:

http://www.ligh.de/software/qmatrix.zip

5) Perhaps someone else can answer that one.

Edit: jdobbs was faster on the trigger. :)

jdobbs
13th July 2007, 18:52
And I use SetMTMode(2) with both the RePAL filter...
Man, I must be getting out of touch now that I'm working this new (too busy) job. An entire discussion on multithreading support within AVISYNTH has been going on and I've remained clueless.

EuropeanMan
14th July 2007, 08:49
^ yes, i have bought many many indian films...cuz well i like them. so i do cces & hand them over to mom or her friends so they can watch...so yes, commercial sources.

thanks for the answers. i guess i'll leave fielddeinterlace alone... :(

one of these days i'm gonna figure out a way to CCE w/o DVD-RB...just waiting for someone who'll be patient enough to teach me.

tx guys for the answers...i'm sure i'll have more soon.

stereo
14th July 2007, 10:26
so i do cces & hand them over to mom or her friends so they can watch...so yes, commercial sources.

strictly speaking that doesn't belong in this forum

dynamis
16th July 2007, 05:51
maybe i missed it, but are there any issues when using Q=1 with Bitrate Redistribution?
i was calculating an anime disc w/ CCE SP 2.70, AVISYNTH 2.5.6.0 and rb-opt 0.33 beta:

- Reduction Level for DVD-5: 77.5%
- Overall Bitrate : 5,422/4,338Kbs
- Space for Video : 3,841,930KB
- HIGH/LOW/TYPICAL Bitrates: 8,616/400/4,338 Kbs

i had rb-opt determine the optimal Q factor and got a factor of 1:


Bitrate for VTS 4 VobID 1 segment 1: original 4406 - redist. 6129
Bitrate for VTS 4 VobID 1 segment 2: original 4457 - redist. 4596
Bitrate for VTS 4 VobID 1 segment 3: original 4541 - redist. 1582
Bitrate for VTS 4 VobID 1 segment 4: original 3908 - redist. 5121
Bitrate for VTS 4 VobID 1 segment 5: original 3685 - redist. 3244
Bitrate for VTS 4 VobID 1 segment 6: original 3558 - redist. 4708
Bitrate for VTS 4 VobID 1 segment 7: original 4760 - redist. 6462
Bitrate for VTS 4 VobID 1 segment 8: original 4467 - redist. 4787
Bitrate for VTS 4 VobID 1 segment 9: original 4387 - redist. 4630
Bitrate for VTS 4 VobID 1 segment 10: original 4448 - redist. 6240
Bitrate for VTS 4 VobID 1 segment 11: original 3642 - redist. 4202
Bitrate for VTS 4 VobID 1 segment 12: original 3549 - redist. 327
Bitrate for VTS 4 VobID 1 segment 13: original 4994 - redist. 6279
Bitrate for VTS 4 VobID 1 segment 14: original 4403 - redist. 4459
Bitrate for VTS 4 VobID 1 segment 15: original 4412 - redist. 4048
Bitrate for VTS 4 VobID 1 segment 16: original 4461 - redist. 5839
Bitrate for VTS 4 VobID 1 segment 17: original 3735 - redist. 3772
Bitrate for VTS 4 VobID 1 segment 18: original 3589 - redist. 4639
Bitrate for VTS 4 VobID 1 segment 19: original 4805 - redist. 6549
Bitrate for VTS 4 VobID 1 segment 20: original 4344 - redist. 4281
Bitrate for VTS 4 VobID 1 segment 21: original 4456 - redist. 5124
Bitrate for VTS 4 VobID 1 segment 22: original 4401 - redist. 6096
Bitrate for VTS 4 VobID 1 segment 23: original 3832 - redist. 5152
Bitrate for VTS 4 VobID 1 segment 24: original 3904 - redist. 4091
Bitrate for VTS 4 VobID 1 segment 25: original 400 - redist. 193

segment 12's bitrate seemed a bit odd so i tried Q=2:

Bitrate for VTS 4 VobID 1 segment 1: original 4406 - redist. 5804
Bitrate for VTS 4 VobID 1 segment 2: original 4457 - redist. 4237
Bitrate for VTS 4 VobID 1 segment 3: original 4541 - redist. 4699
Bitrate for VTS 4 VobID 1 segment 4: original 3908 - redist. 4785
Bitrate for VTS 4 VobID 1 segment 5: original 3685 - redist. 2809
Bitrate for VTS 4 VobID 1 segment 6: original 3558 - redist. 4348
Bitrate for VTS 4 VobID 1 segment 7: original 4760 - redist. 6126
Bitrate for VTS 4 VobID 1 segment 8: original 4467 - redist. 4418
Bitrate for VTS 4 VobID 1 segment 9: original 4387 - redist. 4216
Bitrate for VTS 4 VobID 1 segment 10: original 4448 - redist. 5875
Bitrate for VTS 4 VobID 1 segment 11: original 3642 - redist. 3900
Bitrate for VTS 4 VobID 1 segment 12: original 3549 - redist. 4868
Bitrate for VTS 4 VobID 1 segment 13: original 4994 - redist. 5905
Bitrate for VTS 4 VobID 1 segment 14: original 4403 - redist. 4073
Bitrate for VTS 4 VobID 1 segment 15: original 4412 - redist. 3681
Bitrate for VTS 4 VobID 1 segment 16: original 4461 - redist. 5500
Bitrate for VTS 4 VobID 1 segment 17: original 3735 - redist. 3406
Bitrate for VTS 4 VobID 1 segment 18: original 3589 - redist. 4173
Bitrate for VTS 4 VobID 1 segment 19: original 4805 - redist. 6203
Bitrate for VTS 4 VobID 1 segment 20: original 4344 - redist. 3898
Bitrate for VTS 4 VobID 1 segment 21: original 4456 - redist. 4770
Bitrate for VTS 4 VobID 1 segment 22: original 4401 - redist. 5732
Bitrate for VTS 4 VobID 1 segment 23: original 3832 - redist. 4862
Bitrate for VTS 4 VobID 1 segment 24: original 3904 - redist. 3727
Bitrate for VTS 4 VobID 1 segment 25: original 400 - redist. 186

the segment in question appears to be the ending credits: a still pictures with credits fading in and out. sounds simple, right?

both sample sizes were 20%. i also tried Q=5 and got 4093. who do i believe~~? :p do i need a bigger sample size or something, or should i always use a Q more than 1 even if it's calculated?

edit: 100% sample with Q=1 got me 304. 100% sample with Q=2, 4717 :confused:

also. if i wanted to use 100% sample size will the calculations take as long as it would take for a nomal OPV encode? (~45 min on this setup) thanks

Boulder
16th July 2007, 06:01
maybe i missed it, but are there any issues when using Q=1 with Bitrate Redistribution?An identical case to yours is being discussed in the "RB v1.26bitrate redistribution" thread in this same subforum. It seems there are some problems with CCE and OPV. One more reason to use HC ;)

if i wanted to use 100% sample size will the calculations take as long as it would take for a nomal OPV encode? (~45 min on this setup) thanksYes, it will take the same amount of time. If you use any filtering, you can disable those for faster performance.

dynamis
16th July 2007, 06:15
wow quick response. thanks Boulder. umm, how do i use HC for Bitrate Redistribution and still encode with CCE?

Boulder
16th July 2007, 06:18
At the moment, you can't do that. You should ask robot1 if he could add the feature, it might be useful to others as well.

Boulder
29th July 2007, 08:59
I have a DVD which is incorrectly detected as progressive by RB-Opt. The whole redistribution phase is done as if the whole DVD was progressive which it is not as you can see from the DVD-RB created ecl file. Some segments are flagged as progressive though, maybe that causes the confusion.

http://www.savefile.com/files/926492

Sharc
29th July 2007, 09:48
Are there any (serious) consequences on the redistribution from that?
I have seen many (PAL) DVDs that are effectiveley progressive, however flagged as interlaced - for whatsoever reason. I think this is normally harmless, whereas interlaced material which is erroneously flagged as progressive - as in your case - may be more critical.

Edit: Well, it probably confuses the filters with i: and p: prefixes in DVD-RB, as I assume that they obey the flags?

Boulder
29th July 2007, 11:56
DVD-RB is correct, there's no problem there. The problem is that in this case RB-Opt does progressive encoding on stuff that is pure interlaced video (and the ecl states progressive=0 in those segments). DVD-RB's internal redistribution encodes correctly, some segments are progressive, some interlaced.

This is one of the few correctly mastered PAL DVDs, the ones that are progressive are actually encoded as progressive and not as interlaced.

Sharc
29th July 2007, 12:44
So if I understand you correctly: Only the sample encodes for redistribution (i.e. Q estimation and distribution profile) are not correctly encoded when using RB-Opt for redistribution. The .ecl for the final multipass encode remains intact, and the final multipass encoding will be done correctly?
If so, is the redistribution profile (bitrates) significanty affected by the incorrect encoding? Or is this just the concern?

Boulder
29th July 2007, 18:02
I didn't let the process run through, I switched to DVD-RB's redistribution for that disc so I don't know what would have happened to the final ecl file. I could check it when the current encode process finishes. Encoding interlaced material as progressive is a big no-no and would have a significant effect in the redistribution. Every field is different from each other whereas in progressive video they are the same. Motion is detected falsely and chroma will take a huge hit.

Sharc
29th July 2007, 19:09
Interesting finding. How did you discover the wrong encode for the distribution pass? Did you analyze the sample .m2v, or was the sample file visually crap when viewing it? Were you on HC or CCE?

robot1
29th July 2007, 19:17
I have a DVD which is incorrectly detected as progressive by RB-Opt. The whole redistribution phase is done as if the whole DVD was progressive which it is not as you can see from the DVD-RB created ecl file. Some segments are flagged as progressive though, maybe that causes the confusion.

http://www.savefile.com/files/926492
Thank you for your report.
I have fixed the problem and will release an update soon.

Boulder
29th July 2007, 19:20
Interesting finding. How did you discover the wrong encode for the distribution pass? Did you analyze the sample .m2v, or was the sample file visually crap when viewing it? Were you on HC or CCE?HC is kind enough to show all the settings during the encode process so I immediately spotted that there's something wrong when I saw that the q prediction was being done as if it was progressive. I actually thought that there would only be interlaced segments as the video is a compilation of concerts and regular video footage and interviews. Then I checked the ecl file and noticed a couple of progressive segments and thought that they might be causing the issue.

@robot1: Thanks :)

robot1
30th July 2007, 20:01
New version:

RB-Opt v. 0.34 (http://www.savefile.com/files/927683)

Changelog:
- It's possible to force the use HC for redistribution in place of other encoders
- In avs editing, now it's possible to edit mpeg2source line (example: to add a cpu= parameter)
- When ignoring filters, also cpu parameter in mpeg2source is ignored
- Added in .ini HC_NoVBV, to disable buffer check in prediction (HC can be much faster - default FALSE = VBV enabled)
- Redistribution log is saved in a textfile - redist.txt
- Base_Q value in prediction changes according to the matrix used (could speed up the process, and could avoid CCE crash)
- Fixed a bug in OPV prediction and Redistribution with cells interlaced and progressive in the same VobID
- Minor cosmetic changes.

As always, feedbacks and bug reports are welcome

Sharc
30th July 2007, 20:24
Thanks robot1.

archaeo
30th July 2007, 22:21
thanks for the 'save log' feature!

blutach
31st July 2007, 00:18
Thanks for the new version robot1. From my tests, I would actually suggest HC_NoVBV default to on.

Regards

Sharc
4th August 2007, 16:41
@robot1:
When redistributed segments exceed the bitrate of the original DVD and are scaled down to 100% (or whatever is specified as max_reduction= ) the final adjustments are not reflected in the redist.txt. The.ecl and the encode are correct, though.
Btw. I like the matrix dependent initial_Q. It greatly reduces - or even eliminates (?) - the risk with the annoying cce bug for custom matrices.

dynamis
10th August 2007, 01:22
- It's possible to force the use HC for redistribution in place of

thanks robot1 for the new features. i have question about the one above. do i have to turn off ConvertToYUY2() everytime i want to use HC for Bitrate Redistribution and still use CCE to encode? the dvd-rebuilder beginner's guide says i should leave it enabled if i am using cce? the cce faq says that there is no version of cce that can natively read read YV12 input. thanks.

Sharc
10th August 2007, 05:25
I had the same issue.
At present you must select "ignore all filters" in RB-Opt in your case. This comments out the "ConvertToYUY2()" line in the script for redistribution with HC.
Rbobt1 is going to fix this with the next release.

dynamis
10th August 2007, 06:19
thanks.

~bT~
30th August 2007, 13:03
Donated after ages of usage! :D

Sharc
11th September 2007, 22:02
@robot1:
I wonder if it would be possible to introduce <HC settings>, similar to <CCE settings> in RB-Opt. In particular I find the selection of matrices very convenient and useful.

kumi
11th September 2007, 22:25
I agree, HC settings would be extremely useful (especially matrix adjustment). Doubly so, since HC appears to be the most popular (http://forum.doom9.org/showthread.php?t=129631) encoder around these parts. :)

blutach
12th September 2007, 09:06
Can I 3rd the motion? - having matrices for HC would just be icing on the cake.

Regards

tom942
12th September 2007, 18:47
Hehe, I asked for that sometime ago, and someone told me that add this kind of settings was a bad idea because it is a unique feature of DVD-RB, but I also support the motion :).

Rippraff
12th September 2007, 23:24
someone told me that add this kind of settings was a bad idea because it is a unique feature of DVD-RB
No, I told you that this is a Pro feature and even Robot1 (http://forum.doom9.org/showthread.php?p=727049#post727049) wasn't sure in the past if adding additional Pro features is a good idea.


Cu Rippraff

Sharc
13th September 2007, 07:01
Well, it would be nice if the Matrix could be changed after the prepare, i.e.when the bitrates are known.
I used this a lot for experimenting with redistribution. Otherwise I would alway have to rerun a prepare from scratch.

robot1
13th September 2007, 07:16
This feature will be added (and will work only with DVD-RB pro version, as it's a pro feature).
I hope to have it ready next week.

Boulder
13th September 2007, 07:25
About setting progressive/interlaced, does RB-Opt also adjust the flags according to what jdobbs says here: http://forum.doom9.org/showthread.php?t=129386. If not, I think that might be a good idea to implement as well ;) I've had to rerun the prepare phase many times just because I've forgotten to set "Disable interlaced" for the main movie.

blutach
13th September 2007, 08:45
Wonderful news robot1.

Thank you

Regards

tom942
13th September 2007, 13:11
@rippraff

I didnīt remember that you told me that :). I understood you that under any circunstance, this feature could not be implemented. BTW, as robot1 said, just checking if we are using free or pro version, then we can use these new features. :).

@robot1

Thank you for the coming version :).

Greetings.

robot1
13th September 2007, 20:25
About setting progressive/interlaced, does RB-Opt also adjust the flags according to what jdobbs says here: http://forum.doom9.org/showthread.php?t=129386. If not, I think that might be a good idea to implement as well ;) I've had to rerun the prepare phase many times just because I've forgotten to set "Disable interlaced" for the main movie.
I'm not sure about the problem.
You have an interlaced video, but flagged (and detected by DVD-RB) as progressive.
What is the problem about just changing the ecl in interlaced (you can do that with RB-Opt) and rebuilding with the original flags (progressive)? You should have the same result of the original DVD (wrong flags, but image ok, as the encoder knows it's interlaced).

dynamis
14th September 2007, 02:00
if i use HC for the Redistribution pass, is the value for "Q Factor" actually HC's CQ value? on one dvd, i get a Q Factor of 14 with CCE and 34 with HC. i know the range of CCE's Q Factor is 1-300. what is HC's range and is there any way to calculate and get an idea of what the CCE value would be? i read the HC manual.pdf but i didn't see what i was looking for. thanks.

robot1
15th September 2007, 00:30
if i use HC for the Redistribution pass, is the value for "Q Factor" actually HC's CQ value?
Yes, it's the CQ value, scaled by 10 (example: for a CQ value of 3.4 you get a 34 Q factor).

on one dvd, i get a Q Factor of 14 with CCE and 34 with HC. i know the range of CCE's Q Factor is 1-300. what is HC's range and is there any way to calculate and get an idea of what the CCE value would be? i read the HC manual.pdf but i didn't see what i was looking for. thanks.
There is no relationship between HC and CCE values.
Anyway I hope you can get a better answer from an HC expert.

Boulder
6th October 2007, 09:55
I found a little something to tweak in the q prediction phase. Currently there is no control in what region the q value is being searched. First RB-Opt may try 79, then jump to 88 and go down to 76 even though 79 was determined to be too low.

robot1
28th October 2007, 18:56
@robot1:
I wonder if it would be possible to introduce <HC settings>, similar to <CCE settings> in RB-Opt. In particular I find the selection of matrices very convenient and useful.

Well, it would be nice if the Matrix could be changed after the prepare, i.e.when the bitrates are known.
I used this a lot for experimenting with redistribution. Otherwise I would alway have to rerun a prepare from scratch.

I'm working right now to add some new feature to RB-Opt.
I would add the matrix selection for HC, but probably it's useless.
At the moment, DVD-RB doesn't read the matrices for HC in the Rebuilder.ecl (as it does for CCE), but it reads the matrices from it's own Rebuilder.ini.
Advantage: you can change the matrix for HC after the prepare phase without running a new prepare from scratch.
Disadvantage: if you prepare a project, than change the option in DVD-RB, you'll find the new option also for the old project.

As far as I know, from my tests, DVD-RB reads from Rebuilder.ecl these parameters with HC:
Progressive/Interlaced flag
Gop Length to use
VBR Max bitrate

I'm waiting for suggestions:
do you think I have to read and write the Rebuilder.ini file?
Is it needed, as it's possible to change the other HC parameters in DVD-RB without running the prepare?

blutach
28th October 2007, 22:20
@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.

Regards

Sharc
29th October 2007, 16:29
I used the CCE Matrix selection of RB-Opt mainly to overwrite the DVD-RB matrices - after the prepare - with one single matrix for Q-analysis, redistribution and encode, or when I simply forgot to select the desired matrices before running the prepare. It was just very convenient to make such changes without running a new prepare.
I was not aware that the HC matrices can be changed from the DVD-RB Options menu without running a prepare from scratch again. So my wish is surely less important, and maybe it's not recommended to tweak the rebuilder.ini for stability reasons.

kumi
29th October 2007, 22:01
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.)