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

[Sharc]

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]

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]

@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]

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]

damn you're fast :D thanks a lot!

[EuropeanMan]

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]

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]

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]

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]

^ 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]

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]

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]

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]

wow quick response. thanks Boulder. umm, how do i use HC for Bitrate Redistribution and still encode with CCE?

[Boulder]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Thanks robot1.

[archaeo]

thanks for the 'save log' feature!

[blutach]

Thanks for the new version robot1. From my tests, I would actually suggest HC_NoVBV default to on.

Regards

[Sharc]

@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]

- 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]

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]

thanks.

[~bT~]

Donated after ages of usage! :D

[Sharc]

@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]

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]

Can I 3rd the motion? - having matrices for HC would just be icing on the cake.

Regards

[tom942]

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]

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]

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]

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]

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]

Wonderful news robot1.

Thank you

Regards

[tom942]

@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]

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]

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]

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]

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]

@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]

@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]

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]

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.)