PDA

View Full Version : OPV with DVDRB 1.09.2


SAPSTAR
13th April 2006, 21:58
hi,

I would like to have a small explanation (if possible) on the algo used by DVDRB to find the proper Q value in OPV. Because I found it a bit "strange" :
- Overall Bitrate : 2,914/2,331Kbs
- Space for Video : 3,377,788KB
- Analyzing VTS_01 for optimal Q factor.
-- TargetSize (sectors):221,075
-- Sampling 1500 of 49968 frames.
-- Predicted size (sectors) at Q=58: 219,843
- Q Value selected: 58
- Analyzing VTS_03 for optimal Q factor.
-- TargetSize (sectors):84,141
-- Sampling 675 of 22225 frames.
-- Predicted size (sectors) at Q=68: 74,774
-- Predicted size (sectors) at Q=56: 124,940
-- Predicted size (sectors) at Q=96: 60,322
-- Predicted size (sectors) at Q=46: 184,422
-- Predicted size (sectors) at Q=125: 57,923
-- Predicted size (sectors) at Q=41: 215,977
-- Predicted size (sectors) at Q=133: 49,460
-- Predicted size (sectors) at Q=10: 332,887
-- Predicted size (sectors) at Q=50: 160,067
-- Predicted size (sectors) at Q=116: 59,130
- Q Value selected: 68
- Analyzing VTS_06 for optimal Q factor.
-- TargetSize (sectors):21,396
-- Sampling 165 of 5054 frames.
-- Predicted size (sectors) at Q=60: 18,851
-- Predicted size (sectors) at Q=49: 30,804
-- Predicted size (sectors) at Q=80: 11,109
-- Predicted size (sectors) at Q=15: 69,239


For the VTS_03, I would have expected it to try some values between 68 and 56, because 56 is too big and 68 too small...so why is it trying values outside this range?! Then same thing for the VTS_06.....
It's like if it doesn't keep a track of the previous attempts but just the last one ?!

jdobbs
14th April 2006, 14:24
The prediction is based on a sizing curve that is applicable to CCE's OPV method. I did that to keep the number of required passes to a minimum. If you do a simple binary search it takes way too many passes and reduces the payback for using OPV. With the curve it averages about 3.

I had to modify the routine a lot for HC because it uses a CQ. I assume you are using AutoQMatEnc in the CCE path? That probably has a different sizing curve that is more similar to HC.

SAPSTAR
14th April 2006, 15:06
The prediction is based on a sizing curve that is applicable to CCE's OPV method. I did that to keep the number of required passes to a minimum. If you do a simple binary search it takes way too many passes and reduces the payback for using OPV. With the curve it averages about 3.

I had to modify the routine a lot for HC because it uses a CQ. I assume you are using AutoQMatEnc in the CCE path? That probably has a different sizing curve that is more similar to HC.
Hmmm OK I see....thank you. You're right, AQE is closer from that point of view to HC than CCE. Maybe I could try to emulate it?! Could somebody tell me the behaviour of CCE in regards to that?!

jdobbs
14th April 2006, 19:27
Actually it would be better just to wait until I release the next version. Since it includes inherent AutoQMatEnc support (as you're aware) I can adjust it. I hadn't thought of this before -- so I'll have to go back, look at it, and customize it a little.

jdobbs
14th April 2006, 19:37
One question... does AutoQMatEnc actually use the value passed as a CQ value -- or does it convert the Q value to a CQ?

danpos
14th April 2006, 20:19
Since it includes inherent AutoQMatEnc support .

Cool!!:cool: It's really a great news. Well done, JDobbs! :)

Keep up the excellent development.

Cheers,

techmule
15th April 2006, 14:31
Actually it would be better just to wait until I release the next version. Since it includes inherent AutoQMatEnc support (as you're aware) I can adjust it. I hadn't thought of this before -- so I'll have to go back, look at it, and customize it a little.

That should be good to provide inherent support for AQM enc.

When do you plan a new release and will the changes be done for both ver of DVD-RB ???

jdobbs
15th April 2006, 21:57
I've added it already the Pro version -- I hadn't thought about the freeware. The Pro version should be out soon. I've been spending a quite a bit of time analyzing sources and writing code to recognize garbage in the original streams (causing "Error #0006, framecount differences") and circumvents it where possible. As soon as I have that working to my satisfaction, I'll release v1.09.3.