Question: one-pass-vbr

[ffreese]

just a stupid question:

why des RB try to calculate the Q-factor for all VTS at one time?

would´nt it be better to get Q-factor for the biggest VTS first, then reencode this vts and the recalculate the left sectors for the other vts?

maybe you could do a mixed-mode, where only the last VTS could be done in multipass-vbr to hit the target exactly?

would be a nice feature at least for the pro-version.

[onesoul]

Each VTS/Cell has its own q-factor calculation and they are based on the available bitrate to each VTS/Cell.

[ffreese]

Originally posted by onesoul
Each VTS/Cell has its own q-factor calculation and they are based on the available bitrate to each VTS/Cell.

thats right. but if vts is over- or undersized you could compensate this by correcting target-sectors...

old target sectors - already used sectors = new target sectors for the following vts / cells...

[onesoul]

The objective of q-factor prediction is to achieve the desired avg. bitrate, and it works well.
I don't think there's need to implement what you suggest, which probably wouldn't work that well or make any difference, imagine that the last vts was a small one or that there was only one vts.

Select multipass if you want accurate final size.

[mrslacker]

@onesoul

I find ffreese's idea to be rather efficient, and clever. As the saying goes, OPV is like measuring with a micrometer and cutting with an axe. Unless you up your sample percentage to 100%, the q-factor prediction and the resulting OPV encode won't be perfect (edit: predictable). So, why not calculate each sequential VTS's q-factor after you have either over- or under-swung that metaphorical axe?

The processing time would be the same, but accuracy could potentially be improved. This would especially be the case if there are two or more VTSs for which the original (proportional split sector basis) q-factor guesses are not accurate. After the first of them are encoded, with possibly a less than ideal Q, a compensation would be made in estimating for the next VTS.

This would help to produce more accurate results, avoiding both under- and over-sized outputs, on occasion... those admittedly rare occasions.

Why would this approach not "work that well"? If there is one VTS, no problem. If there is a small VTS (but not small enough to be excluded from encoding), still no problem.

[onesoul]

@ mrslacker

I don't think what you are saying is the same ffreese suggested, which was to do multipass on last vts if predicted size was way off.

Anyway your new idea is interesting and it would probably work.
So the idea is to do q-factor prediction after each encode based on the available space.

[jdobbs]

Just a correction here... DVD-RB doesn't do Q predictions by the CELL -- it does it by an entire VTS. Q isn't like bitrate -- it is a bad thing for it to change between cells... you want consistency in quality across an entire movie.

I think there are people who are too worried about pushing the size out to the edge of the disc. As in an example I saw a while back, if you have a Q of 1 and are at 3.6GB -- making it 4.32GB isn't going to improve anything, it will only make it bigger.

[jdobbs]

By the way, I've already been considering moving Q prediction to the encode phase. Right now I have a problem when trying to use the Segment Editor/Viewer with OPV -- because the prediction is done before you get there, and I hesitate to do a prediction each time you save any changes from the editor.

[mrslacker]

Originally posted by jdobbs
I think there are people who are too worried about pushing the size out to the edge of the disc. As in an example I saw a while back, if you have a Q of 1 and are at 3.6GB -- making it 4.32GB isn't going to improve anything, it will only make it bigger.
This guy (http://forum.doom9.org/showthread.php?s=&postid=650764#post650764) reported 3.1GB for the main VTS with Q=1 and 3.7GB overall! Maybe that's the one you were referring to, maybe not, but your point is well taken!

Although, with demanding content, I don't think a couple hundred MB are always that trivial. I hope I'm not making your life difficult, especially since I haven't qualified my claims or quantified the gains. For picky, obsessive people like me, tweaking TargetSectors, min_vts_size, Q_sample_percentage (when applicable), etc. can be worth the time. It's part of the fun too. I have been trying (http://forum.doom9.org/showthread.php?s=&postid=651787#post651787) to tag disclaimers onto what I say! :)

[ffreese]

Originally posted by onesoul
@ mrslacker

I don't think what you are saying is the same ffreese suggested, which was to do multipass on last vts if predicted size was way off.


This was exactly, what I suggested in my first part.

The "mixed mode" is a second suggestion, which maybe makes sense, when you have at least 75 percent in the main vts and less than 25 percent in extras-vts.

[mrslacker]

That really is just a trick to push the size to the edge, as you're only talking about helping the last?/smallest? title, not the main movie. On the other hand, you would save loads of time on the large title. Still, this requires the titles to be processed out of order. That could be in order of size, largest first. Or alternatively, processing of the OPV title(s) first.

Perhaps there is something to an adaptive OPV encoding strategy, or even hybrid OPV/multipass. But first things first: Unless DVD-RB does Q prediction during the encode phase, this is all academic.

[mrslacker]

Originally posted by jdobbs
Right now I have a problem when trying to use the Segment Editor/Viewer with OPV -- because the prediction is done before you get there, and I hesitate to do a prediction each time you save any changes from the editor.
Oh yeah. I haven't tried to use the Segment Editor after an OPV prepare. That is a tricky situation.