Huge oversizing with 2pass encodes

[Xavin]

I am trying to make a 325mb 2pass encode with XviD RC3, and it is turning out huge, over a gig. I have done many encodes with the dev-api-3 XviD, and either I have found a bug or I am not understanding the settings for the newer version. I have tried three different times, and it is hugely oversized every time. I have tried all kinds of different settings, but it does this even with default settings. The only thing I changed from defaults this last try was setting the 2nd pass Target Size to 320000. I am using VirtualDub 1.4.13, though I have also tried with the newest VirtualDubMod and the same thing happens.

Any Ideas?

[crusty]

That sounds weird...could you post some more details?

[frodoontop]

Any Ideas?

Sure,

1. Try to load defaults and see if it helps
2. You're aiming for a target filesize right? Not for a target bitrate for instance?

[Xavin]

Originally posted by frodoontop
Sure,

1. Try to load defaults and see if it helps
2. You're aiming for a target filesize right? Not for a target bitrate for instance?

1.After the first time it happened I loaded defaults, and after the second time, I loaded defaults and left everything that way except the target size.

2.Yes, although I really don't like the "click the button to change the parameter" interface, it is not what I would expect. Is it still correct that the Target Size is in kbytes, so I would put in 325000 to get an approximately 325MB file?

The source file is a pretty plain avs script (crop, resize, levels, undot), and the source for that is a movie off a DV cam. The output resolution is 368x256.

This machine is a P3 800 at work, while I usually do encodes at home, but I have sucessfully done two pass encodes with an older devapi3 XviD on this machine in the past.

The XviD status screen shows that it is only using quants 1 and 2, so it is almost like it is disregarding the Target size all together.

[frodoontop]

To get from MB to KB: MB*1024
(1024=2^10)

Maybe that an old install is still screwing up your settings. Try to uninstall and do a clean install afterwards.

[sysKin]

Originally posted by frodoontop
Maybe that an old install is still screwing up your settings. Try to uninstall and do a clean install afterwards. Nah, loading defaults would fix that.

I have no idea what's wrong. The only thing that comes to my mind is that there is something wrong with 1st pass' stats file - if it's too short (no idea why would it be), everything after it would be coded with quant 2.

Perhaps you could use DRFAnalyzer (http://www.geocities.com/analyzerDRF/)to figure out what's going on with the video - what quantizers are used?

This is a very strange problem.

Radek

[Teegedeck]

Really. I suppose the 'zone'-settings would also reset if one clicks the 'load-defaults' button?

[Xavin]

I made a short clip of just the first five minutes so I could test easier. I did a two pass encode with the defaults. Target size was 27083KB. It gave me a file of size 78862KB. Here are is the DRFAnalyzer report:

DivX DRF Analyzer v0.9.5 Report!
File Name: F:\meeting_test_out.avi
FourCC: XVID
Codec: XviD0029
Resolution: [ Width: 368 Height: 256 ]
Frame Rate: 29.970 frames per second
The Video has 8991 frames [ 00:04:59 ]

Average Frame quality is HIGH [Average DRF/quantizer is 1.33]
Standard Deviation: Quality is HIGH [Std. Deviation is 0.47]
Image Resolution is LOW

The file has Packeted Frames!

There are NO frame drops ( NO drops is better )

Recomended Resolution: [528x368] (Target DRF/quantizer=2.8)

Performance Caracteristics:
This video seems to have too FEW Keyframes. May degrade image quality and seeking.
Macroblocks per frame: 368
The Width is not multiple of 32. May degrade performance in some systems.

Kilobits per Second: 2104.05
Kilobits per Frame: 69.97
Kilobits per Macroblock: 0.190
Bits per Pixel: 0.76

Frame Type Statistics :
I Frames: 0.42%
P Frames: 66.18%
B Frames: 33.40%
S Frames: 0.00%
N Frames: 0.00%
(More Advanced Codecs use B and S frames)
Frame Quality Statistics :

DRF=1&2: 8953 100.0%
DRF=3: 0 0.0%
DRF=4: 0 0.0%
DRF=5: 0 0.0%
DRF=6: 0 0.0%
DRF=7: 0 0.0%
DRF=8: 0 0.0%
DRF=9: 0 0.0%
DRF>9: 0 0.0%
KeyF/DeltaF: 0.42%
KeyDRF<4: 0
KeyDRF=4: 0
KeyDRF>4: 38

AverageKeyDRF: 1.00
MAXDRF: 2
AverageDRF: 1.33
Deviation: 0.47

http://www.geocities.com/analyzerDRF/

I am not an expert, but I have been lurking here for about two years and doing my own encodes for about a year and a half, so I do generally know what I am doing. It just looks to me like it is encoding every frame at the highest quant possible regardless of what is in the stats file.

The stats file is getting written, would it do any good for me to post it or a section of it?

[Koepi]

set all overflow settings to 20 %.

This will most likely help your problem.

You could also try to look at the first pass size and just try to hit that.

Koepi

[Xavin]

Originally posted by Koepi
set all overflow settings to 20 %.

This will most likely help your problem.

You could also try to look at the first pass size and just try to hit that.

Koepi
I just tried the second pass again with all the overflow settings set to 20. That did make it use quants other than 1 and 2, but the file turned out bigger than before, 83568kbytes.

*EDIT*
I was wrong, somehow an audio track got left in that last attempt and I thought it was bigger than it was. Changing the overflow settings did seem to fix the problem. The file was dead on within 20KB. Thanks for your help.

Do you think the default overflow settings are something that needs to change, or is my clip just strange?

[crusty]

What are all your encoder settings?
Getting such an oversized file is really weird.

[Koepi]

xavin:

i'll chat with sysKin about it, it seems either your clip is strange or our "smart" 2pass stuff stuff isn't as smart as it should be ;)

Regards
Koepi

[sysKin]

This is weird. All p-frames and i-frames are quant 1, b-frames are quant 2. How come O__O

Maybe there was some kind of overflow in 2pass2....?

[rivers]

just want to tell that while doing a backup of 'les invasion barbares' I've got the same oversizing problem (obviously i'm talking about RC4), and no problems at all with my backup of 'zatoichi'.

now i'll try the 20% overflow treatment fix you suggested (required ~3 days to localize the options :D )