Source where lower bitrate > higher bitrate

[madoka]

I was encoding Ghost in the Shell: Innocence, at ~950 kpbs. The result was not as good as I hoped for. Instead of playing with filters, I decided to just throw bits at the problem: increasing the bitrate to ~1980 kbps.

To my surprise, the result came out even worse. It turned out that the source was very noisy. At lower bitrates, XviD smoothes out the noise while at higher bitrates it tries to encode the noise faithfully--sort of. Only a few frames got the noise while the others were smoothed out. The result ended up alternating between noisy and smooth frames, which made the noise stands out even more.

I think this is the first time for me where increasing the bitrate actually decreased quality. Anyone else had the same experience with other materials?

[E-Male]

i got similar effects with rv10

for more 'controlled' and eye-pleasing results you should try to filter out teh noise before encoding

[Kagura]

I haven't had the problem you described because I rescale all of my quants for 2nd pass.

However, the new method does significantly improve quality of compression of anime at low bitrate. I've done 50% compression that now looks like what 75% compression would have been like using 1.0 with default settings.

Basically, use jon.schaffer (sp?)'s method to change internal settings, use the latest unstable build with the logarithmic correction, and cap quants religiously.

This creates a big disparity between the quality of i/p/b frames to deceive the eye. I must be *very* low quant so that the base image is good. P can vary a bit more, and b even more than that.

I usually do
I 2-3
P 2-5
B 2-6

[Sirber]

Use Convolution3D with animeHQ or animeLQ if grain is very bad.

[sysKin]

To my surprise, the result came out even worse. It turned out that the source was very noisy. At lower bitrates, XviD smoothes out the noise while at higher bitrates it tries to encode the noise faithfully--sort of. Only a few frames got the noise while the others were smoothed out. The result ended up alternating between noisy and smooth frames, which made the noise stands out even more.
This sounds awfuly similar to old ffdshow problem, where postprocessing would smooth b-frames badly and leave p-frames (relatively) unchanged. Can you check if this is not it?

[Didée]

I haven't had the problem you described because I rescale all of my quants for 2nd pass.

However, the new method does significantly improve quality of compression of anime at low bitrate. I've done 50% compression that now looks like what 75% compression would have been like using 1.0 with default settings.

Basically, use jon.schaffer (sp?)'s method to change internal settings, use the latest unstable build with the logarithmic correction, and cap quants religiously.
Erh, what? I thought I know XviD, but here I hardly understand anything.

Manual rescaling of quantizers? Change of internal settings? A la jon.schaffer? Logarithmic correction?

Could be please explain, just to ensure that I didn't wake up in an alternate reality today?

[Kagura]

Ah shoot. SirC was right when he said that 99% of ppl on doom9 wouldn't understand me >.<.

rescaling of quants = clamping quant values combined with changing the internal max trimming per frame.

Jon schaffer posted a stickie on this forum titled something like oversize/undersize. He says to change the 2nd pass overflow treatment and control strength. This combination rescales quant distribution to be imo more even and a more consistent quality. Actually, it's less consistent but appears to be more because interleaving a (relatively) bad frame followed by a (good) frame deceives the human eye into seeing quality.

I think the logarithmic correction was a fix for low bitrate in the latest unstable build.

[Teegedeck]

Ah shoot. SirC was right when he said that 99% of ppl on doom9 wouldn't understand me >.<.
Heyyy, don't try to make us feel stupid! :)

Capped quants are capped quants; they are NOT rescaled, they are cut off.

There is no such thing as an 'internal max trimming per frame'.

'Internal settings' as as a term don't exist. What you meant were perhaps 'advanced settings'. And there are quite a lot of advanced settings in XviD. Overflow treatment is overflow treatment and nothing else.

What you meant with 'logarithmic correction' was very probably Michael Militzer's 'low bitrate patch' for XviD (http://list.xvid.org/pipermail/xvid-devel/2005-March/004922.html). That patch simply consists of "using better lambda values for R-D vector search". Michael Militzer used a graph to illustrate the differences between patched and unpatched XviD behaviour, and that illustration used a logarithmic scale. That got nothing to do with the patch.

Don't be surprised to receive irritated answers if you don't express yourself accurately, OK? ;)

I hope we got the problem with terminology sorted out now.

[SirCanealot]

Ah shoot. SirC was right when he said that 99% of ppl on doom9 wouldn't understand me >.<.



Yeah, your language is too geeky. Half the time you sound like you're making your speech complicated and hard to understand just to give the person a challange in understanding. Sometimes it seems like you try to put as much terminology into your speech as possibly just for the hell of it.

When you really want to make yourself understandable, you need to treat the other person like a complete idiot ^^;;

I'll note, though, that I've used the capped quants and tweaked 2-pass settings for a few months now, and they've been working well for me. Though it might seem to me that it makes XVid block a tiny bit more and ring a tiny bit less. XVid will still randomly smooth a source to buggery, however... ¬_¬
Although this might have something to do with:
"Actually, it's less consistent but appears to be more because interleaving a (relatively) bad frame followed by a (good) frame deceives the human eye into seeing quality."
and my third magic eye (which is the size of a small moon) not getting tricked :P

[Teegedeck]

Yeah, your language is too geeky.[...]

When you really want to make yourself understandable, you need to treat the other person like a complete idiot ^^;;Nah, on the contrary it is sometimes necessary to use appropriate technical terms. But using the correct geek-speak would kinda help. ;)

[Kagura]

No, capped quants by themselves do rescale the quant distribution, without even taking into consideration the "culling in advanced settings." This just means that wheras previously the distribution might have been say:

I
2 157
3 300
4 100

it will now be
2 63
3 494

That's a rescaling (of the quant graph). Changing the 2nd pass overflow treatment also does a rescale. The evidence, courtesy of jon.schaffer, is at http://forum.doom9.org/showthread.php?t=92366. Obviously, doing both results in a rescale of quant distribution compared to the default settings.

For what I called "internal max trimming per frame," I quote crusty's FAQ:

"'max overflow degradation %' sets in % how much each frame may shrink if the file would become oversized. Think of it as 'trimming fat off your clip' if it's a bit too far on the porky side. :^)
Obviously, experimenting with these settings may break filesize prediction completely as you're altering the basic settings of the underlying process." (crusty, http://ronald.vslcatena.nl/docs/xvidfaq.html)

Also:

"Most of these settings are meant for tweaking of the allocation of bits during the 'real' encoding pass." (crusty)

Internal kinda developed from there too.

I'll admit that internal settings is always what I've called the settings hidden in the little side tab beside 2nd pass. It developed over a conversation I had with mf about forks (don't ask -.-). I used it in a conversation on irc with syskin and had no problems *shrug*. Yeah, it's also rather well hidden so that most new encoders don't even notice it. This also causes the quant distribution to be rescaled, even without any capping of quants. Logically, if each frame can have different %s trimmed off, there will be a tighter or looser spread in terms of std dev. I apologize if I confused anyone with that nonstandard term.

I got the logarithmic scales part from a post by Koepi on the last unstable xvid release.

"- {core}: Rate-Distortion tables fix - logarithmic scales adopted correctly." (Koepi, http://forum.doom9.org/showthread.php?p=634846#post634846)

Thank you for bringing up these points. I obviously cannot cite all my sources in every post, but I will be glad to do so upon request. If I have any erroneous sources, please correct me, and I will be glad to retract my statements.



SirC:The blocking you're noticing is because some frames are being "cut" more than they would otherwise be. Slight compression = ring/noise/blah (terminology again. Are we talking about the same thing?). More compression = blocks. It's the nature of mpeg 4 compression. There is less noise (which I think is what you're referring to) because the good frames do not have as much and, taken together, you are deceived (hopefully) into seeing a continuous clean picture, which is the purpose of lossy compression!

Oh, about your third magic eye: I used to never notice the Gibbs effect/phenomenon/blah until I read about it. Then, I looked back at some of my older stuff and GAH, I couldn't watch them ever again! =D Maybe the best way to delude yourself is to stop reading doom9. =P

[Teegedeck]

"culling in advanced settings."
??? Culling = "to pick; to choose; to slay". Sorry, but this really doesn't make any sense to me.
No, capped quants by themselves do rescale the quant distribution[...]

I
2 157
3 300
4 100

it will now be
2 63
3 494

Ah, that is a misunderstanding on my part because we use the terms differently: As far as I'm concerned scaling takes place before encoding; it is the process of normalizing the bitrate-distribution, or rather 'framesizes' for 2nd pass. What you are talking about is (for me) the effect of overflow handling. This takes place in order to compensate for the difference between the framesizes as they were calculated ("scaled") for 2nd pass and the actual framesizes as we get them in 2nd pass. The mechanism that takes care of that goes by the name of "overflow treatment" in XviD's config.

Now, as you also explained, if you cap quants, you easily throw the whole calculated bitrate distribution for 2nd pass off balance. So as an effect, we get massive overflow and, in that way, a rather brutal ad-hoc 'rescaling' is enforced, yes. You're right in a way there. :) Please take note, though, that this is not comparable to a rescaling of the complete bitrate curve, but that it only consists of shuffling bits back and forth between the calculated framesizes for frames that are just about to be encoded. Rather 'unsmartly', therefore with often bad results - and thus this is not really a desirable way to scale framesizes.

To explain myself: When you wrote 'capped quants rescale quant distribution', I said 'no', because they don't do that in a literal sense but rather trigger it; like: capped quants-->size-mismatch-->overflow treatment settings-->rescaling


For what I called "internal max trimming per frame," I quote crusty's FAQ:

"'max overflow degradation %' sets in % how much each frame may shrink if the file would become oversized. Think of it as 'trimming fat off your clip' if it's a bit too far on the porky side. :^)
"
Crusty really used some very colourful language in order to visualize what overflow compensation is about, here. Please don't use this allegoric language for seriously describing that mechanism, OK? Or else I'll call 'quantizers' 'my minuscule detail crunchers' from now on. ;) I guess we better stick to the names as they are written in XviD's configration tabs so that everyone knows what we are talking about.

Edit: Another problem with terminology:
I'll admit that internal settings is always what I've called the settings hidden in the little side tab beside 2nd pass. It developed over a conversation I had with mf about forks (don't ask -.-). I used it in a conversation on irc with syskin and had no problems *shrug*. Yeah, it's also rather well hidden so that most new encoders don't even notice it. This also causes the quant distribution to be rescaled, even without any capping of quants.I take it that you are now also talking about curve compression (high/low) here - or not? (Note that I need to ask...)

[Kagura]

Culling = " To remove rejected members or parts from (a herd, for example)" (dictionary.com)

I use it as I would "trimming."

Actually, the overflow from capping the quants produces a rather nice effect on animated content that I work with most. *shrug* Testing with different sources can yield surprisingly different results, as SirC can attest to.

"Crusty really used some very colourful language in order to visualize what overflow compensation is about, here. Please don't use this allegoric language for seriously describing that mechanism, OK? Or else I'll call 'quantizers' 'my minuscule detail crunchers' from now on. ;) I guess we better stick to the names as they are written in XviD's configration tabs so that everyone knows what we are talking about."

Sure. However, there are lots of terms that aren't standardized, i.e. gibbs whatever, ringing/edge noise/halo/whatever anyone thinks that is, etc.

"Edit: Another problem with terminology:"
I take it that you are now also talking about curve compression

Nope. I was referring to all the settings in that little tab beside 2nd pass. I've always called it internal settings because it was so well hidden, being only there when 2nd pass is selected and all...

[Shinigami-Sama]

oddly enouhg after about 1.5min of thinking and remembering what ghnot looks like I had reiltivly little problems with understanding kagura
as for "miniuscule detail crunchers" I think I'll acquire that term :D