[FFmpeg-devel] [PATCH] RV40 Loop Filter

Kostya kostya.shishkov
Tue Oct 28 16:20:37 CET 2008


On Tue, Oct 28, 2008 at 01:23:15PM +0100, Michael Niedermayer wrote:
> On Mon, Oct 27, 2008 at 09:49:04PM +0200, Kostya wrote:
[...]
> > > > 
> > > > 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.
> 
> this description is too vague to say much about it ...
> until i know precissely in what order things are filtered i cant say if its
> a odd implementation of a simple rule or not

Top left subblock
1. bottom edge
2. left edge when filter strength is not 2 for current MB and left neighbour
3. top edge when filter strength is 2 for current MB or top neighbour
4. left edge when filter strength is 2 for current MB or left neighbour

Other top row subblocks
1. bottom edge
2. left edge
3. top edge when filter strength is 2

Other subblocks:
1. bottom edge
2. left edge (one parameter is different for filter strength 2).

Hmm, that boils down to a rather simple ruleset.

Also for top row subblocks dithering parameter is N*4 for subblock N,
while for others it's simply N.
 
> [...]
> > > > 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. 
> 
> are you sure its not reference frame indexes? That would be more in line
> with h264 ...

even the functions are called refDiffMb or something similar.
Also it just checks MB type, I've checked.
It's not as H264ish as I like it to be (ideally, decodable by
unmodified libavcodec/h264.c)
 
> > My favourite is clipping value selection for bottom frame border.
> > As you can guess, B-frame edges are filtered too (pretty, huh?).
> 
> i dont understand what you mean by "B-frame edges"
 
real borders of B-frame (i.e. lines (0,0) - (width-1, 0), (0,0) - (0, height-1)
and (0,height-1) - (width-1, height-1). A bit uncommon to me).
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB




More information about the ffmpeg-devel mailing list