MultiAngle + Rb-Opt OPV = Big Oversize without, like, bigger, count, added

andy

Hi all,

I've got oversize with the movie quot;Hide and Seekquot;. It contains a short multiangle part or interleaving, dunno how to call it. It's like DVD-RB just added it without to take it in count for the compression. For info, I used DVD-RB Free and RB-Opt 0.20. Ah yes, more strange, the output is bigger than the input.

Input : 4.784.496.640 bytes.
Output : 4.935.471.104 bytes.

How could it be ? If you need I upload any file, just let me know, I keep all. Thx.

what preprocessing did you do? the hide and seek dvd is bigger than that

please try it without preprocessing, and as a side note, if all you need to do is cut less than 100mb, dvd shrink is worth a thought

I used DvdRemake Pro as preprocessing to cut down all extras and trailers. For info, I'm PAL user. The PAL version is maybe much smaller than the NTSC one. I know I could use DvdShrink but OPV is fast enough for me and I prefer encoding instead transcoding even the size is small.

@Djan

I just did this one straight across (no preprocessing) using DVD Rebuilder Pro, multi-pass (2 passes CCE), and got good results.

A few things to consider, though...

1)OPV is pretty unpredictable, size-wise.  If you're using CCE and running OVP, check your Rebuilder INI file.  If you've selected any sort of special target sectors (CCETargetSectors=2260000 or the like), delete that line so that Rebuilder can go back to its default output settings.  Not doing this seems to pretty much guarantee oversizing while using the one-pass mode.  

2)The freeware version of Rebuilder doesn't re-encode multi-angle segments.  It leaves these as full-sized.  I would imagine that this would throw off OVP's sizing predictions.

I'd recommend using regular multi-pass methods on this one.  Don't worry about running 4+ passes:  This just wastes time.  If you let it run 2 passes (1 analizing pass + 2 encoding runs) you should get better sizing without taking all that much more time.  Keep in mind that OVP has to run a sample of the video streams -- several times, at that -- to get the optimal Q value for encoding, and this takes time, too.  I shouldn't take much more time to simply run a full encoding pass for improving quality.

oh i didnt even see the dvd-rb free comment

yeah full size ilvu segments are gonna kill you on this

if you upgrade to pro you can blank in rebuilder (avoiding preprocessing) and reencode ilvu.. seems very worthwhile in this case

@writersblock29 :

I didn't touch any SectorTarget. But as I said I think the problem comes from the multiangle. Should Robot1 review his calculatings ? I'll process OPV without RB-Opt Q factor calculating and will check if it's OPV problem or RB-Opt calculating.

Let me know your results.
And, if possible, send me by email reuilder.inf, rebuilder.ecl (modified by rbopt and the original).

Ok, I tested OPV directly from DVD-RB without using RB-Opt and I got big undersize this time.

Before : 4.784.496.640 bytes
After : 4.154.617.856 bytes

So, there is also a problem by DVD-RB for OPV encoding. And always because the small multiangle part. So here is the Rebuilder.inf and .ecl for this test and I'll redo using RB-Opt for Robot1.

Here are the RB-Opt modified inf and ecl files.

single q's can wildly change the file size

maybe with a q of 8 you get 4.1 gb and with 9 you get 4.8, you might not be able to get closer.

Yes I was thinking about this, it would probably happen with small Q's. I'm waiting about answers of respectives creators of the programs, jdobbs and Robot1.


Originally Posted by djanOk, I tested OPV directly from DVD-RB without using RB-Opt and I got big undersize this time.

Before : 4.784.496.640 bytes
After : 4.154.617.856 bytes

So, there is also a problem by DVD-RB for OPV encoding. And always because the small multiangle part. So here is the Rebuilder.inf and .ecl for this test and I'll redo using RB-Opt for Robot1.
I wouldn't call that a huge undersize -- at least not in OPV.  Post the LOG and let me see what Q values it used.  As was mentioned, when you get to the low Q values a single increment/decrement can be the difference between oversized and undersized.   In addition DVD-RB's freeware version does the prediction, it does it without taking the ILVU sections into account because they have to stay intact.

What is the difference (per VTS) in Q size for the RB-Opt and DVD-RB predictions?

DVD-RB finds Q=8 and RB-Opt finds Q=5. It's a big difference for a so small video size reduction of +/- 3%. If DVD-RB doesn't take in count the ILVU parts maybe RB-Opt does it and it's why the Q value is different.

What about to try to encode at a Q=7 or 6 ?

PS : Why moderators don't approve my attachments ? It takes long.

If you look at the REBUILDER log you will probably see that 6 and/or 7 was tried in the prediction and was predicted to oversize.  Either that, or 8 predicted so close that it wasn't dropped.

All DVD-RB can do is sample and predict based upon the output size of the sample.  The only way to ensure exactly the right output size is a 100% sample -- which is what happens in multipass VBR.  All OPV can hope for it quot;close enoughquot; accuracy in exchange for a savings of time.

There are a large group of posts on this subject, including prediction techniques, prediction curves, etc. in the CCE forum.

Another thing you could test:
Edit you Rebuilder.ini =gt; copy the line under [Options]

Code:
Q_sample_percentage=3
I've got pretty good results with 3 percent (default value is 1) but keep in mind that prediction time takes longer.

Cu Rippraff

@djan
I've doublechecked the code in RB-Opt, and I find no errors (RB-Opt doesn't consider the ILVU part).
Anyway, I'll send you a new build to test, and if the results are better, I will post it in the forum.

As you've found, with q=5 (DVD-RB) you have a final size of 3,87 GB, and with q=8 you get 4,60 GB.
Probably with q=6 you still have an undersized result, and with q=7 you still have oversize.
The problem lies in OPV prediction, expecially in the non linearity of the relation between Q and final size.
Could you post the log of DVD-RB and the log of the RBOpt prediction (you can copyamp;paste it from the log windows). I don't know if you enable the double pass in RB-Opt. In case, enable it.

Thank you for all your tests.

Ok, I'll do it as soon as I've time. It's a pleasure for me to test for you.

Here is the DVD-RB OPV log :Code:
[00:04:43] Phase I, PREPARATION started.
- quot;One Pass VBR (w/analysis)quot; mode is enabled.
- VTS_01: 2.333.045 sectors.
-- ANGLE and/or INTERLEAVING is present.
-- Scanning and writing .D2V file
-- Processed 152.975 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 94,7%
- Overall Bitrate : 4.748Kbs
- Space for Video : 3.546.310KB
- Analyzing VTS_01 for optimal Q factor. -- TargetSize (sectors):1.799.752 -- Sampling 1536 of 152975 frames. -- Predicted size (sectors) at Q=22: 896.152 -- Predicted size (sectors) at Q=7: 1.856.190
- Q Value selected:  8
- HIGH/LOW/AVERAGE Cell Bitrates: 6.460/500/4.748 Kbs
[00:12:54] Phase I, PREPARATION completed in 8 minutes.
And here is the RB-Opt OPV analysis log :Code:
=== Running prediction on VTS 1 - VobID 1
--- Initial Q: 21
--- Frames: 137710, target size: 3572002 KB
--- Desired sample size: 107385 KB
--- Pass 1. Waiting for encoder...
--- Testinq Q factor: 21
--- Obtained sample size: 49363 KB (-54.0% error)
--- Pass 2. Waiting for encoder...
--- Testinq Q factor: 4
--- Obtained sample size: 120031 KB (11.8% error)
--- No change in Q for next iteration
--- Overshot, incrementing Q
--- First pass: found Q factor 5
=== Verifying prediction on VTS 1 - VobID 1
--- Frames: 137710, target size: 3574858 KB
--- Desired sample size: 107471 KB
--- Pass 1. Waiting for encoder...
--- Testinq Q factor: 5
--- Obtained sample size: 114159 KB (6.2% error)
--- No change in Q for next iteration
--- Overshot, incrementing Q
--- Second pass: found Q factor 6
*** Using Q factor 5
I hope you'll find something.

DVD-RB predicted that a Q of 7 would have put the output approximately 3% oversized, so it selected 8 as the Q.  Because of DVD-RB's conservative TargetSize value (assuming it is left unchanged), it is possible that a Q of 7 may have fit -- but when in doubt, DVD-RB always chooses the path of caution (to prevent ever having to do the entire encode over again).

Either way -- you are getting exceptional quality when you are seeing Q values that low... so the argument is really just academic.

There is not really a problem with DVD-RB as a small undersize is not a problem, especially with a so low Q value, it's something to not worry.

But the problem is with RB-Opt where I obtain a big oversize because it choosed 5 as Q value, far from DVD-RB for a low Q value. There is then a problem in its prediction. Waiting Robot1.