XviD and undersize

[len0x]

I see some ppl have problems getting slightly undersized files with Xvid. So I want all ppl having such problems (as well as those who use Xvid and get correct sizes) report it here, providing:

1) Desired size (in kb)
2) Real size after encoding (in kb)
3) version of the codec used
4) audio used
5) whether credits option was used or not

So that we can see if it's a common problem and whether there is a pattern in undersizing.
Please don't post you findings to other threads, coz I want everything to be in one place...

[Acaila]

If you allow me to add something:

6) Report 1st pass size.

If people don't report this then the problem could very well have been a user error instead (=saturation). You can easily find this value by loading the 1st pass stats file in Koepi's StatsReader (comes with XviD install) or MoonWalker's XviD Analyzer (http://www.geocities.com/aleksikerayno/).

[len0x]

I don't get it - everybody happy with XviD filesizes ? :)

[FeWipS]

no i am not happy with my filesizes, ill grab my post together in a few minutes ;)


Here is my info

1) Desired Size: 716800 KB / 700 MB
2) Real Size: 713162 KB / 696 MB
3) Nics build from 23/12/02
4) ~160kbit MP3
5) normal credz encoding, no cropping or something



Movie is The Usual Suspects from a R2 PAL Disc, almost 102 minutes.



XviD Analyzer Results:

Number Of Intra-Frames (Key-Frames) : 1558
Number Of Inter-Frames (P-Frames) : 151004

1.02% of the Movie is Intra-Frames (Key-Frames)
98.98% of the Movie is Inter-Frames (P-Frames)

1-Pass Size : 1288324085 Bytes or 1258128 KBytes or 1228 MBytes
Average 1-Pass Size : 8444 bytes

[Mordor]

Well I can come with the 2 dvd rips i have done sofar with xvid and GK.

1st rip:
1.701mb - which was the size i got when doing the same rip with divx 5.02
2.698mb
3.the xvid build I have is from (March 16,2003 12:49), I think it is Nics build, but not quite sure as I no longer have the install file lying around
4.mp3 128
5. yes

2nd rip
1.701mb(735.670.272 bytes)- which was the size i got when doing the same rip with divx 5.02
2.699mb (732.968.960 bytes)
3. same build as the first rip
4. mp3 128
5. yes

I am sorry, but I don't know the 1 pass sizes for the rips.

[len0x]

Well, I don't see a pattern yet. 2, 3 and 4 M difference...

Those who experienced undersized files can you please anwers this:

a) did you do mp3 encoding as a part of GK job, or just mux ready file ? (I'm trying to figure out whether recalculation of target size took place)

b) can you try encoding without credits for a test... (+just muxing audio, so no recalculations occurs). In this conditions if undersize still exists - it's probably xvid problem, not GK (all that we can do is artificially pass slightly, say 2Mb, more to the desired size to xvid).

Does anyone have a perfect-sized rip with xvid at all ?

And what your experience with 2CD rips?

*edit*
look what I've found in xvid forum:
http://forum.doom9.org/showthread.php?s=&threadid=50876
it looks like it's quite common (somebody said "I always had results within 3Mb"). I recommend asking there for more information. (Or may be Koepi can say something here).

[cyberyeye]

Does anyone have a perfect-sized rip with xvid at all ?

Yes, but without using option like: b-frame, qpel, vhq mode.

Anyway i don't care about 2 at 10 Mo undersized. Undersized is probably due with encoding using unstable option: b-frames, qpel, vhq.

The size is not respected ...ok, but the quality is really better !!!

[dwrbudr]

Wanted filesize - 790MB

I manually select encoded MP3 file - 85MB (128kbps VBR)
GKnot 0.28.13 reported that Video data requires 691MB
I checked the option to calculate AVI interleave overhead to VBR
MP3 - (about 9MB)

The final AVI (only video) filesize encoded with Koepi XVid(latest dev build) was exactly 691MB.

The final movie file was 781MB (and NOT 790MB as I wanted to be)

So, I think the overhead does the wrong things... or I am wrong :)

[manono]

Hi-

For those people getting around 3 MB undersized with XviD encodings, I've found the same thing. If you're using GKnot to get the file size, as near as I can tell, XviD doesn't use the same amount of overhead as DivX3.11 or DivX5.02. So, when doing 1 CD rips, I set the file size for 703MB and it turns out fine.

[len0x]

Wow - this is interesting, can we drag someone from xvid forum to comment on that here ? :)

[FeWipS]

well i just ripped another movie over night and i got exactly the same undersize, my rip is again 713260 kb / 696 mb so i think ill try setting 704 as standard when ripping xvid again next week :P
i'll let u guys know what happens then lol

cya

[cyberyeye]

My last encode:

1) 620000 kb
2) 619336 kb
3) XviD 0.9.1 - Koepi 5 avril
4) Ogg 81 Mo
5) Yes using Gk "save avs script"

Muxing as been made myself with OggMux cause I prefer using Ogm than avi.

XviD Settings: load default + 1 pass + 2 pass (int)

Desired size: 620000 (for 2nd pass)

1 pass + 2nd pass:

Motion Search Precision: 6 - Ultra
Quantization Type: H.263
Max I-frame Interval: 250 (PAL dvd)
Min I-frame Interval: 1
Lumimasking: ON
Qpel: ON
Use Chroma Motion: ON
Max B-frames: 3
B-frames Quantizer Ratio: 150%
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON

..... etc....

Used Avs script (v2.5.1 dll):

mpeg2dec3.dll > cpu=2
Crop+resize > made with Gk
Denoiser > Fluxsmooth(7,7)
Tweak

final size: 704 Mo

My opinion: perfect ! Gk as made what i ask ^^

[cult]

Its better to remove lumimasking from defaults options.

[len0x]

care to explain further - why? :)

[cult]

I ll try.Few people use it and that is with weird results sometimes.There are also the refdixv's solution that is implented in Koepi's builds,but I am not so sure about cvs builds.But we discussed it with other guys(including some developers)and they agree not setting it as default

[FeWipS]

Originally posted by FeWipS
well i just ripped another movie over night and i got exactly the same undersize, my rip is again 713260 kb / 696 mb so i think ill try setting 704 as standard when ripping xvid again next week :P
i'll let u guys know what happens then lol

cya

latest rip just finished, as a test i set 703mb as size in gknot and yup it worked, its 699 mb now, so for all my next (xvid) rips i'll just use 704mb as standard and i guess i will be alright lol ;)
cya

[Acaila]

For everyone who is getting a few MB undersized and using Ogg Vorbis: How do you calculate the container overhead? Because an OGM requires less overhead than an AVI, which could account for those extra MB savings.

Personally I always set GKnot on "no-audio" and that way it always hits the target size within 1 MB after muxing into OGM.

[len0x]

I did some experiments and indeed overhead seemed to be not the one calculated. But when I looked closer I found that margin is not audio dependent, but rather fixed for a movie. That all leads to one conlusion: AVI overhead is not used at all when muxing XviD video!!!

So all you have to do is to uncheck "calculate frame overhead" and you will hit the target size perfectly :)
In the next version I'll be unchecking that option automatically when XviD is selected.

P.S. I still don't know why XviD behaves like this (even Nic's calculator is identical to the GK's one...)

[frodoontop]

@Acaila:
About the overhead for .Ogm: I don't know about divx, but for XVID+OGG 3 MB overhead seems to be just fine. It's more or less independant for the length of the movie.

[Acaila]

Which is exactly what setting it to "no audio" does, it still calculates an overhead based on the length of the movie, just less than what it would have used if you specified audio.

But len0x said he has found the answer, so...:)

[Ewi]

@len0x: I don't want to criticize you but my experiences are that there is a normal overhead with Xvid. There are differences how you mux a MP3. If you mux VBR MP3, you have to use Nandub (or Nandub style in VDubMod), as we all know, but there is no possibility to compare. But if you have chosen to encode a CBR MP3 you have that possibility. There is a file size difference between 2-4 MB if you mux it with nandub or if you mux it as CBR MP3 (for example as Riff Header added MP3-Wave File with Vdub or with VDubMod; use the later only with the not official release, cause CBR Muxing is broken in 1.4.13.2v2). If you mux it in the second way your output file is these 2-4 MB smaller than the file produced by nandub or VDubMod(VBRMP3).

How this is related to Vorbis and ogm files I don't know; perhaps similar.

Perhaps I'm doing a stupid thing here (and restart a discussion about an issue that is already solved) but I would like to know what kind of MP3 you produced and how you muxed it into your video file...

P.S.: Please tell me if this is all wrong and that I am stupid, if that's the fact. I'm not sure about this and I don't want to bother you unnecessarily

[len0x]

CBR MP3 is out of the question at the moment (the topic started when GK didn't support CBR mp3)
VRB MP3 is muxed properly with nandub mode of vdubmod...

The fact is: new versions of XviD producing AVI stream with overhead _already included_.

*EDIT*
Coz I had undersize with AC3 as well...

[TheWEF]

nandub does mux all kinds of mp3 with the same method. if you are using cbr mp3 and want to save space you must not use nandub for muxing. you can, but you have to manually add a wav header to your mp3 file with wavmp3 and mux it as a wav-file (like we did in the old days).

wef.

[Ewi]

That's what I wanted to say. If VirtualDubMods CBR Muxing function will work correctly (in the next release; 1.4.13.2v2 uses an incorrect rounding but it is known and fixed but not released) you don't have to add a wav header manually and CBR muxing will be as simple as muxing with nandub.

That's what Belgabor repeated over and over again(I hope it was Belgabor): make CBR audio AVI files. I like to make files that are totally in the specs... And to achieve this you have to use audio that is coded in CBR Mode. The result is that every program can edit these files but only a few like nandub or VdubMod can handle VBR audio AVIs correctly.

But if this is really not the reason for the few MB undersize I will trust in that. I read the numbers (2-4 MB) and they were so similar to the difference between muxing CBR files as CBR(manually) or as VBR (nandub).

But perhaps it would be a good idea to mux CBR files in CBR mode (I call it here CBR mode) and not with nandub. So you will have a few kbit/s more for your video bitrate(~3-5 kbit/s); and that's free of charge...

P.S.: I will search the forum for the answer but I would like to know how Xvid can add this overhead on its own. I think it can't know how I will mux my audio, if it will be CBR or VBR. But I will not ask til I'm sure that there is not already the answer somewhere... I tested it several times with Xvid files and DivX files: If I mux the file as CBR my file is 2-4 MB smaller... I will go and look for myself...

[len0x]

Originally posted by Ewi
P.S.: I will search the forum for the answer but I would like to know how Xvid can add this overhead on its own. I think it can't know how I will mux my audio, if it will be CBR or VBR. But I will not ask til I'm sure that there is not already the answer somewhere... I tested it several times with Xvid files and DivX files: If I mux the file as CBR my file is 2-4 MB smaller... I will go and look for myself...

You're missing the point - there are two types of overhead:

1) audio interleaving overhead (which is audio dependent indeed and codec cannot know that...)
2) AVI overhead (container overhead)

It seems like second one is the one which XviD is taking care of (since the encode is going to be to desired size, not bitrate). For divx - we're using bitrate and hence calculating _pure_ video stream without AVI overhead...

Actually after writing this I totally cleared this issue for myself :)

[Ewi]

You're missing the point - there are two types of overhead:

OK... that can always happen ;)

Perhaps I was a little bit confused cause both overheads are normally calculated simultaneously in a bitrate calculator (and in GK). But nevertheless: if this calculation is internally separated (or separatable) perhaps it would be a good idea to use these extra kbit/s for the video bitrate when CBR creation is chosen (perhaps after this muxing fix for VDubMod is released; in the unofficial build that appeared a few days ago, that you wanted to include in the Rippack, this fix is already included). In this case you can calculate audio overhead individually for CBR and VBR and the container overhead individually for Xvid and DivX...

Only an idea....