MVBR one-pass calculation. "A New Approach"
 

I've been busy the last 3 days fiddling with file prediction, and I found something very interesting in TMPEG that we hadn't tried before. Deep in TMPEG, there's an option where you can force TMPEG to encode at a specified average bit rate :!: So basically, it will encode at a specified "Average" instead of a specified "Quality" as we have been encoding. This could be an alternate method, and might be very accurate too. After experimenting with this, I've made some tests, and I'm very surprised at the results and I developed a small calculator with some factors taken into consideration, and here it is with a full explanation :D

First, download this: http://www.kvcd.net/kvcdcalc.exe ( Small, about ~12KB ). Here's a screenshot of the program:

http://www.digitalfaq.com/archives/i.../2003/03/1.jpg

Now Run "SwiftAVS" or "MovieStacker" and create your favorite script as usual.
Now take a look at the suggested average bit rate in MovieStacker.

On the KVCD MVBR Calculator, adjust the top track bar and select your resolution. Then enter the average bit rate that you got from MovieStacker and press "Calculate"

Now here comes the fun part :D :
Open TMPEG and change the encoding mode from CQ to MVBR, and enter the MAX bit rate and MIN bit rate that the calculator gave you in the step above. Make sure you set the P and B spoilage to 0
Here a screenshot of what it should look like:

http://www.digitalfaq.com/archives/i.../2003/03/2.jpg

Next go to TMPEG's "GOP Structure" tab an click on "Force picture setting" and click on the "Settings" right beside it. Like this:

http://www.digitalfaq.com/archives/i.../2003/03/3.jpg

You'll get a screen like this:

http://www.digitalfaq.com/archives/i.../2003/03/4.jpg

Right click on the line that says so :wink:, and you'll get this screen:

http://www.digitalfaq.com/archives/i.../2003/03/5.jpg

Then select "Bitrate" and you get this:

http://www.digitalfaq.com/archives/i.../2003/03/6.jpg

And enter the "New ABR" (New Average Bit Rate) value suggested by the KVCD MVBR Calculator. DO NOT enter the average bit rate suggested by MovieStacker or other programs. The calculator already takes into consideration an offset, which based on my tests, is close to the actual and final average bit rate. So take the number calculated from the "New ABR" field and enter it on the "Set bitrate" field.

You're done :!: Start your encode using "High quality". Read notes below.

Notes:

This is still VERY experimental, and more tests have to be conducted. I have had great results with three movies, one targeting less than 1% final file size, and another one around -6% to -7%. What I did find is that no matter what filters I use, TMPEG compensates and produces the same output file size :D ( At least on the limited tests I have done )
So if this does work for everyone, I can adjust the calculator to take other factors into consideration. For example, I get a different file size if I encode as "High quality" than if I encode as "Motion estimation fast". So version 0.36 of the calculator will add a selector, where you can choose your encoding mode. I just need more people to test this, and if your file size was way off, then tell me here what was the difference from the actual file size to the one suggested by MovieStacker. Also tell me what encoding mode you used. Ex: "Normal", "High quality", 'Fast", etc.

I still have to do some quality comparison between this mode and CQ mode. As far as I can tell looking at my monitor on what I have encoded, It looks the same as my CQ encodes.

Edit:
Please try this ONLY at 352x240(288).
I have not done that many tests with higher resolutions, so the ABR calculations will probably be off.
Edit: Higher resolutions WILL NOT WORK with this method. Use only at 352x240 or 352x288.

Enjoy,
-kwag

Sounds interesting, I´ll try it when I got some time, propably many people will do the same... :D

YEAH! :lol: :lol:
If this works, we can say "bye-bye" to all other kinds of prediction! 8O

Great work kwag!
:ole:

It's working great, but only at 352x240(288). TMPEG tries to keep the bit rate close to average, and doesn't let the bit rate fluctuate too much. It goes up to ~1300Kbps MAX, so it's no good for higher resolutions. However, it's excelent for 352x240(288) 8)
But I'm still working on it's limitations, so let's see if I can take the 352x240(288) cap off and go beyond that :wink:
Right now, this method should work great with KVCD_ULBR and KVCD_LBR, but NOT KVCD 352x240(288) PLUS, because that template is set to MAX=1,800Kbps and that bit rate will never be reached.

-kwag

Kwag

Let see if I can follow using my best principal (KISS) and believe me this is the only I can follow. If I go beyond that I’m lost. For those that don’t know KISS – Keep It Simple Stupid ----Is what I use. An I keep telling myself to use the KISS system.

First I run the d2v through Moviestack, create the avs (I always start with the default templates). Then I get the average bit rate (My test gave me 880).

The rest I can follow. Now my question is after I set up TMPGEnc, I’m assuming that it will adjust the bit rate based on the template. So with this procedure I no longer have to worry about what the CQ is going to be.

I hope I got this right. I am running a test now on a 110 Min movie. Will keep you posted on the results. This jsut keeps getting better all the time.

Bud

I use the same principle too :lol: So far, so good, but you must load the KVCD_LBR template for this method, or any other 352x240 template only. Not higher resolutions. Not exactly!. You have to set the bit rates and the average bit rate that you get with the KVCD calculator in TMPEG. You don't use the default bit rates that are on the template, and you must change the encoding in the template from CQ to MVBR as in the screenshot. Almost 8O :)

-kwag

Kwag,

why don't use the 480x480 feature?

thanks in advance!

Kwag

Thanks...Hey at my age almost if good enough for me (I almost hit the toilet every time, at least that’s what my wife tells me).....looking forward to more testing....with the movies not the toilet......


Bud

It only works with 352x240(288)

-kwag

hi again,Kwag :wink:

yes,but the control jump from 352x240 to 528x480 and no to 480x480.
in the future you don't want to use this resolution? :?

:?:

Only if we're able to make this method work at higher resolutions :wink:

-kwag

of course you can do it .
this forum make miracles!
:wink:

Yea, and Im always <<Watching>> :wink:

OK... i have tried this with 2 Samples.
Both at the resolution 352x288.
Motion search precision: slow

The samples are a little smaller then predicted. 11,25MB:10,3MB and 11,06MB:10,8. But it seems to me that the MVBR gives me a better quality. Trying now on the complete movie.

Edit: finish. MVBR Calculator is not really hitting ABR. But you can use the Sampler() to be sure. So it is not a replacement for the predicting stuff. MVBR produces more "striped" blocks

Hey... what happend... hasn't anybody other tried it yet?
Maybe i am wrong...
Last year i tried this MVBR. I used standard Matrix and "force picture type setting". I needed almost the same time to set the pictures as TMPGEnc needed to encode :lol: But the result was really amazing. It was really like a DVD 8O

Hi alfredini,

The problem with MVBR and the method I describe here, is that TMPEG clamps the MIN and MAX fluctuations close to average. But it's not wide enough to go to a high MAX on action scenes. So fast scenes look blocky. I haven't found a way around it, so we might as well stick to CQ with file prediction. Nothing beats that yet :D

-kwag

hay kwag..

looks like nothing will ever beat CQ :wink:

Personall, I love using it. Thanks to you. And, in my best opinion,
CQ is as good as multi-pass (if bitrate min/max/CQ) are properly setup
for the encode. I can't ever see myself going back to 2-pass, though
I reailly used it, because I used to use CQ_VBR 8O though it's good too.

Well, that was me beafing.
-vhelp

Can this predict the final mpeg size? Be nice to know before you start encoding,also can this work within Tok?

Hi ezysk,

This method (and old thread!) worked "so so", but only at 352x240. It was an experiment, and didn't work very well. There's nothing like CQ encoding. At least not yet :wink:

-kwag

..problem is, there's a variety of prediction methods and tools on this site,so I was just kind of wondering,what and where would be the best place to start for a beginner like me 8O