OPV vs. Multipass

[TheSeeker]

Ok I have been searching around in this forum for general guidelines on bias and qual_prec settings in cce as I would really like to understand how I can maximize quality with Rebuilder as I love its output. Needless to say I found a crap load and it only served to confuse me a bit. I found this thread that stated OPV mode could produce better quality output than multipass at quants of 15-30 or so. this seems backwards to me.. shouldnt multipass be better than One pass? I guess I need a total re education on rebuilder and cce. also what are some good techniques and/or suggestions to analyze a movie and figure out the best possible settings to use within rebuilder and cce? i know one should analyze the bitrates used in the dvd using bitrate viewer but than how should one interpret these settings? Anyone patient enough to lend me their infinite experience would be much appreciated.

[Faust2]

I'm also a relative novice in CCE Encoding (And I only did manage it thru RB), but I can tell you this: (If i'm wrong, please anyboda feel free to correct me :)

1. OPV generally doesn't improve Quality compatred with Multipass. It just samples 1% or so of the source with different given compressing qualities (Q), and then tries to match a given file size. The achieved qualtity is then used for a one-pass Encode (which needs only one-pass-time) and gives you a certain quality. But generally, in multipass-mode, CCE tries to distribute the bitrate very accurate across the movie, depending on the complexity of the single frames (and not nessecearily keeping one certain Q). Also, using this process, CCE can reach much more exactly the given file size. But you can use OPV PREPARE to estimate the compressibility of the source and then maybe decide what to do (use filters...).

2. Concerning Bias and Qualitiy_prec: For what I remember what Master Jdobbs once said: In the First Pass, CCE does an encode with CBR (Constant Bitrate) and decides then, in the 2nd pass, where and to which degree to leave the CBR, to follow the different complexitiy of the source. By the Bias-Setting, you tell CCE how much weight is given to keep the CBR. I think by decreasing bias, you give more priority towards the constant bitrate, which prevents abrupt bitrate swings (which can maybe lead to stutters), but I'm not sure here. This was well discussed somewere here. With quality_prec, you tell CCE, if you want more priority on image detail and edges (with a high setting) or on evenly coloured regions (with a low setting). When you set it too high, you get colour banding, when you set it too low, you get mosquito noise (Am I right here ? :rolleyes: )

A good idea to test it would be: Run prepare with different settings, select an interesting segment by looking in the corresponding avs'ses, delete everything but this segment in the rebulder.ecl and start this ecl directly from CCE. then judge the m2v's. I didn't try it, maybe it works :D

regards, Faust

[TheSeeker]

Thanks for the info. Yea thats pretty much what I thought. I had done some more investigating and found some good info on opv and settings. Seems that a Quant in the 40's is pretty darn good and anything over 55 is not so good. Also from what I read it seems that for longer movies (>2 hrs.) you should use a bias of 15-20 or so but with normal movies 25 seems to be the standard. As for qual prec it seems that 16 is pretty standard for normal movies. Does this sound correct to all you experts? What Im also wondering is if a higher qual prec gives more attention to flat color areas than to detail would you then set the qual prec higher (say 20 or so) for animation? Just wondering because that anime i encode looks pretty good.. there is just very fine little mosquito noise around the edges. hardly noticeable except on a computer monitor at high resolutions but still there. any good way to remedy this? anyone have anything to add?

[Noah]

Does multipass do nothing more than determine how to best distribute the bitrate? It seems to me that with "Dynamically Assign Cell Bitrates" checked, that's kind of pre-determined by the original bitrate, at least on a per-cell level. Of course, you can get more precision than that, but what else does multipass accomplish?

[Faust2]

Originally posted by TheSeeker
What Im also wondering is if a higher qual prec gives more attention to flat color areas than to detail would you then set the qual prec higher (say 20 or so) for animation? Just wondering because that anime i encode looks pretty good.. there is just very fine little mosquito noise around the edges. hardly noticeable except on a computer monitor at high resolutions but still there. any good way to remedy this? anyone have anything to add?

Please note I said it the other way: With a high prec setting you give Priority to detail/edges ... But then again, I could be wrong :)

Edit:
...and I am:
(from the settings sticky :rolleyes: )

Quality_prec
Also known as Image quality Priority in CCE 2.5 and Quantizer characteristics in CCE 2.66 +. This setting ranges from 0-64, but is scaled for CCE 2.5 which uses a 0-100 scale.
This setting controls whether CCE gives priority to the fine details of the image, or evenly colored flat areas. A low setting will give priority to details, but could result in blockiness or color banding. A high setting will favor flat areas, but could result in edge artifacts.



I read somewhere that anime would be difficult to encode because of the many sharp edges in there. according to that, you could improve the quality by upping qual_prec. But up to now, I didn't do any anime stuff. I think, all this depends very much on the source, so testing is required. IMO, the RB-defaults are pretty good for the most cases. When the source itself is noisy, or the bitrate VERY low, a filter (two filters) like undot().deen() (using undot.dll and deen.dll) can work wonders.


What would be good to know: RB-Opt, the very useful add-on by robot1, has the option to set the GOP-Size to 15, not to 12, like it is the RB-Default. robot1 claims that this would be in the standard and enhance compression. I tried it several times, and it works (on PowerDVD). But (of course :D) ) I didn't do any test with the same source and GOP=12, so I can'T say anything about compressibility... Maybe someone (jdobbs ? :) ) can say what he thinks about this subject?

[TheSeeker]

To put it about as simple as it gets multipass examines each and every frame and determines the optimal bitrate for that frame. So essentially you are getting the most video bitrate where you need it and when while still staying under your target size. It gives you the best quality possible while staying true to your desired output size.

[TheSeeker]

Ok... I just did a quick test with Laputa: Castle in the Sky. What I wanted to test was the effect of qual prec settings on anime. First i ran prepare with qual prec 8 and bias 25, idct=7, cce 2.67. let it run through to the second m2v file than stopped. The source looked really quite good.. almost perfect.. ok then i just changed the qual prec to 60 and ran again (without re preparing it, i dont know if that was required or not) and the output looked almost identical. i dont know what is going on. does qual prec make such little difference on a high quality source? also the reduction was 69%.

EDIT: The resulting .m2v files WERE different sizes (the second one being 106mb while the first was like 96 i believe)

[jdobbs]

Originally posted by Faust2
Please note I said it the other way: With a high prec setting you give Priority to detail/edges ... But then again, I could be wrong :)

I read somewhere that anime would be difficult to encode because of the many sharp edges in there. according to that, you could improve the quality by upping qual_prec. But up to now, I didn't do any anime stuff. I think, all this depends very much on the source, so testing is required. IMO, the RB-defaults are pretty good for the most cases. When the source itself is noisy, or the bitrate VERY low, a filter (two filters) like undot().deen() (using undot.dll and deen.dll) can work wonders.

What would be good to know: RB-Opt, the very useful add-on by robot1, has the option to set the GOP-Size to 15, not to 12, like it is the RB-Default. robot1 claims that this would be in the standard and enhance compression. I tried it several times, and it works (on PowerDVD). But (of course :D) ) I didn't do any test with the same source and GOP=12, so I can'T say anything about compressibility... Maybe someone (jdobbs ? :) ) can say what he thinks about this subject? I'd be very careful using 15 frames. CCE has a tendency to sometimes add additional frames. Sometimes it will go over the DVD limit (15 for PAL, 18 for NTSC) -- I've seen it happen several times before when using authoring packages and a GOP size of 15 (and it was on NTSC!). Please note that DVD-RB assumes the input is good and doesn't do a frame count, so if you violate the standard you're up-the-creek... don't know what will happen. Maybe a freeze?

Generally speaking 12 frames is most often the standard on FILM and PAL DVDs, usually if you see 15 frames it is on NTSC sources (29.97fps).

[Lagoon]

I've already burned DVDs with GOPs of 24 frames, it worked fine in all the players I've got at home :D

[jdobbs]

Originally posted by Lagoon
I've already burned DVDs with GOPs of 24 frames, it worked fine in all the players I've got at home :D It doesn't change the fact that you did it wrong. The DVD standard does not allow more than 15 frame GOPs on PAL and 18 frame GOPs on NTSC. You got lucky.

[Faust2]

OK thanks jdobbs. I already thought that there was something problematic involved. But what do you think about a GOP-Size of 15 allowing better compression? Is it possible? Anyway, I will probably stay at the RB-default. I don't want to discover at one time that my backups don't work at some player :eek: :)

[Faust2]

Originally posted by TheSeeker
Ok... I just did a quick test with Laputa: Castle in the Sky. What I wanted to test was the effect of qual prec settings on anime. First i ran prepare with qual prec 8 and bias 25, idct=7, cce 2.67. let it run through to the second m2v file than stopped. The source looked really quite good.. almost perfect.. ok then i just changed the qual prec to 60 and ran again (without re preparing it, i dont know if that was required or not) and the output looked almost identical. i dont know what is going on. does qual prec make such little difference on a high quality source? also the reduction was 69%.

EDIT: The resulting .m2v files WERE different sizes (the second one being 106mb while the first was like 96 i believe)


This is how I think it works:

1. Put RB in three click-mode
2. Run PREPARE with one setting you want to check
3. either start encode and look at the first segment(s) after they finished (meaning looking at the corresponding m2vs) or select one interesting segment before, delete everything but this segment in the rebuilder.ecl, then start this .ecl directly from CCE (via open project/file)
4. Repeat steps 2 and 3 with different settings and judge them upon the same segment(s).

You have to start PREPARE again, because in this step the CCE-Settings (.ecl-file) are written.

[jdobbs]

Originally posted by Faust2
OK thanks jdobbs. I already thought that there was something problematic involved. But what do you think about a GOP-Size of 15 allowing better compression? Is it possible? Anyway, I will probably stay at the RB-default. I don't want to discover at one time that my backups don't work at some player :eek: :) 15 frames does make for better compression -- but the difference isn't dramatic and the picture is usually degraded slightly.