Is using a decimal # for quantizer value ??

[NeonEva]

when I re-encode other video files, mostly divx 5.0.x codec origonally, to XviD I like to use the 1 Pass - Quantizer method for encoding it.

But when I use a quantizer value of 3 the resultant file it bigger then the origonal file with the same quality.

When I use a quantizer value of 4 then the resultant file is smaller with must less quality.

so I am wondering if there is a way to use a decimal value like 3.5 which would resulat in a file that is farily close to the origonal file size and very similar quality

http://neoneva.n3.net/quant.JPG

this is the value I whis to change if you could not understand what I said.

is there any place in the sourc code that I could change it so this can be done then re-compile it ?

or can you make this an option in future releases.

Thanks for you time :D

[DaveEL]

You want quality based encoding that will give you an average quant. Look in the faq for the formula to convert a quant value into a quality value.

DaveEL

btw why do you want to encode divx5 stuff to xvid at the same size if its the same size you gain nothing and you lose quality?

[NeonEva]

the reason i am encoding it again is for a fansub group.

the raws are divx 5.0.3 usually and the group encodes it's final format in XviD so I am trying to get some good settigns to use so that the quality stays approx the same as the raw with close to same file size :D

as for that formula
((MaxQuant-MinQuant)/100 * (100-quality)) + MinQuant

I take it MaxQuant and MinQuant are the quantizer levels you want to use it in between, 3 and 4 for me. so I would get

((4-3)/100 * (100-quality)) + 3

just don't know what the quality is supposed to be:confused:

so if somebody could verify that this formula is correct so far and what value I need to plugin for my quality variable would be greatly appreicated :D

[NeonEva]

OK

away from the previous attempt at the formual I just did lets try again.

MaxQuant should be equal to the "Max I-frame quantizer" and the "Max P-frame quantizer" valuse in the advanced tab

MinQuant is "Min I-frame quantizer" and the "Min P-frame quantizer"

and quality is the value you use for the general quality setting of the 1 Pass-Quality

and then i use ((4-3)/100)*(100-50))+3 = 3.5

and Place Max I and P frames @ 4
Min I and P frames @ 3
quality @ 50
and then the quantizer should equal 3.5

:D

hopefully this it correct this time

[WyldeF1r3]

I know DivX5's 1pass quant allows for a decimal as a quant value, but I've never seen it done with xvid. Why not just go for a 2pass? Quantizers will be an averaged (decimal) value, and they'll be better distributed, thus smaller size

[BoNz1]

I don't know why you are trying to encode it again, especially when you are going for practically the same size you will only lose quality. I would just change the fourc on the avi to xvid if they really want it in xvid, chances are nobody will ever know the difference plus it would be a lot less work. Anyhow, thats just my opinion. Maybe it would be a better idea to encode the raw files to xvid in the first place if that is possible, but I don't know what you are doing perhaps this isn't possible.

[mf]

I haven't seen it mentioned in this thread, so I'll just mention it for completeness: Do note that quantizers are always integer. If you want a float quant like 3.5 the codec will just code frames with quant 343434343434343434 etc. Still, I agree with WyldeF1r3 that it might be better to run a 2pass first pass and then calculate what target size you would get with quant 3.5, and set that size in 2pass 2nd pass. (1st pass size * 2 / 3.5 if I'm not mistaken) Oh and btw, if you use 2pass, don't limit your quantizers.

PS: If you use "Discard first pass", you can find out the first pass size by Analyzing the stats file (http://homepages.pathfinder.gr/statsviewer/index.htm?&rnd=1045413692#download).

[Imperial Llama]

Originally posted by BoNz1
I don't know why you are trying to encode it again, especially when you are going for practically the same size you will only lose quality. I would just change the fourc on the avi to xvid if they really want it in xvid, chances are nobody will ever know the difference plus it would be a lot less work. Anyhow, thats just my opinion.

Changing the FourCC would be my suggestion too. I believe there may be other ways to tell what codec was used to encode the video but I doubt anyone is going to bother to check. As long as you didn't use DivX's Qpel or GMC then I think the video stream should be XviD compatible anyway (you might want to get someone who knows more about it then me to confirm this).

Personally I'd just change the FourCC, test it with Nic's latest decoder (no point testing it with ffdshow because we know it can decode DivX 5) and as long as plays back correctly then it's job done. :D

[Prettz]

Are these raws that are being encoded in divx5? If I remember correctly, divx5 always uses the h.263 matrix, so why in the heck would they use that for a capture that's supposed to be near-lossless?

[mf]

Originally posted by BoNz1
I don't know why you are trying to encode it again, especially when you are going for practically the same size you will only lose quality.
My hunch is he's a fansubber. And anime filtering does increase quality.

[NeonEva]

the reason i am encoding it again is for a fansub group.

yes, I re-encoding it because you can't just add the subtitles in with the origonal file, and fansubs groups don't like mass distributing the sub file to public ;p

well not from my experience

will try the 2 pass mode and see what happens then :D

thanks for you input guys

[mf]

Originally posted by NeonEva
the reason i am encoding it again is for a fansub group.
Oh! I didn't even notice that line! :) Still I had the right hunch then ;). If you wanna do fansubs you'll probably just wanna aim for 4eps/cd so best bet would be 175 * 1024 - audiosize, for 2nd pass target size.

[sungey]

yaa to get good/accurate size ... 2 pass is the way to go :)