[FFmpeg-devel] [PATCH] RV40 Loop Filter

[Kostya]

On Mon, Oct 27, 2008 at 07:29:41PM +0100, Michael Niedermayer wrote:
> On Mon, Oct 27, 2008 at 07:09:34PM +0200, Kostya wrote:
> > On Mon, Oct 27, 2008 at 05:19:13PM +0100, Michael Niedermayer wrote:
> > > On Mon, Oct 27, 2008 at 05:12:33PM +0200, Kostya wrote:
> > > > On Mon, Oct 27, 2008 at 03:55:38PM +0100, Michael Niedermayer wrote:
> > > > > On Sun, Oct 26, 2008 at 03:41:09PM +0200, Kostya wrote:
> > > > [...]
> > > > > 
> > > > > have you confirmed that this loop filter is bit exact?
> > > > > Id like to make really sure that this is correct before i spend time
> > > > > on finding a clean implementation.
> > > > 
> > > > Yes, it is. But as I've mentioned, there is simpler and saner filter
> > > > there which I tend to use instead of this.
> > > 
> > > a different filter could cause artifacts for some videos, if that happens we
> > > are back to square one.
> >  
> > But binary decoder uses it instead of this for slower CPUs.
> 
> then it might be ok ... hopefully ... but then i dont belive in reals
> inteligence enough ...
 
because all their codecs are really maimed/rebranded versions of standard
ones?
 
[...]
> 
> > In most cases that would boil to "if this subblock is coded or neighbouring
> > subblock is coded or they are in different blocks and those blocks' motion
> > vectors significantly differ, then perform loop filtering".
> 
> but that can be implemented much cleaner than the way it is ...

that variant has escaped their sight completely
 
> > 
> > There are several question I'd like to know an answer:
> > 1. Why they have different edge filtering order for the first row of subblocks?
> 
> well i dont even know in what order they do filter them ...

for most cases it's bottom edge first, left edge second, for top row
there may be an additional filtering of top edge.
For the top left subblock filtering order depends on edge filtering type -
i.e. whether left edge is filtered like edge between macroblocks or
subblocks in single macroblocks (the last argument in loop filter function),
it may be invoked before or after top edge filtering (and top edge
filtering type affects that decision too). Except that, the rest fits
into simple loop.
 
> > 2. Why they decided to filter bottom edge of macroblock?
> 
> do they filter an edge twice?

seems so
 
> > 3. Why not stick to h.264 drafts more closely?
> 
> they probably thought their mess results in better quality or they just
> failed to implement h264 correctly ...

NIH syndrome?

> > 4. Why special treatment for B-frames loop filtering 
> 
> well i do not know how different it is, but there are 2 motion vectors
> instead of one that leads to special cases.
> This is especially nasty for H264 because one has to check more than
> forward vs. forward and backward vs. backward in the mv<4 check its
> also possible thet forward has to be checked against backward but that
> is h264 not rv, i dunno about rv ...

there are two differences - both are not related to MVs.
reference macroblock types are used in some logic for clipping values
selection. My favourite is clipping value selection for bottom frame border.
As you can guess, B-frame edges are filtered too (pretty, huh?).

> > (and why loop filter them at all)?
> 
> looks better i guess (less flickering (applying different filters to every 3rd
> frame is not going to look perfect), less blocking artifacts)

reminds me of logic on introducing BI-frames in VC-1 (i.e. B-frames that
are coded with intra MBs only).
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB