[XviD-devel] dynamic hpel/qpel decision

[Michael Militzer]

Hi,

----- Original Message -----
From: "Radek Czyz" <radoslaw@syskin.cjb.net>
To: <xvid-devel@xvid.org>
Sent: Monday, December 02, 2002 12:10 PM
Subject: [XviD-devel] dynamic hpel/qpel decision


> Hello everyone,
>
> I noticed this point in out todo list:
> >> * decision criteria if qpel or "normal" halfpel vectors should be used
> and decided to have some fun and play with it. I'm on a very good way
> to have it done - I currently use edge detection to check if encoded
> picture is crisp or smooth, and decide on those basis. As I'm doing it
> during P/B/I decision, other data - such as high/low motion info - are
> also available to me.
> Currently, my 'dynamic qpel' encodings have the size of halfpel (at
> fixed quant) but crispness of qpel where the crispness is visible. And
> also the smootheness of hpel in high motion (but the last not perfect
> yet). Not bad, is it?

Hm, I'm not sure if this is the perfect decision criteria. You seem to be
very happy to achieve halfpel filesize with dynamic qpel - well, from my
experience the difference between halfpel and qpel is not simply that qpel
gives a "crisper" image and has bigger filesize (well, this is what people
reported over at doom9 and it confused me a lot). In my tests, qpel resulted
in _smaller_ files than halfpel in nearly all cases. I have one clip where
qpel gives an advantage of nearly 30% (!!) over halfpel in terms of filesize
while PSNR is increased as well by about 0.2 dB.

Maybe qpel just performs very bad on your test clip, but I don't believe
that qpel is only good for "crisp" scenes and bad on smooth ones. A decision
based on high/low motion is something which might be better suited (qpel
seems to be more successful on slow-motion than high-motion) but I'm not
sure if this is true in general...
But because I haven't done any exhaustive tests yet to reliably figure out
under which conditions qpel is good or not (and because I don't have the
time to do any), I better stop criticism ;-): A not-yet-perfect decision
criteria is better than no criteria at all...

> However, there is one issue which must be resolved.
> Quoting our todo list:
> >> * VOL support only at I_VOP??. (interlacing,gmc,qpel,etc.)
> as changing qpel/hpel requires a VOL header.
>
> What are we going to do? If you asked me, I'd tell you that we can
> safely write a VOL header before a P-VOP, simply because all decoders
> decode it and there is no difficulties for future decoders to decode
> it.
> However, the question must be answered....

if it's not MPEG-4 compliant (and it looks like it's not), then we cannot be
sure that other players will accept our streams. It might work right now,
but when new players (and hardware decoders) will be available, the
situation could change completely.

bye,
Michael