Understanding relation between xVID parameters

[lapoule]

Hi,

I am a bit new with xVID so I went through the forum, and did a bit of testing.

Here are the tests I did and the questions I am asking to myself.

I am using
- a YUY2 9 seconds avi movie with no sound (not too long for a test....;-))
- VirtualDub 1.5.10
- Koepi's 1.0.3 XVID codec

XVID codec configuration (any unmentioned parameter is default) :
- 2 pass encoding
- profile@level = changing from a test to another
- quantization type = H.263
- quarter pixel
- B-VOPs (packet bitstream, closed GOV)
- advanced options
- motion search precision = ultra high (6)
- VHQ mode = 1 - Mode Decision
- Quantization (for I, P and B) = Min=2, Max=31
- bitrate calculator is set to 9 secondes/ 25 fps and for video and audio is "none"

I have done 5 tests and have a question for each...

TEST 1
AS@L5, 720*576, bitrate calculation = 7920 kps (size = 8702 ko according to calc)

result is : 8732 ko file (7935 kbps according to VDub, 8941 according to winamp).
Here is frames stats from xVID Status Monitor :
Quant Min Max Average
I 2 2 2
P 2 7 3.52
B 4 7 5.80

TEST 2
AS@L5, 720*576, 2003 kps (= 2202 ko)

result is : 2546 ko file (2304 kbps according to VDub, 2607 according to winamp).
Here is frames stats from xVID Status Monitor :
Quant Min Max Average
I 8 8 8
P 11 14 13.23
B 17 22 20.97

Q1 : why is the rate and size not as accurate as in TEST1 ?

TEST 3
AS@L4, same as TEST 2

result is : same as TEST 2

Q2 : changing Level does not change anything....are level only informational (I mean that are they only given for suggested parameters ?)

TEST 4
AS@L3, 720*576, 765 kps (= 842 ko)

result is : 2380 ko file (1118 kbps according to VDub).
Here is frames stats from xVID Status Monitor :
Quant Min Max Average
I 15 15 15
P 26 31 30.87
B 31 31 31

Q3 : why is my video file size/rate far away from the ones I requested ? (I hace the feeling that my max quant parameter (31) is not "strong" enough, because the average quant is very closed to max quant)

TEST 5
AS@L3, 576*480, 765 kps (= 842 ko)

result is : 892 ko file (796 kbps according to VDub, 811 according to winamp).
Here is frames stats from xVID Status Monitor :
Quant Min Max Average
I 15 15 15
P 22 31 27.93
B 31 31 31

In this test the video size/rate is almost the one requested.

Q4 : before I encode a 1 hour video and that I end with a muc bigger file than expected, is there a simple combination of parameters (quant, etc...) for every rate to be more or less sure of the file size (don't know if I made myself clear on this one)

Thanks for reading till the end ;-))

[communist]

Use 2pass encoding. Unless you have something that can be compressed really good it should hit the file size you set up :)
Here is pretty good guide on how to use it. Instead of loading up the avs you just load up your avi into VD.
http://www.doom9.org/index.html?/xvid-vdub-final.htm

[lapoule]

thanks for your answer.

Actually, I am using 2 pass encoding in all cases....the problem is that sometime my file size is bigger than the size I request (and not smaller...)

[jon.schaffer]

I would suggest you to make tests with longer samples.
If there is a very "error" in the final file-size, it's much visible on very small encodings:
the bitrate control engine - during the second pass - tries to achieve the desired bitrate by permanently fluctuate (within the overflow treatment values limits) around an estimated value (estimated for each part of the movie - so not always the same). So if the encoding ends with a frame while the codec was rising the bitrate, you can get a slightly too high bitrate, with this very small sample, because with 9 sec (225 frames and a few MB for the file)some KB are a significative error.
The very same error would be invisible in a longer sample where some KB are irrelevant face to 1000, 10 000 or 200 000 frames.

But maybe the content of your sample is a tough one for the codec and its default settings. Try capping the Minimum quantizer for each frame type to 2 (instead of 1). This may help.

Hope this helps

PS: In the first part of this answer, I may have written some really really stupid things - Please correct me...

[lapoule]

thanks for your answer.

I am actually also using min quant = 2 in all my tests.

I have noticed this file size difference for longer video as well, this is why I am digging a bit with a small one.

Cheers

[lapoule]

could the rate be innacurate because I am using BVOPs ???? I have just read that in v 1.1 beta, the follonwing fix :

"- {core}: Fixes to the CBR/ABR rate controller, it should work much better with
bvops now."

??

[jon.schaffer]

Originally posted by lapoule
I am actually also using min quant = 2 in all my tests.
...
- Quantization (for I, P and B) = Min=2, Max=31


Yes, indeed... too much lines to read (I'm a lazy guy ;))

About the B-frames:
well... I once had troubles with the bitrate on some "too highly" compressible movies and using min. quant=1. Among the different workarounds to this problem, disabling B-frames worked well. So, I guess B-frames are a difficulty for the bitrate control... (anyway, more than the I and P frames)

- {core}: Fixes to the CBR/ABR rate controller, it should work much better with bvops now.

Worth the try... give us your results...

[Surco]

Hi

Your tests shows this because:

The length of your clip is too short, and sometimes the rate control can't compensate. Longer clips will help here.
The average quant of the resulting file is too far from the first pass quant. Doing the first pass at higher quant (using zones) will solve this.

Cheers

[stephanV]

Originally posted by lapoule
Q1 : why is the rate and size not as accurate as in TEST1 ?
Your first pass used a too low quant to be effective at your bitrate. As said before, use zoneoptions to do a first pass on a higher quant.


[quote]
result is : same as TEST 2

Q2 : changing Level does not change anything....are level only informational (I mean that are they only given for suggested parameters ?)

Yep, thats what it also says in the XviD config.


Q3 : why is my video file size/rate far away from the ones I requested ? (I hace the feeling that my max quant parameter (31) is not "strong" enough, because the average quant is very closed to max quant)

With this test, you are reaching the point that you almsot cant go any lower in file size, 31 is the highest possible value for the quant. Resizing the video would be in place here.


Q4 : before I encode a 1 hour video and that I end with a muc bigger file than expected, is there a simple combination of parameters (quant, etc...) for every rate to be more or less sure of the file size (don't know if I made myself clear on this one)

Using standard settings you usualy end up with the desired file size. Dont muddle with minimum and maximum quants too much. And stay of the b-frame settings. Also, dont try to undersize your files.

[jon.schaffer]

Originally posted by lapoule
Q4 : before I encode a 1 hour video and that I end with a muc bigger file than expected, is there a simple combination of parameters (quant, etc...) for every rate to be more or less sure of the file size (don't know if I made myself clear on this one)

Indeed... you'll get the correct filesize/bitrate with long clips.
If you want to be absolutely sure to get the correct filesize/bitrate use min. quant.=2
I encoded a large number a movies (different contents) and NEVER had any bad surprise with filesize (with min. quant.=2, at least).

[lapoule]

Hi again,

I've done another test with a longer clip (8 minutes). My settings are still the same as in my first post.

- 2 pass encoding
- profile@level = AS@L5
- quantization type = H.263
- quarter pixel
- B-VOPs (packet bitstream, closed GOV)
- advanced options
- motion search precision = ultra high (6)
- VHQ mode = 1 - Mode Decision
- Quantization (for I, P and B) = Min=2, Max=31
- bitrate calculator is set to 8 minutes 4 secondes/ 25 fps and for video and audio is mp3 128k

in calculator, I have asked for 12600 kB for total video+audio (=188242 kB/2001 kbps for video).

My ending stats are :
Quant Min Max Average
I 2 4 3.40
P 2 5 3.73
B 4 8 6.14
average kbps = 1987 kbps

This sounds good but when I look at my filesize in windows it's 178647 kB (=1.5*118000) and when played in winamp it gives 3023 kbps (=1.5*2000kbps)

Any idea on this one ?

[jon.schaffer]

I'm not sure to understand.
What video size did you asked for? (12600 KBytes or 188242 KBytes?)
What is the size of the file?

This sounds good but when I look at my filesize in windows it's 178647 kB (=1.5*118000) and when played in winamp it gives 3023 kbps (=1.5*2000kbps)

???
What is the 1.5 factor?

WinAmp gives a total bitrate (audio+video). VDub gives the detail video then audio. Use VirtualDub to read the bitrate.

When we say "you'll have the correct filesize", it's not the perfectly exact bitrate. It's in general slightly inferior (the carefulness of the codec... (in the case where you're searching for that...)

[stephanV]

Originally posted by lapoule
in calculator, I have asked for 12600 kB for total video+audio (=188242 kB/2001 kbps for video).


I dont understand your numbers

12600 kB for total size, 8m04s gives 12600*1.024*8/(484) = 213 kbps for total bitrate... :confused:

PS. dont use WinAMP to detemine bit rate, use GSpot or VirtualDub.

[iago]

lapoule,

I don't know what's going wrong with your test encodes, but I encoded a short 4min 30sec clip using XviD-1.0.3-20122004 by Koepi with exactly the same parameters as yours

-------------------------------------------------
- 2 pass encoding
- profile@level = AS@L5
- quantization type = H.263
- quarter pixel
- B-VOPs (packet bitstream, closed GOV)
- advanced options
- motion search precision = ultra high (6)
- VHQ mode = 1 - Mode Decision
- Quantization (for I, P and B) = Min=2, Max=31
--------------------------------------------------
(no trellis - no chroma motion - else default)

and the final clip accurately hit the desired final size.

desired: 15000 KB -> output: 15006 KB

You must be messing up something there. I have not had any bad surprise regarding target size for a long long time either, and honestly I have encoded really a lot with XviD 1.0.3.

regards,
iago

[Bogalvator]

Problems reaching target size on shorter clips can also be solved by raising the percentages in the "Overflow treatment" settings (seen when you click 'more...' next to 'Twopass - 2nd pass' in the configuration).

Try raising from 5% to say 20%, and see if it helps.

[lapoule]

Sorry, I meant 126 000 kB (for video+audio = 118 000 for video only) and not 12600....

The 1.5 factor is the difference between my video rate I asked for and my final file rate. More or less same factor for the desired filesize (126 000) and final file size (178 000).

If XVID only gives video (and not audio), I should have 2000 kbps+ 128 kbps = 2128 kbps for video+audio and not 3000 kbps (winamp info).

I'll read my file with vdub to watch for the rate information

I'll give it another try anyway...

thanks for your help.

[lapoule]

I think I've found what is causing my problem....I had a look with VDUB to my file stats and it appears that my audio is NOT COMPRESSED at all (using a 1024 kbps rate !!! :angry: :angry: :angry: ).

I am really a newbie ! :D

Yet I have another question : apparently XVID codec does not encode audio with the video....is it possible to use a tool like LAME to encode my audio and XVID for video ???

Cheers

[stephanV]

lol, of course does XvID not compress audio, why should it?

select an audio compression in VirtualDub... there is a LAME ACM so you could install it and try it.

[lapoule]

Thanks for your help.

I all works fine now.

[pwh04]

"Yet I have another question : apparently XVID codec does not encode audio with the video....is it possible to use a tool like LAME to encode my audio and XVID for video ???"
------------------

I like to use gknot (which uses besweet) to set up and encode my audio (from dvd2avi). After, I use nandub (takes all of 3 min) to mux the audio. It's very easy..

[Brother John]

@pwh04
Consider to stop using Nandub. It’s terribly outdated. Today there are much better muxing solution around for every scenario (AVI-Mux GUI, VdubMod, mkvmerge...).