Q pattern Encoding

[Steady]

Since moving from CD to DVD, encoding for a fixed size (bitrate) makes less sense to me than encoding for a fixed quality within a general size range.

I have been frustrated in my efforts to create an optimal "Q pattern" by the encoder. If I set Q=1.75, instead of giving P-frames 34443444... which I want, it will encode something like 333444444444.

What I would really like is to specify a pattern like 25452545... Would this be difficult to implement?

It would be nice if you could have separate patterns for p and b frames. For i frames, a separate value for "scene change" i-frames vs "max interval timeout" i-frames.

It would also be nice to have a special pattern to use following a scene change, like 8765432. This is based on a psychovisual theory that your eye takes time to pick out detail when the scene changes. So detail would be added as your eye adapts.

In a similar vein, but more complicated, "motion" parameter could be added. The thoery here is that the more rapidly the scene changes, the more your eye follows general movement and misses detail, so less high-frequency information is needed. With static scenes, your eye has time to pick out the fine details, so you would want a lower Q-value.

Or better yet, with high-motion you would drop the higher frequency coefficients, to the point of having only the first 4 "de-blocking" coefficients.

Note that this would need to be based on true motion, and not frame size or count of replaced macroblocks (ala Nandub).

[Koepi]

Back in 2002 we explained all this already.

XviD is not DivX 3.1 - it's no "hardcoded motion engine", some of the theories you have are supported _otherwise_, and some other theories are plain wrong.

If you choose to use trellis quantisation and maybe adaptive quantisation you might find the image altered (and in case of better quality) independant from the quantisation pattern. There simply is no benefit, but many drawbacks with forcing quantisers that way, i.e. non-optimal curve scaling, quality will vary more. (Especially in the case of high-q bframe, and then lowering the quantiser significant. Believe me, XviD's quality raised by a huge amount when we introduced a "actual quantiser = max (last quantiser +/- 2)" - it is a bad idea to decrease quality that way, the iframes of XviD look way better than with divx3 so you don't benefit from p-frames too much there.)

Don't get me wrong, I like the suggestion, but they make no sense to apply when you can use your screwdriver on the motor itself :)

Regards
Koepi

[Didée]

- Completely OT -

Steady, it's a great pleasure to see you around again.

Hope you'll stay a while, before never-never-land is calling again :)


A comment onIt would also be nice to have a special pattern to use following a scene change, like 8765432. This is based on a psychovisual theory that your eye takes time to pick out detail when the scene changes. So detail would be added as your eye adapts.
The theory is obvious, but doesn't work out from my personal experience. Same or similar effect is present in VP6 and older versions of RealMedia. Both annoy(ed) me *big time* with a muddy picture after a scene change, needing time to recover full quality.
Well, perhaps my eyes are simply too fast (trained during several years of semi-professional table-tennis ;) )


And forOr better yet, with high-motion you would drop the higher frequency coefficients, to the point of having only the first 4 "de-blocking" coefficients.
Although this is sensible in general, it is a sort of image degradation that is not in compliance with XviD's "spirit", I think. Plus, XviD's motion vectors are not necessarily "real motion" for several reasons.

But of course, an avisynth filter that does a similar kind of pre-filtering would be very interesting! - I could think of some member that uses to appear out of nowhere with some alien-like-technology filters as the perfect coder for such a one ;)


- Didée

[sysKin]

Originally posted by Steady
What I would really like is to specify a pattern like 25452545... Would this be difficult to implement?
Nope, having any *fixed* pattern (frame type+quant) is easy. But we probably won't do that, because there is no need for it.

As for setting particular quantizer for given frame type, this would require some hack in the code - because in xvid, any rate control must decide on the quantizer, and *later* it's the core that decides on frame type. So unless ratecontrol sets frame type (bypassing internal decision), it can't assign proper quantizer in advance.

This is why quantizer restrictions don't work in one-pass - only one restriction (to p-frames) is applied to all frames.

You can call it a design flaw, but it kinda seems to work for now.

For i frames, a separate value for "scene change" i-frames vs "max interval timeout" i-frames.
There is no difference between the two. All "max i-frame interval" does, is slowly lowers scenechange detection threshold to encourage encoder to detect a scanechange "on time". The threshold goes to zero when i-frame interval is fully reached, but it's almost certain that scene detection will "detect" a fake scene change (which is still better than random frame) before that time.
It would also be nice to have a special pattern to use following a scene change, like 8765432. This is based on a psychovisual theory that your eye takes time to pick out detail when the scene changes. So detail would be added as your eye adapts.
It turns out that it's often cheaper to encode a scene with full quality and just keep it that way, rather than spend bits every frame to make it better and better.
In a similar vein, but more complicated, "motion" parameter could be added. The thoery here is that the more rapidly the scene changes, the more your eye follows general movement and misses detail, so less high-frequency information is needed. With static scenes, your eye has time to pick out the fine details, so you would want a lower Q-value.

Or better yet, with high-motion you would drop the higher frequency coefficients, to the point of having only the first 4 "de-blocking" coefficients.

Note that this would need to be based on true motion, and not frame size or count of replaced macroblocks (ala Nandub).
All that is a part of more general HVS-based encoding, which I will try to introduce sometime soon. And btw, xvid has much better way of controlling quality than changing quantizer, or dropping selected coefficients. There is trellis, there is VHQ, and a couple of other things :)

Radek