[XviD-devel] Re: qpel smearing/noise problem

[Michael Militzer]

Hi,

----- Original Message -----
From: "suxen_drol" <suxen_drol@hotmail.com>
To: <xvid-devel@xvid.org>
Sent: Tuesday, January 07, 2003 6:22 PM
Subject: [XviD-devel] Re: qpel smearing/noise problem


>
> > hi,
>
> > we need to replace our idct. the present mmx/xmm code (peter
> > gubanov/mpeg2dec) produces errors, which become quite visibile in
> > quarterpel mode. our current integer idct also produces qpels errors..
> > which makes me curious about the sse2/ppc/ia64 stuff.
> >
> > anyway, i think we should switch to michael niedermayer/ffmpeg's
> > simple_idct. it is fast and produces much less error.
> > simple_idct_mmx is written in gas... so will anyone object to me
> > commiting a nasm'd version?
> >
>
> i retract my previous statement
> it seems simple_idct is prone to h+v qpel interpolation error.
> (where as the mpeg2dec idct was more prone to h qpel interpolation)
>
> i conclude that quarterpel amplifies idct error.
> maybe wee need to enforce an intra macroblock refresh every 132/4 frames,
> or use ieee_floating_point_reference_idct, or maybe pull qpel
> entirely? :-(
>

I don't think that replacing our idct will really help us here: idct error
gets compensated, so the error itself is not that much of a problem. The
core problem is that different idct implementations introduce different
sorts of errors. Therefore if a different idct is used for decoding than in
encoding, the reference pictures will get more and more out of sync between
encoder and decoder over time which leads to artifacts (smearing).

Switching to floating point reference idct won't help (artifacts could be
even worse instead) because most decoders will use an idct which introduces
much bigger errors than reference idct and therefore encoder and decoder's
reference pictures will again run out of sync.

I see the following ways to solve the problem:
1) use xvid for decoding xvid content (encoder+decoder share same idct = no
problems)
2) implement the 132 inter macroblocks limit and check if this helps
3) reread the iso specs. I remember a sentence similar to this one: "idct
has to meet IEEE1180 requirements with the following modifications: ..." -
so our idct might be IEEE compliant but is maybe not compatible to the
mpeg-4 standard...
4) try to agree on one idct implementation between all the various mpeg-4
decoders (impossible, but at least xvid and ffmpeg could agree on one common
idct, maybe divx also)

bye,
Michael