[XviD-devel] dynamic hpel/qpel decision

suxen_drol xvid-devel@xvid.org
Tue, 03 Dec 2002 19:39:28 +1100


On Mon, 2 Dec 2002 16:23:20 +0100 "Michael Militzer" <michael@xvid.org> wrote:

> 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...

motion search distance comes into play. since qpel halves the max search
distance, high action scenes will suffer.

> > 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.

ok, assuming we all agree to mpeg-4 conformance and permit only one 
vol per ippp(etc..) sequence, how do we determine when to enable qpel?
i can see two solutions:

a) buffer some (or all) the frames between keyframes, perform a
multi-frame motion analysis, and then encode. this will be slowish,
consume heaps of memory, and introduce a significant encoder delay.

b) restrict qpel to the second pass only, using the 1st pass stats to
determine qpel regions. his might also force use to consider the "three
pass encoding algorithm" :
	1st=halfpel at quant 2; gather motion stats
	2nd=halfpel and/or qpel at quant 2; gather bitrate stats
	3rd=encode to target bitrate/filezize.

cheers,
-- pete