DVD-RB free with OPV, HC Enc and you

[techreactor]

I did some tests with OPV, since OPV can save upto 2-3 hrs (after deducting CQ prediction time) for a 2 hrs movie. Usually a 2-pass with same settings can take more than 6 hrs to encode.

I used :

GetCQ for CQ prediction value
HCenc in BEST mode
Configured HCenc to use OPV
Kept 2 audio's AC3 + DTS and English Subtitles.
Movie length : 2 hrs 11 min
Time taken for encode: 163 min
HIGH/LOW/AVERAGE Cell Bitrates: 4,753/786/3,249 Kbs

See the results for yourself and Judge:

















EDIT: I got an encoded size of 4.31 GB (thats a major concern for ppl using OPV, since accuracy is always a problem), but the trick is to calculate the sizes properly (audio, mux) when feeding GetCQ.

[BR7]

That's impressive thanks for the test.

[soup]

@ techreactor When you use HcEnc on it's own & not part of Avi2Dvd do you still do the Identity swap between the exe & gui? I hope I explained that right & you know what I mean. I did it with 0.16 on advice but I haven't done it yet with 0.17.

[techreactor]

@ techreactor When you use HcEnc on it's own & not part of Avi2Dvd do you still do the Identity swap between the exe & gui? I hope I explained that right & you know what I mean. I did it with 0.16 on advice but I haven't done it yet with 0.17.

Hi

I dont use it with avi2DVD, I use it only with DVD-RB and that doesnt require the swap . Only you need to edit the HC.ini to make HCEnc work in CQ (OPV) mode, before you start with DVD-RB.

[soup]

Whew thanks I didn't know if I was explaining that properly. Again thanks for the info.

[UncasMS]

do you *compare* an opv result against the original frame from the vobs?

++++++++++++++

comparing the pictures it seems obvious that you compare reduced material against original material

in addition to this inappropriate *comparison* we do not have the identical frame depicted

the encoded material of course looses details / is smoothed and thus we shouldnt talk about a comparison here

[techreactor]

do you *compare* an opv result against the original frame from the vobs?

Yes, both the frames are from the VOB's, captured using vdubmob.

comparing the pictures it seems obvious that you compare reduced material against original material

in addition to this inappropriate *comparison* we do not have the identical frame depicted

Its difficult to get to the exact frame since the encoded video frame numbers changes and the screenshot has to be then done only by browsing thru.

I just wanted to show the results using OPV as compared to the original source, *Its not a poll*.

the encoded material of course looses details / is smoothed and thus we shouldnt talk about a comparison here

I forgot to mention, that I used removegrain(), since thats what I prefer, so the results are a bit smoothened, but are as per my taste.

I would like to iterate, that I have just shared my results, have never said which one is better!!!.

Its just for the ppl to know what they can expect using CQ mode of HCenc.

[UncasMS]

and i simply wanted to point out that comparing A with B shouldnt lead to any kind of conclusion as there is no basis for comparison

[techreactor]

and i simply wanted to point out that comparing A with B shouldnt lead to any kind of conclusion as there is no basis for comparison

Eeeexaactly.....its not about comparision but about the conversion process using OPV!!! and what to expect as results

[techreactor]

Today I tested 1 more movie with OPV(actually the CQ mode) and got impressive results with HIGH/LOW/AVERAGE Cell Bitrates: 3,033/2,069/2,527 Kbs, it took 173 min for a 2hr 46 min movie in Best mode, no filters.

I got an oversize of 31 MB but I managed it by stilling few extras menu's w/o audio.

So the key with CQ mode is to get the right CQ value and keep some buffer for correction.

[jdobbs]

Why are you using an external prediction routine? Does GetCQ give you different CQ values than the DVD-RB internal prediction routines? Also -- 4.31GB is a good size. I don't know how GetCQ works, but I have seen some routines that sacrifice overall quality in an attempt to make the output size more accurate and that concerns me. One good rule of thumb with CQ is that you really don't want to change it between segments because it will cause inconsistencies while viewing... and since you use a single CQ value for an entire VTS, sometimes increasing the CQ value by only one digit (e.g. from 5.9 to 6.0) will result in oversizing. So you may have to live with undersizing somewhere in the 1 - 5% range.

[techreactor]

Why are you using an external prediction routine? Does GetCQ give you different CQ values than the DVD-RB internal prediction routines? Also -- 4.31GB is a good size. I don't know how GetCQ works, but I have seen some routines that sacrifice overall quality in an attempt to make the output size more accurate and that concerns me. One good rule of thumb with CQ is that you really don't want to change it between segments because it will cause inconsistencies while viewing... and since you use a single CQ value for an entire VTS, sometimes increasing the CQ value by only one digit (e.g. from 5.9 to 6.0) will result in oversizing. So you may have to live with undersizing somewhere in the 1 - 5% range.

I dont have the Pro ver, therefore I cannot comment on what value the Pro ver gives in OPV. But you do need to do some tweaking with GetCQ values and look at the ecl's (to feed BR's into GetCQ) before start using its CQ value. The CQ value it gives is in 3 decimals so more accurate. GetCQ uses the pingpong script and therefore picks up samples from different segments.

I dont use GetCQ to encode but only for the value. Also Darksoul(from doom) is already developing a better CQ prediction tool (as he told me) for HCenc. Apart from it I also heard that DIKO has a better prediction routine then most others.

[jdobbs]

Hmmm.... I'll have to check on the accuracy. I thought HC only looked at one decimal place, but I'm not positive about that. I round to one place for that reason.

[techreactor]

Hmmm.... I'll have to check on the accuracy. I thought HC only looked at one decimal place, but I'm not positive about that. I round to one place for that reason.

No it doesnt, it looks at all three decimals. GetCQ uses HCenc for its prediction and when it comes closer to the desired size, it only changes the decimal values for its next prediction, till it reaches closest to the desired size and changing decimal values cause no difference in the encoded file size. Sometimes it attains 100% match but sometimes it goes no further than 99.3% precision.

And probably thats the reason why OPV prediction in DVD-RB pro is not as accurate as the rest.

[jdobbs]

I doubt that a CQ factor change measured in hundredths is making much of a difference... I also believe that the only way to get consistent accuracy above 99% is through two passes or the equivalent amount of time in predictive passes. But -- we're all entitled to our opinions.