Better Overflow Treatment Settings (?) [Koepi's RC4]

[jon.schaffer]

SUBJECT:
Better Overflow Treatment Settings (?) [Koepi's RC4]



Hi everybody,

I recently had a problem with a DVD encoding (with Koepi's XviD 1.0 RC4 [Hola!]) which led to an oversized file. I searched for a guilty and found a solution to this problem. I later walked around the forum and found some relative threads, but the answers to the same problem didn't satisfy me. So I would like to bring some elements which may be interesting.

Here's the story:
I encoded one of my DVDs (Solaris, by S. Soderbergh, if someone can/wants to test it to verify the problem...) with some personnal settings and a bitrate of 1904 kbps in order to make this 1h34mn movie fit on 2CD (with mp3-CBR-160kbps sound). The final file was over 1.6 Go (with sound). (I must precise that I've already encoded several movies before, without any problem). My settings were not to blame, since the default settings led to the same (even more important!) problem...



So, I did many 2-pass tests with different sequences of different movies with different contents (i.e., from very high to very low-motion, in sequences of 500 to 1000 frames). The final files were nearly always over- or undersized (the error was sometimes very important).

The low-motion scenes generally produce oversized file; the high-motion scenes generally produce undersized files. When a clip (even a short one) has both low-motion and high-motion scenes, the final bitrate is close to the targeted bitrate. It acts as if the correct final-bitrate was achieved thanks to the alternation of high- and low-motion scenes, the first raising the bitrate, the second lowering it . So, the Bitrate Control seems inaccurate for short clips with homogeneous contents.

In a previous thread, Koepi explains that the default settings are OK for entire movies (at least more than 10 minutes said OUTPinged_ in another thread)... It's indeed OK for most movies, but with a movie like "Solaris", which has a lot of long very-low-motion scenes and no high-motion scenes, the default settings of XviD don't seem correct. So, the BitRate Control also seems inaccurate for full-length movies with homogeneous contents.


Some other conclusions to my tests:
- when a target file-size is asked instead of a bitrate, the result is the same.
- with the default settings, H.263 quantization involve a more important final bitrate-error than MPEG quantization.
- with the default settings, when high bitrates (e.g. 1900 kbps) are asked, the final bitrate-error is by far more important than in the case where lower bitrates are asked (e.g. 1000 kbps). So maybe a lower target bitrate aims its goal easily (I didn't test a lower bitrate with the whole movie). With the settings I recommend below, it's OK in both cases.



• I found 2 solutions to the problem:

1) disabling the B-frames allow to get the correct bitrate. But as B-frames are such a good thing to improve quality (at a fixed bitrate), this is not a good solution. I must conclude that B-frames are a difficulty for the BitRate Control... Is it right?

2) tweaking the "overflow treatment" values. A good solution, this time.
For the bad-size files problem, Koepi recommends high percentage for these values (20%). I don't know for which version of XviD these are good, but it seems to me that they're not good/optimal for XviD 1.0 RC4. Indeed, in my short-clips tests, these values lead to a correct final bitrate, but they produce a high number of high-quantizers frames (up to 24-29!), which involve some very ugly visible artifacts: blinking blocks in moving regions, even when the average bitrate is high... (but I must be honest: I didn't test Koepi's advised settings in a full-length movie, since I had already found some good settings by myself... ).

I found settings for this values which allow the codec to create a correct file-size and at the same time which produce a maximum of low-quantizer frames (or at least, which do not produce too high quantizers frames) - the key is to allow the codec to decrease the bitrate a bit more efficiently:

DEFAULT
- Overflow control strength 5
- Max. overflow improvement 5
- Max. overflow degradation 5

MY RECOMMENDED VALUES
- Overflow control strength 0 (the Crusty's FAQ say it is the Automatic setting and (normally) the DEFAULT value - maybe in prior versions?)
- Max. overflow improvement 4
- Max. overflow degradation 9 (this allows the codec to avoid the oversizing by lowering the bitrate easier, but without decreasing too strongly as 20% does)

(Other near values, like "0,5,9", "0,5,10" or "0,10,10", provide close results, but involve slightly more high quantizer frames)


These settings (for all the full-length movies and short clips encoding I made since) are OK for both final file-size and quality...
I won't say that these settings are the best in an absolute way... they seemed to be the best in my tests, and I use them since, that's all... I'm waiting for suggestions...

In fact, I don't know if my reasoning is right: it seems to me that, for a same bitrate, it is better to avoid having high-quantizer frame (if possible...). Let me know if I'm wrong...
I'm kind of a noob... neither developper, nor specialist in anything... This means that I've maybe forgotten some important point, like B-frames behaviour, etc. Furthermore, I don't really know how the 2-pass sytem really works. I don't know exactly how to use the Stats-reader which seems to be an important tool: in some previous threads, I read that the estimated file-size of the 1st pass was an important factor. With the "solution" I found to my problem, I don't bother this 1st-pass information... Is it bad?

###

So, to sum up:
- overflow default settings can lead to oversized (and under?) for certain full-length movies, whose content is too homogeneous.
- Koepi's recommended settings are good for correct final size achievement, but can produce ugly artifacts (in short clips, at least).
- the settings above (just slightly modified compared to defaults) seem to correct the size prediction problem and to preserve quality both in full-length movies and in short clips.


That's all.

I hope that:
- first, the error was not my fault (though, I don't think so). If it's the case, just consider my willingness and excuse me for wasting your time...
- secondly, this can help the development of this wonderful codec... My post is not a "bug"-report, but I think that the Default-Settings should be usable by all users, even rookies (and for almost all the encoded source),...
- in the third place, a final version will come soon...


Yours,

Jon


PS:
BTW another point/question concerning the bitrate: after calculating the bitrate in the built-in BitRateCalc, the value imported in the TargetBitRate param is 4 kbps higher than the one calculated (eg: 1908 instead of 1904). Why? Is it a pre-correction face to the BitRate Control behaviour (the final bitrate is about always 5 kbps lower than the expected one...)? Is it normal?

[rivers]

up!
this is definitely an important problem also for me (encoding a 2xCD rip of 'les invasion barbares' i've got an oversize of ~200MB), so would be great to read other comments.

[Manao]

Use defaults, but cap the quantizers to the range 2-31 instead of 1-31. But, in that case, you'll have undersizing ( because both of your movies compress easily, and if you check the first pass size with statreader, you'll see that it is inferior to the size you specified ).

In order not to have undersizing, raise the resolution, blurs less in the avisynth script, use lanczos if it is not already used.

[Asmodian]

So this is an example of why the old defaults for quant range were 2-31?

That makes sense, the size of a quant 1 frame is so much larger then a quant 2 that the rate control goes crazy and if you set the overflow higher it allows the codec to quant the next few frames high enough to make up for the massive quant 1 frame.

Do I have this right?

@jon.schaffer
I wonder if setting quants to 2-31 would fix your problem.

[jon.schaffer]

Hi,

first... OK... OK... my post is too long and may be confusing... I'll try to be more concise.

I want to say that this overflow problem is no more a problem for me. The settings I now use satisfy me (though I'm still looking for better settings... and till a new error appears...).

I've already tested encodings with Quant 2->31 settings. I haven't no more the results on my PC, but I remember that this indeed led to a modification of the final bitrate error, but an error still remained... (i.e., sometimes: undersizing became oversizing). Anyway, I'll try it again ASAP to see the real effect.

So, tweaking this seems to me like disabling B-frames: it has an effect which can really be good, but it's not the best solution... it only circumvents the problem.


I think that the min->max quantizer setting is above all a quality setting: indeed, setting the min quant to 2 seems to be a really good thing, since it allows - without too much quality loss - more bits to be allocated in higher quantizer frames, and so not to have too many high quant frames. This should not affect the BitRate Control.
I mean, the BitRate Control should normally be able to deal with it... if we use Q=1 as minimum value, the BitRate Control should, by default and in any way lead to a good final size, but - maybe - with a non-optimal quality-result (Duh... is that correct english?)


In the same way, (@ Manao), I consider that yours tricks are smart, but this is only an adaptation face to a problem. I'd prefer seeing this problem disappear...


For me this overflow problem remains a fault, because, with its default settings, it leads to errors with a certain number of clip/movies (I saw many threads about that specific problem).
I didn't want to do that, but... you know... DivX 5 is able to produce good file-size prediction with nearly all clips/movies - with different contents and durations. So, if we want XviD to be huge, newbies with default settings shoud be able to produce good encodings... (...obviously, encodings are in any way better with XviD...)

In the end: I don't think the smartness of the 2-pass - BitRate Control is inevitably to be called into question since with my slightly-modified settings ("0,4,9"), I get perfect results...
The reasons I posted are essentially: can some people confirm that my settings give good results in other problematic cases (i.e. "Les Invasions Barbares"?)... and can some advanced user tell [me] if this is indeed a good way to solve the problem (I wouldn't want to induce other users in mistake...)

Yours,

Jon

(Damn, it's again a long post... sorry!)

[Manao]

Your posts are definitely too long ;)

* Tweaking quantizer limit doesn't amount to disable b-frames.

* 2-31 was the original quantizer limit, until RC1 ( or beta3, I'm not sure ). With such a limit, nobody ever had oversizing. However, a lot of users were complaining about undersizing, each time because they tried to reach a final size bigger than if the movie had been encoded at quant 2.

So the developers decided to lower the limit down to 1. In that case, you don't get any undersizing. However, since a quant1 frame is a lot bigger than a quant2 one, the rate control algorithm ( with default settings ) can't sometimes cope with it, and this may lead to oversizing.

But the rate control algorithm with default settings is good when you're not using quant1, which happens most of the time.

But, anyway, when you try to reach a size that is bigger than a quant2 encoding, it means that you're underemploying the codec. That's why I told you to raise the resolution, or to denoise less. You can also try not to use b-frames, or a to use sharper matrix ( MPEG or Andreas78 ) instead of H263, and to add Qpel, and so on. Because you'll have a final quality which will be higher than if you used your solution.

And finally, with a movie like Solaris, 2CDs are really an overkill, especially if you don't keep the ac3 sound.

[jon.schaffer]

Thank you for your explanation.

Now, I just have to make some tests to see if some special frames in a movie could ever need to be encoded with a quantizer of 1. I don'think so, but...
And then, let's roll with Quant 2->31...

(Hey... I must be honest. Some DivX 5 encodings lead to undersizing too... this confirms your remarks...)

You're also right concerning Solaris... but, you know... in some cases, a perfect encoding would be 1.5 CD! (I'm part of those who are used to do 2 or 3 CDs-encodings - you know, those guys who always complain about quality...)


So... can we imagine that the default setting "2->32" will be back in the next (final?) XviD version?

In any way, thanks for your answers...

Jon

[JasonFly]

-My point of view on this oversizing problem is that it could be a combination of fast first pass and quant 1-31 limit.I explain:

Fast firt pass is konwn to be a tweak of motion estimation in the first pass in order to speed up first pass. This results in bigger first pass files than without fast first pass setting.
That,plus the fact that quant1 frames takes a lot of bits could explain that the rate control couldn't cope with this.


-jon.schaffer:
As Solaris is a well known quite compressible movies, did you try to make a 1 cd rip?
Doing that, we could know if this oversize problem is due to large target files(1400Mb) or also apply to smaller target files(700Mb).
You could also try to encode without fast firt pass option to see if that has an influence on your oversize.


-Personnaly, I have recently used the defauts quant limit(1-31) on many movies, and I didn't have any problems.
I even encoded a quite compressible movie(It's all about love).XviD used some quant1 frame(not many because I have chosen a big anamorphic resolution).I'll try to see the filesize result with a smaller resolution which will have more quant1 frames.

[Manao]

Originally posted by jon.schaffer
So... can we imagine that the default setting "2->32" will be back in the next (final?) XviD version?Well, I don't know, because the fact is that 1->32 leads less often to oversizing than 2->32 leads to undersizing.

For users who know what's happening, it's not a problem, because they always try not to reach saturation at quant2. But for newbies, who don't read doom9, 1->32 may be better, because there will be statistically fewer issues.

And moreover, the rate control algorithm may be improved with 1.0, in order to cope with quant1 ( I'm not a dev, so I'm just extrapolating )

[rivers]

oki, I'm doing right now a 2-pass of Les Invasion with quants @ 2-31 (a slightly higher res cause was already high, and MPEG quant instead of H.263)and I'll see what happens.
Thank you all guys.

[Sharro]

I read the whole thread. And I still remember how many times I have this same dilema.

My 1 cent would say: AC3 Track, and higher resolution, (720x XXX).

In the past I was looking so much at the numbers, that I forgot the visuals, than I was forced to do blind encoding (encoding without looking at the numbers just visuals) and damn me if Xvid is not great.

Now ? Most times (up to 120 mins) I'm encoding for 1400 mb filesizes, 1 ac3 track at 720x XXX and even if the quant distribution doesn't look that great (who isn't mislead by the great look of a quant 2 and 3 encode) still, the visuals of a higher quant/higher res always beat my lower quant/lower res attempts.

Without getting technical, try it...don't look at the numbers and look at visuals, still I always redo my encodes when quants go above 5 without any capping.

Numbers do not say everything about visuals.

I do understand you, I'm on my 7th encode of Pinocchio trying to get the "numbers" to look good, it's a damn noisy source, and it's 1H24min are giving me >2.5gb first pass sizes, the quants at 720x XXX are mostly quant 3. Still, the noise and poor quality of the animation make a quant 3 look as good as quant 2 even on a frame by frame basis.

First I gave mpeg a try, then hvs-best then h263, then filtering, then different resize filters, now... I'm removing filters and allowing higher quants, my attempts are always to reproduce original noise and damn... set your monitor to 1600x1200 and view your results at full screen, you'll certainly give credits to higher resolutions.

Numbers ain't everything. (Glad Mf forbid the word compressibility)

All the best,


Sharro

[rivers]

oki, redone with 2-31 quant, native resolution and MPEG instead of H.263, now i've got my good old undersized-movie-due-to-highl-compressibility, no more huge oversize :)

[Sharro]

Originally posted by rivers
oki, redone with 2-31 quant, native resolution and MPEG instead of H.263, now i've got my good old undersized-movie-due-to-highl-compressibility, no more huge oversize :)

What RES ?
What Settins ?
What filters ?

So many whats :-)

Take care

Sharro

[jon.schaffer]

Hi

• I just had time to make a few tests with short sequences (I re-used Solaris). This obviously confirms Manao's explanations. In one of my tests, a fixed quantizer of 2 leads to an average final bitrate of about 810 kbps (with B-frames, which produce quant4-B-frames).
In my previous encoding-tests (with 1->31 quant), I was asking for 1900 kbps for this very same scene... when this desired bitrate was achieved (with overflow values tweaking), many frames was quant1 (1 frame every 3 or 4 frames), in order to reach this soooo high bitrate.



• At this step, we find the "personnal visual appreciation" problem:

I of course totally understand why you consider "2->31" as being largely sufficient...
The "2->31" setting gives very good results, but personnaly (I must though test some other sequences - frame by frame), I currently slightly prefer the "boosted" bitrate with some quant1-frames... It allows to retain more film-grain/noise on many frames (without any blinking effect between quant1 and quant3/4-frames). It also allow to slightly decrease the displacement of pixels around moving objects (I don't know the name of that artifact).
So, I've currently got a better impression with the "1->31" setting...


But... but... but...
- I must verify if quant1-frames have such a real impact on visual aspect (maybe pixels are in... my eyes?!). And maybe I'm dreaming too much of a DVD-like quality at "low" bitrates... I should have never compared a quant1-frame to a quant2: I'm now like an insect attracted by the light - beware: it burns!
- I'm totally aware of the fact that using quant1 for a frame consumes many bits (it seems to be at least 2-3 times bigger than a quant2-frame!)... So, I'm afraid that too many quant1-frames may lead to the production of too many higher quant-frames, to "balance" (in a movie like Solaris, it may not be important, but what for high-motion movies?)... This would directly lead me to forget "1->31" and to use "2->31" setting instead...

This is the reasons why I'll keep testing that...



@JasonFly:

I agree to test what you propose. I'll do a 1CD-encoding ASAP (but my PC is soooo slooow [PIII-700]).
And I'll try to discard Fast First Pass too, but in a condition: you tell me what Fast First Pass is... Is it Discard First Pass? Is it Turbo? (I use them both...)

I'll also test a "simple" fixed-quant2 encoding to see the final size...

@Sharro:
I generally proceed like you: numbers can't say everything. I trust my eyes more. It's exactly why I don't want to forget quant1 too fast...



• Some questions:

1) in the StatsReader, what is the meaning of the final size? Is it the size for a fixed quantizer of 2? (this would allow me not to make the previous test ;-P )

2) I recently discoverd DRFAnalyzer. Great tool, but it reports quant1 and quant2-frames together (no distinction between them). Is there a tool which counts quant1 and quant2 separately - such as the Encoding Status Window does, but in a standalone way?


I'll give the results as soon as possible (but not until next week: my "snail-PC" is going to have a difficult week-end...)


Jon

[Koepi]

The solution for oversized files at 1-31 quant range is very simple:

set all overflow variables to 20% - and you're done.

We're still thinking about a better/smarter algorithm for "temporary overflow spreading", but that helps the workaround is too simple ;)

Regards
Koepi

[JasonFly]

Originally posted by jon.schaffer


@JasonFly:

I agree to test what you propose. I'll do a 1CD-encoding ASAP (but my PC is soooo slooow [PIII-700]).
And I'll try to discard Fast First Pass too, but in a condition: you tell me what Fast First Pass is... Is it Discard First Pass? Is it Turbo? (I use them both...)



I was talking about the "Full quality first pass" checkbox in the 1st pass tab.

[Manao]

jon.schaffer : the artifact you are refering to is called "ringing".

If you're not pleased with quality difference between P and B frames, you can try to change the b-frame settings ( lower the b-frame quantizer ratio / offset ), but it's true that quality will still be slightly lower than with quant1 frames. You can also give a try to "high quality" matrices ( H263 is not the best to retain grain )

I would tend to say that the grain can be added afterwards with postprocessing, but that is a personnal point of view.

Finally, I wonder : can you play back your encode without problem / slowdown on your PIII 700 Mhz ?

[jon.schaffer]

I've had time to make one test: Solaris with the same personnal settings (those who initially led to oversizing) except for the bitrate: I asked less than 900kbps (don't remember exactly...I currently don't use my PC...) in order to get a 700MB file.
Result: perfect final size.

I disabled Discard First Pass, this one (fixed quant2, isn't it?) is slightly smaller than the final (=2nd). So, as we could expect, I found several quant1-frames in the final (the only way to make the AVI "heavier" than "fixed-quant2"-AVI...).
So, it seems that the oversizing problem appears when a high Target Bitrate leads to the production of too many quant1-frames... which make the RC crazy...
I guess that, now, a problem is to determine the threshold (i.e. the minimal number of quant1-frames) from which the RC is lost (?)



I'll try other tests:

- I want to verify if a desired final file-size inferior to the one with fixed-quant2 produce anyway some quant1-frames or if the quant1-frames are only produce to "make heavier" a file... in the case of Solaris (I guess I know the answer, since my other encodings have several quant1-frames, but...)

- I'll try to make a 1 CD-encoding with the Default Settings, in order to make my conclusions more "valid" (although I'm quite sure about the result...)

@JasonFly:
I guess "Disabling Fast First Pass" is equal to "Enabling High Quality First Pass"?

-> I'll also try this in a 2 CD-encoding



@Manao:

OK for all this. I had already test both B-frames settings and other matrices (I usually use std-MPEG, I tried Andreas 78er and some others...). It's indeed slightly improving the quality and lower the ringing-effect.
Obviously, ringing can be find in every movies, but the thing is that in a very slow-motion movie, it's nearly the only visible artifact since the only motions are those of objects (people) moving on fixed backgrounds... so the eyes easily focus on this...
Post-processing can sometimes be interesting. I don't like very much de-ringing and de-blocking (loss of details), but noise addition can indeed be a good thing.

Concerning the playback: I'm totally dependant of the FFDShow decoder... The XviD-built-in-decoder is too slow for my PC. In order to display subtitles, I MUST use BSPlayer, which seems the most optimized for this. Furthermore, with my configuration, BSPlayer 1.0xxx is the only player to accept YV12-display correctly under WinXP (for me, Win98 was better for displaying video).
Some options like Q-Pel are though still a problem for me (but fortunately I don't use it, for visual preference reasons)
BTW, I know about the fact that FFDShow use alternative methods to decode XviD... So when testing the quality, I use the XviD-built-in-decoder or VirtualDub (vfw)... (e.g: when Trellis quantization used, FFDShow produce smearing... etc)

A question: do you think using quant1 is definitively a bad thing and that the only way to improve quality with quant2 is to modify the source-clip and/or to use sharper matrices/B-frames tweaking? (and if YES, is it because of too much loss due to the "balance-effect"?)


Jon

[Manao]

when Trellis quantization used, FFDShow produce smearing...I never heard of such a bug, are you sure ?

And for the use of quant1, well, I can't tell, because none of my encodes lead to a possible undersizing ( I almost always aim at 1 CD and two audio streams ). Quant2's quality is enough for my taste, but it may not be for everybody. So finally ( as always ), it's up to you :)

[jon.schaffer]

Yes, you're right it's up to everyone (personnally I never made any 1 CD-encoding of my life...). I was asking this "in a theoric way"...

Concerning FFDShow, I don't think it's really a bug. I would say it's related to the the decoding method used and its degree of optimization.
(It is not obligatorily directly related to the Trellis option, but I only noticed this in the only movie I encoded with Trellis...)

I had noticed this smearing effect longtime ago... while I was still using DivX. "Native" DivX decoder was OK; "Simple" method of FFDShow produced smearing (above all in pictures borders); "Normal" and "Reference" methods was OK...
I think the speed optimization requires/involves this slight loss in quality.


Jon

[kilg0r3]

Originally posted by jon.schaffer
"Simple" method of FFDShow produced smearing (above all in pictures borders); "Normal" and "Reference" methods was OK... Xou should use Xvid (Walken) Idct, otherwise you will get smearing, especially when using qpel.

[jon.schaffer]

@kilg0r3:
Yes, I knew this, but for my slow PCU, the only way to avoid jerky playback is... "simple method" of FFDShow. Thanks anyway...

@JasonFly:
I Tried "Full Quality 1st Pass" + "1->31". Without success... Oversizing still there...

@Manao:
New tests learnt me that the absence of ringing was only indirectly due to the quant1-frames. In fact, when quant1 is allowed, the resulting B-frames are calculated to be quant3. So, we have quantizer sequences like 1,3,3,1,3,3...
With the default settings we had 2,4,4,2,4,4... => ringing
By lowering the B-frames quantizer: 2,3,3,2,3,3... => less ringing
By allowing only 1 B-frame each time: 2,3,2,3,2,3... => (almost) no ringing...

So, I'm now searching for new global settings, based on the "2->31" setting...

Thanks for all your advices, I learnt much...

Jon