XviD presets - preliminary thoughts and suggestions

[Teegedeck]

Actually that was my mistake. I was too sloppy and overlooked that [edit:] the parameter 'LumiMasking' seems to be deprecated; I should have set 'AdaptiveQuant' to 'false'. Strange, as AdaptiveQuant doesn't seem to be an encraw input option.

[Valeron]

questions about preset for anime(XviD 1.1 final):
i encode an episode good detail Basilisk DVD with different settings of QPel(not recommend in your preset), GMC and Cartoon mode with 1st pass only. B frame 1/1.0/1, constant Q2, H.263 quantization. Trellis, VHQ1, VHQ for B, chroma optimization.

from the 1st pass result in the XviD status, with QPel on, bitrate increase about by 1.8%, it tends to code more I frame and reduce total number of P and B frames;with GMC on, bitrate decrease by1.2%; with Cartoon mode on, bitrate incredibly decrease up to 4.1%!:eek:

that is, with QPel only, you should produce the largest filesize and possible the best detail(theoretically), and with GMC and cartoon mode on, you can get the smallest filesize at the same quant(but in principle, GMC is very implementation dependent, cartoon mode definitely hurt details too).

my question is, do XviD 1.1 change a bit in this point or even make my knowledge outdated?
question in another perspetive: does XviD do bits saving with GMC and cartoon mode on(for this good detail anime) in way with quality degradation?

[Teegedeck]

The effects of encoding features on bitrates you have found are well-known and true. (If you did only a first pass, I assume that you did a zone-based first pass like described in the presets? Otherwise you wouldn't see any differences because Qpel and GMC aren't used in the standard 1st pass.)

Qpel makes for 1-2% bigger files, GMC saves about 0.5% (and is very slow), cartoon mode saves about 4%. As there is visually hardly anything to gain from Qpel in anime, and as the savings from GMC usually are very small and make encoding much slower, these are not used in the preset. Cartoon mode makes for astounding savings and thus delivers overall better quality in two-pass, so it is used.

No, cartoon mode never hurt any details in my tests. If this is more than a gut-feeling from your side, please come forward with screenshots to prove it (remember; only two-pass results are valid for the comparison).

See here (http://forum.doom9.org/showthread.php?p=621806#post621806) for some screenshots I took a while ago.

[Valeron]

@Teegedeck:
i can hardly tell the differences between the two sample you post~
but the feedback from my friends are vary

i'll stick to cartoon mode off for whatever i think very good detail source(i would like to pay 4% more bits to avoid anything unpredictable), but for most not so good detail DVD, i'll leave it on.

but for Basilisk, there's so many rainning scene, it's hard to encode, maybe zone encode will help me out

[Teegedeck]

That conscientious and certainly better than blindly saying 'cartoon mode is no good'.

This whole cartoon mode debate that we once had on the forum always struck me as funny. Isn't it strange how some people don't feel that cartoon mode is good for anime while they relentlessly denoise all detail to death, anyway? And how people used to be afraid of detail-loss because of cartoon mode in XviD and now have absolutely no bad feelings about using x264 with deblocking set to '0' which equals total destruction of any detail? ;-)

[Valeron]

That conscientious and certainly better than blindly saying 'cartoon mode is no good'.

This whole cartoon mode debate that we once had on the forum always struck me as funny. Isn't it strange how some people don't feel that cartoon mode is good for anime while they relentlessly denoise all detail to death, anyway? And how people used to be afraid of detail-loss because of cartoon mode in XviD and now have absolutely no bad feelings about using x264 with deblocking set to '0' which equals total destruction of any detail? ;-)
:goodpost: ,sir

that's why i only apply nothing more than convolution3d or even serve cleanly with only "MPEG2Source" and stick to XviD for my anime dvd backup. why denoise so much, i need the original dvd but not a reproduced one, right?

i have to state, i didn't say cartoon mode is not good, for my eyes it doesn't get rid of details/noise like AVC codec generally do. i'll somehow consider it a superior solution. nevertheless not everyone(mostly) would like to watch anime with that kind of noise/detail.

PS: the two sample you post is very static scenes. in PRINCIPLE they would not be hurt by the way catoon mode work. i'll try some BRIGHT&fast motion scence. Basilisk is generally too dull:(

btw, any ideas to make the rain looks pretty close to the original dvd?

[berrinam]

I don't want to appear impatient, but I'm wondering what the situation with XviD presets for MeGUI is.

Are you waiting for the naming issues to be resolved, because I haven't touched them because I don't use XviD and thus have no idea what is going on. If you tell me what the problems are, I can fix them.

[Teegedeck]

Oh, sorry - I haven't had any time lately. I hope those presets haven't held up things with MEGui.

You could actually save me some time if you can tell me how I best force a first pass to be performed at a defined quantizer. Restricting quants or meddling with zone-settings? That's it really; no other problems, just thinking about things other than video encoding ATM takes up all my time. I promise to be quick with these presets, when the above thing is worked out.

[berrinam]

It's not supported at the moment through any mechanism I know of. There (I think) is one turbo option, which restricts the features always in the same predefined way. I can change the way it behaves when pressing turbo to whatever you want, however that is only if there is a single set of first-pass options which is used for all the profiles. If not, then some other approach (probably something like having 'inner profiles' or something similar) needs to be looked into.

Is it enough just to hardcode what the turbo option is, or do you have different first passes for the different presets? How is it supported in XviD-VFW?

BTW, don't worry about holding MeGUI development up -- it isn't affecting it at all; I just wondered about the presets because they sound like a good thing for XviD+MeGUI. If I can help in any other way, let me know.

[Teegedeck]

Thanks for your help. :)

The thing about the first pass being performed at a different quantizer than the standard '2' is that in most cases '2' results in a bitrate too far from the aimed-at filesize for 2nd pass (especially true when using high-bitrate matrices). The curve is harder to normalize and we get an uneven quantizer distribution.

The usual solution when using the VfW interface is setting a zone with a constant quantizer for 1st pass. (This also disables fast first pass.)

If you can force quantizer=3 through the 'turbo' switch that would be fine by me; I'd wanted to revise the presets to '1st pass at quant=3' all over, anyhow.

So, this would probably mean I wouldn't need to create separate profiles for the 1st pass if 'turbo' is by default used in the 1st pass and if setting the 'turbo' switch would trigger the wanted settings? If it works that way one could of course ruthlessly alter the settings to meet what those preset-thingies require. Don't know whether others would regard this a 'misuse', though...

If you think it's viable this would be what I have in mind for a unified 1st pass behaviour (some compromises* included):

Quantizer=3, VHQ=1, motion search precision=5

Some folks would perhaps not like the change to motion search precision as '5' not exactly triggers a 'turbo-speed'..?

The rest should be standard 1st-pass behaviour (i.e. deactivated QPel, GMC, VHQ for-b-frames, chroma ME).

---------
*= motion search precision = 5 means an artificially small first pass for the DVD-R preset which runs at msp=4 in the second pass. Maybe the higher VHQ mode in 2nd pass will make up for it, probably not.

[berrinam]

I don't actually understand why you would want a high motion search precision in the first pass. What does it matter what the filesize is that pass?

Anyway, you are probably the best judge of how people will react to changes I make to XviD in MeGUI, so I have two things I could do:
Set turbo to behave exactly as it is needed for your profiles, meaning that mse5 would be enabled on turbo.
Support 'first pass settings' as a special configuration for the codecs (perhaps just XviD).

Now that I write it down, I think that 2. is better, but what do you think?

[Teegedeck]

Those first-pass settings are a compromise between a 'full quality first pass' and a 'fast first pass'. See this thread here (http://forum.doom9.org/showthread.php?p=644721#post644721), especially Koepi's and Didée's posts.

If you could without going to too much trouble work solution #2 that would be great, of course. :)

[Sharktooth]

Uhm... i dont think a Q4 first pass is a good idea for ULR matrix though.
It usually produces about 1000kbps @ Q2(Q4 for B frames) for 640/720px sources.

[Teegedeck]

The "1-CD" preset using EQMv3 ULR was meant for extreme compression ('extreme' as in 1000 kbps at full resolution, not 640x - so 'pretty extreme', I'd say...) and I thought it a good idea to use the middle-ground of 'allowed' quantizers for the first pass; i.e. '4'. But I myself wasn't so convinced that this was a good idea as you can see from this:
[...]I'd wanted to revise the presets to '1st pass at quant=3' all over, anyhow.[...]

If you think it's viable this would be what I have in mind for a unified 1st pass behaviour (some compromises* included):

Quantizer=3, VHQ=1, motion search precision=5

[Sharktooth]

Yep, quant 3 is much better... even if i would leave quant 2...
ULR compresses really much and sometimes, with particularly compressible or denoised movies, even using Q2 is not enough to fit 1CD...

[Teegedeck]

That's pretty rare at full resolution. More importantly - the aim of those presets is not that each and every one of them can be used to fill a CD, 2 CDs, a DVD, whatever. If the preset which utilizes the ULR matrix doesn't fill a CD you're supposed to use the next-higher preset. The idea is to use CQMs at their sweet-spot. The '1CD'-etc. tags are only there to give a vague idea.

For example, here's some figures from the most compressible source I've tested so far:

1CD fast@quant3: 497 MB (EQMv3 ULR)
2CD fast@quant4: 397 MB (EQMv3 LR)
2CD HQ@quant4: 439 MB (EQMv3 HR)

You see that if one uses the '1CD preset' at quantizer=3 one could already start using the '2CD preset' at quantizer=4 (even the 'HQ' version of it which uses EQMv3 HR) - and that would look much better indeed. So there's little sense in allowing a lower minimum quantizer than '3' for the '1CD preset' IMHO. It's not a nice method but I decided to use quant-restrictions in order to prevent the 'misuse' of a preset after it became apparent that such things would actually happen. :)

Edit: For means of comparison, here the same for the least compressible source I've tested so far (2-hour-movie!):

1CD fast@3: 1668 MB
2CD fast@4: 1511 MB
2CD HQ@4: 1734 MB <---- an obvious problem; for some movies the outcome just is different... I think I will change the max. quantizer of that preset to '5'

It really is so futile to assign absolute figures in bitrate or filesize to the presets; what would you think of 'grade A', 'grade B' etc.?

[Teegedeck]

OK, here's some (not all) MEGui profiles with the necessary CQMs. ATM it's for testing, OK? :) You should be able to just go to MeGUI file menu and choose 'import profiles'. Until berrinam has added custom first-pass settings to MeGUI you'll have to adapt your first pass settings manually to read:

Quantizer=3, motion search precision=5 (except for the '90% preset' where it should be '4'), VHQ=1

Actually I have no idea whether you can change the first-pass quantizer by adding a constant-quantizer zone in MEGui at all...

Spelled out:

* XviD '>30% comp. check' (fast): MSP=6, VHQ=1, VHQ for b-frames, AQ, EQM v3 ULR rev.3, curve-compr. H30, L15, quantizer-restrictions min. 3, max. 5
* XviD '>30% comp. check' (HQ): MSP=6, VHQ=4, VHQ for b-frames, QPel, AQ, EQM v3 ULR rev.3, curve-compr. H30, L15, quantizer-restrictions min. 3, max. 5
* XviD '>45% comp. check' (fast): MSP=6, VHQ=1, VHQ for b-frames, QPel, EQM v3 LR, curve-compr. H20, L7, quantizer-restrictions min. 3, max. 4
* XviD '>45% comp. check' (HQ): MSP=6, VHQ=4, VHQ for b-frames, QPel, EQM v3 HR, curve-compr. H20, L7, quantizer-restrictions min. 3, max. 5 (4 for I-frames)
* XviD '>58% comp. check' (fast): MSP=6, VHQ=1, VHQ for b-frames, Qpel, SixOfNine, curve-compr. H15, L5, quantizer-restrictions min. 3, max. 5 (4 for I-frames)
* XviD '>58% comp. check' (HQ): MSP=6, VHQ=4, VHQ for b-frames, Qpel, SixOfNine, curve-compr. H10, L3, quantizer-restrictions min. 3, max. 5 (4 for I-frames), Overflow Control Strength=0
* XviD '>90% comp. check' (fast): MSP=4, VHQ=1, VHQ for b-frames, b-frames 1/1.00/1.00, QPel, b-frame sensitivity=-3, SixOfNine, no curve-compression, quantizer-restrictions min. 2, max. 4 (3 for I-frames), Overflow Control Strength=0
* XviD '>90% comp. check' (HQ): MSP=4, VHQ=3, VHQ for b-frames, b-frames 1/1.00/1.00, QPel, b-frame sensitivity=-3, SixOfNine, no curve-compression, quantizer-restrictions min. 2, max. 4 (3 for I-frames), Overflow Control Strength=0

Settings that are always active if not specified otherwise: chroma ME, Trellis, chroma opt., b-frames: max. 2 consecutive, ratio 1.62, offset 0. NOTE: MEGui does not support chroma optimizer.

Naming has changed:
1-2CD preset --> 30% comp. check
2-3CD preset --> 45% comp. check
3CD preset --> 58% comp. check
DVD-R perfect preset --> 90% comp. check

I know that will trigger the inevitable question "what comp.-check?!?"* but I just couldn't come up with anything else that makes sense. Perhaps someone else has a thrilling idea.

The 'sharpen' preset will turn up as a specialized preset together with the 'for editing' and the 'Anime' presets lateron.

--------------
*: Compressibility check with Enc (http://forum.doom9.org/showthread.php?s=&threadid=50714); SixOfNine CQM, constant quantizer=3, b-frames max=2, ratio=1.62, offset=0, motion search precision=4, VHQ=off, Trellis=on, Turbo=on and no other switches at all.

Edit: forgot that "constant quantizer =3" for the comp. check. Sorry.

[berrinam]

You can let MeGUI manage the CQMs if you use File->Export Profiles. I've attached what it produces, which you can install by dragging onto MeGUI or by using File->Import profiles.

[Teegedeck]

Thanks; I've replaced my attachment with what you have uploaded.

Cool feature, by the way.

[henryho_hk]

XviD '>45% comp. check' (fast) and XviD '>45% comp. check' (HQ) seem different much. Any typo there?

Now I am trying to figure out how to make a comp test in Enc using commandline

[Teegedeck]

XviD '>45% comp. check' (fast) and XviD '>45% comp. check' (HQ) seem different much. Any typo there?They've always been quite dissimar. Apart from the obvious ('fast' uses faster settings) they use different matrices. The filesizes that EQMv3 HR and LR produce are not as different as for example the filesizes that LR and SixOfNine produce. When you use VHQ=4 with the HR matrix and VHQ=1 with the LR matrix the difference gets very small. What has changed in this revision is though that the HQ preset gets a higher max. quantizer because with sources that compress badly this preset at quant=4 is still 2% or something above the filesize of what the 30%-presets produce at quant=3. Let's see if it works out, it sure ain't a perfect world...

Now I am trying to figure out how to make a comp test in Enc using commandline:cool:

[loro]

Hey Teegedeck, first I wan't to say that this is great what your doing here because I tried some of the presets and I was amazed with the quality of some of my rips. I wan't to ask you someting. Only setting in xvid I do not fully understand are quantizer-restrictions. So here is my first question:

Example:

I'm doing a DVD rip and my compressibility check in Enc was 70,94% so I have decided to use this preset:
very high quality 2 - 3 CDs: slow medium compression:

VHQ=4, VHQ for b-frames, SixOfNine, Qpel, 1st pass @q=3, curve-compr. H10, L3, quantizer-restrictions min. 2, max. 5

My first question is about setting the quantizer-restrictions min. 2, max. 5. Is this for all frames (I,P,and B)

The second question is about using the setting "Qpel". Because i have a DVD-Divx standalone player, it doesn't have support for Qpel in Divx nor Xvid. If I deactivate Qpel will that affect the overall quality?

Thanx in advance.

[Teegedeck]

My first question is about setting the quantizer-restrictions min. 2, max. 5. Is this for all frames (I,P,and B)As you can read above, I just changed it so that I-frames max. quant. is '4'. And the min. quant is '3'. The b-frame max. quantizer is entered as '5' but will actually be calculated as 5 x 1.62 = 8 (well, roughly). Yes, that's not intuitive but apparently it is how XviD works.

The second question is about using the setting "Qpel". Because i have a DVD-Divx standalone player, it doesn't have support for Qpel in Divx nor Xvid. If I deactivate Qpel will that affect the overall quality?A little, yes. I didn't have hardware considerations in mind at all when I decided to work on presets; IMHO XviD's hardware profiles should do that job. Just deactivate QPel when you want to keep it compatible.

[loro]

So lets see If I got it right:

very high quality 2 - 3 CDs: slow medium compression:


Quantization Settings in Xvid for second pass:
Min I-frame quantizer: 2
Max I-frame quantizer: 4
Min P-frame quantizer: 2
Max P-frame quantizer: 5
Min I-frame quantizer: 2
Max P-frame quantizer:5

You see I'm kind of a new when it comes to quantizer-restrictions settings.

[Teegedeck]

The up-to-date presets are here. (http://forum.doom9.org/showthread.php?p=841263#post841263)
'3 CD preset (HQ)', formerly known as 'slow medium compression' now is called '>58% comp. check (HQ)'. I'm working hard to keep you all confused. :)

[loro]

Hehe I can see that, thanx for the link.

[shon3i]

@Teegedeck because i am interest for 1CD encoding (to keep quality much as possible) i use 30% HQ preset because enc show me 35%, after few hours of encoding i get file wery undersized. My target been 620mb (80mb for audio)=700mb, but i get 510mb video, i founded a i think is that problem, restricting quants to 3/5, 2/5 soloves problem.

[Teegedeck]

What does the XviD statsreader say about the first pass' filesize? Could you do a filesize prediction with Enc for the >45% comp. check (fast) preset at constant quantizer 4 as well?

Are you sure you've used these comp. check settings:
SixOfNine CQM, b-frames max=2, ratio=1.62, offset=0, motion search precision=4, VHQ=off, Trellis=on, Turbo=on and no other switches at all?

Thanks for reporting.

[shon3i]

Stats reader says 542mb

Are you sure you've used these comp. check settings:
SixOfNine CQM, b-frames max=2, ratio=1.62, offset=0, motion search precision=4, VHQ=off, Trellis=on, Turbo=on and no other switches at all?
Of course, ad i work first pass with q=3

Could you do a filesize prediction with Enc for the >45% comp. check (fast) preset at constant quantizer 4 as well?
Latter, maybe tomorow, i do this.

[Teegedeck]

Thanks, that's a big help! I do hope that for the vast majority of movies the comp. values I have given hold true. But it would be hoping too much that they hold true for every case.

ATM I'm happy to collect data. Even such that invalidates my data...

[henryho_hk]

Actually, the movies I encoded with your presets + xvid_encraw are very hard to make seeks. Much harder than conventional XviD VFW defaults. Does the increased # of b-frame make it harder to seek? It may also be xvid_encraw ignoring the "-max_key_interval 300" setting. Time for more testing. ^_^

[Teegedeck]

Increased number of b-frames? I don't think so; 2 max. consecutive is the XviD default... And for the 90% preset there's even a negative b-frame sensitivity, i.e. fewer b-frames. Nah, must be something else. (Seeking works fine over here.)

[foxyshadis]

Writing mp4 and mkv straight out of a lot of apps gives you almost unseekable files, but remuxing usually fixes that up.

[shpitz]

i ran xvid_encraw on a full football match. ~1:30hrs long using this command:

xvid1enc1.bat slow_extreme 1000 wc_720p.avs

this is the output:


start "slow_extreme - Pass 1" /b /wait /low xvid_encraw.exe -i default.avs -type
2 -pass1 default.stats -progress 100 -max_key_interval 300 -max_bframes 2 -bqua
nt_ratio 162 -bquant_offset 0 -vhqmode 1 -lumimasking -qtype 1 -qmatrix eq
m_v3ulr_rev3.xcm -nopacked -imin 3 -imax 5 -bmin 3 -bmax 5 -pmin 3 -pmax 5 -qual
ity 5 -nochromame -turbo -zones 0,q,4,KO -threads 4
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
Avisynth open failure:
AVISource autodetect: couldn't open file 'C:\Dokumente und Einstellungen\tobias\
Desktop\tmp\ELDER\ELDER_beta4\default.avi'
Error code: 3
(default.avs, line 7)
start "slow_extreme - Pass 2" /b /wait /low xvid_encraw.exe -i default.avs -type
2 -avi default_xvid.avi -pass2 default.stats -progress 100 -max_key_interval 30
0 -max_bframes 2 -bquant_ratio 162 -bquant_offset 0 -vhqmode 4 -bvhq -lumimaskin
g -qtype 1 -qmatrix eqm_v3ulr_rev3.xcm -nopacked -imin 3 -imax 5 -bmin 3 -bmax 5
-pmin 3 -pmax 5 -quality 6 -chigh 30 -clow 15 -bitrate 1000 -zones 0,w,1,KO -th
reads 4
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
Couldn't open statsfile 'default.stats'!
start "slow_extreme - Pass 1" /b /wait /low xvid_encraw.exe -i wc_720p.avs -type
2 -pass1 wc_720p.stats -progress 100 -max_key_interval 300 -max_bframes 2 -bqua
nt_ratio 162 -bquant_offset 0 -vhqmode 1 -lumimasking -qtype 1 -qmatrix eq
m_v3ulr_rev3.xcm -nopacked -imin 3 -imax 5 -bmin 3 -bmax 5 -pmin 3 -pmax 5 -qual
ity 5 -nochromame -turbo -zones 0,q,4,KO -threads 4
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
Input colorspace is YV12
xvidcore build version: xvid-1.2.0-dev
Bitstream version: 1.2.-127
Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
Detected 4 cpus, using 4 threads.
163301 frames( 99%) encoded, 20.18 fps, Average Bitrate = -1293kbps
Tot: enctime(ms) =8094685.00, length(bytes) = -879412230
Avg: enctime(ms) = 49.55, fps = 20.18, length(bytes) = -5382
I frames: 942 frames, size = 62092/58491355, quants = 4 / 4.00 / 4
P frames: 80877 frames, size = -21546/-1742642542, quants = 4 / 4.00 / 4
B frames: 81557 frames, size = 9867/804738957, quants = 6 / 6.00 / 6
start "slow_extreme - Pass 2" /b /wait /low xvid_encraw.exe -i wc_720p.avs -type
2 -avi wc_720p_xvid.avi -pass2 wc_720p.stats -progress 100 -max_key_interval 30
0 -max_bframes 2 -bquant_ratio 162 -bquant_offset 0 -vhqmode 4 -bvhq -lumimaskin
g -qtype 1 -qmatrix eqm_v3ulr_rev3.xcm -nopacked -imin 3 -imax 5 -bmin 3 -bmax 5
-pmin 3 -pmax 5 -quality 6 -chigh 30 -clow 15 -bitrate 1000 -zones 0,w,1,KO -th
reads 4
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
Input colorspace is YV12
xvidcore build version: xvid-1.2.0-dev
Bitstream version: 1.2.-127
Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
Detected 4 cpus, using 4 threads.
163301 frames( 99%) encoded, 9.01 fps, Average Bitrate = -2842kbps
Tot: enctime(ms) =18137247.00, length(bytes) = -1934683806
Avg: enctime(ms) = 111.01, fps = 9.01, length(bytes) = -11841
I frames: 942 frames, size = 53174/50089911, quants = 3 / 4.99 / 5
P frames: 80877 frames, size = 22749/1839901905, quants = 3 / 5.00 / 5
B frames: 81557 frames, size = 5766/470291674, quants = 4 / 8.00 / 8


after many many encodes this was the best encode that looked closest to lossless yet produced the smallest file.

3 questions:
1. it didn't matter which bitrate i specified in the command, it will always encode to the smallest filesize possible for the certain profile i chose.
2. when i went to mux the encode with the audio nandub said the keyframes are totally out of wack and i should rekey the file. the muxed output cannot seek at all.
3. there are several errors reported in the log, are they of any concern?

thanks

am i doing something wrong?

[henryho_hk]

Thank you for using my BAT script!

Please remember to use the most updated code in this post (http://forum.doom9.org/showpost.php?p=804680&postcount=87) because I made updates directly there.

Your command-line seems wrong. There is no need to specify the AVS name. My BAT will process every AVS file in the same directory automatically. The 2nd param is actually "<bitrate>", "<size>K" or "<size>M" (the param is for reference only because the preset quantizer settings has more prevailing effects.)

The "slow_extreme" preset uses the ultra-low bitrate matrix and so your encode is small. For bigger size, you should use slow_strong or slow medium. (All credit goes to Teegedeck) BTW, I have not updated my BAT to use Teegedeck latest presets yet.

As for the keyframe issue, I notice it too. Seeking through those AVIs seem much more difficult than those produced by AVS2AVI or VirtualdubMod. Still no idea, though.

Thank you again for using my BAT script. ^_^

[shpitz]

henry, i did use the latest code you posted.

the encoded file ended up being 2.6gb in size keeping 720p resolution and looking lossless to me (only difference from source is 60fps compared to 30fps encode).

i'm wondering what tools i can use to quantify the quality of a clip compared to the original...

can anything be done regarding the keyframe issue?

[squid_80]

xvid_encraw uses MS's AVIFile API for writing avi files, which chokes when files get larger than 2gb. Outputting to mkv works better but it's still a good idea to remux with mkvmerge to create cues.

[shpitz]

thanks squid, i'll give mkvmerge a shot.

[henryho_hk]

(only difference from source is 60fps compared to 30fps encode)

That's strange. Why is your fps changed after the encode? Is your source 720i?

As for the seeking issue, I suspect that it may be a problem of OGMuxer as the ogm produced (or even remuxed) by VirtualdubMod does not seem to have this problem.

I am now thinking if I can use MKV as intermediate output and then muxing it into OGM with VirtualdubMod (all in commandline).

[shpitz]

source is 720p, i used selecteven to reduce it to 30fps.

[henryho_hk]

Teegedeck, are there still "turbo=yes" and "chroma me=no" for the 1st pass? Is the 1st quantizer "2" or "3" for the 1st pass of >90% presets?

[Teegedeck]

Yes, yes and 'three'. :)

[firered]

XviD '>90% comp. check' (HQ): MSP=4, VHQ=3, VHQ for b-frames, b-frames 1/1.00/1.00, QPel, b-frame sensitivity=-3, SixOfNine, no curve-compression, quantizer-restrictions min. 2, max. 4 (3 for I-frames), Overflow Control Strength=0

in your presets i noticed something called sixofnine what is that excatly? and where in the options is it

[Adub]

six of nine is a quantization matrix put together by Didee. It is used to improve compression and keep details, etc. It is included in berrinam's profile zip. (see earlier pages)

[BigDid]

There is a recent thread on the subject with alternate location here: http://forum.doom9.org/showthread.php?p=839915#post839915
or on the author's page here: http://forum.doom9.org/showthread.php?p=840582#post840582 :)

Did

[henryho_hk]

The new BAT script with Enc comptest and new presets is under alpha testing. ^_^ The batch processing capability is temporarily gone because you need to click 2 buttons in Enc to start its comptest anyway.

I am also switching from ogm to mkv output because since squid_80 said Xvid_Encraw cannot write >2G avi files and I found some problems in Ogmuxer. Let's see if MKVmerge works better.

---------------------

I need more time to test.... because the HQ presets are really SLOW.... while the quality is.... AWESOME!

[Teegedeck]

You actually did it?!? Man, that's ace. :cool: Way cool.

[loro]

Hello Teegedeck I'm doing a Concert DVD Rip. It's 149 minutes long and I used both original audio files. Avarage Bitrate is like 1250 kbps. Then I did comprssibiltity check for 3 cd's with enc and I got 45% result so I used The SLOW HEAVY COMPRESSION preset and I got almost 400Mb oversized File

Aiming Size = 1365916 KB = 1334 MB
Result size = 1768000 KB = 1726 MB

[Teegedeck]

I'm sorry that you lost time with that encode but I hope we can clear this up.

Do you mean you used the preset that used to be called 'slow extreme compression' (with EQM ULR matrix) or the one that was called 'slow strong compression' (with EQM HR matrix)?

I suppose you meant 'slow strong compression' - which now has undergone a name-change and is called XviD '>45% comp. check' (HQ)'

From looking at the preset's new name you can already tell that your comp. check result was just on the border of things (BTW '>45%' reads 'more than 45%'), and not-so-long-ago it really could happen in such a case that at the maximum allowed quantizer you could not reach the desired filesize.

That's why I raised the maximum allowed quantizer for that preset to '5'. Because you still used the old name, I could well imagine that you've also used the previous version of the preset that only allowed for max. quantizer=4?

But at 45% compressibility - and in all cases that are just on or slightly below the mark - I would advise to use the next-lower preset; in this case that would be the '>30% comp. check' (HQ) preset.

Thanks for testing those presets.

[henryho_hk]

xvid_encraw ..... Outputting to mkv works better

xvid_encraw produces a MKV of fourcc MPEG4 (codec private actually). How can I change it to "xvid"?