[FFmpeg-devel] [PATCH i+1/N] RV40 loop filter

[Kostya]

On Mon, Mar 17, 2008 at 02:16:04AM +0100, Michael Niedermayer wrote:
> On Sat, Mar 08, 2008 at 07:21:57PM +0200, Kostya wrote:
> [...]
> > +}
> > +
> > +/**
> > + * This macro is used for calculating 25*x0+26*x1+26*x2+26*x3+25*x4
> > + * or 25*x0+26*x1+51*x2+26*x3
> > + * @param  sub - index of the value with coefficient = 25
> > + * @param last - index of the value with coefficient 25 or 51
> > + */
> > +#define RV40_STRONG_FILTER(src, step, start, last, sub) \
> > +     26*(src[start*step] + src[(start+1)*step] + src[(start+2)*step] + src[(start+3)*step] + src[last*step]) - src[last*step] - src[sub*step]
> > +/**
> > + * Deblocking filter, the alternated version from JVT-A003r1 H.26L draft.
> > + */
> > +static inline void rv40_adaptive_loop_filter(uint8_t *src, const int step, const int stride, const int dmode, const int lim0, const int lim1, const int mult, const int thr0, const int thr1, const int chroma, const int edge)
> > +{
> > +    int diffs[4][4];
> > +    int s0 = 0, s1 = 0, s2 = 0, s3 = 0;
> > +    uint8_t *ptr;
> > +    int flag0 = 1, flag1 = 1;
> > +    int llim0 = 3, llim1 = 3;
> > +    int i, t, sflag;
> > +    int p0, p1;
> > +    int lims;
> > +
> > +    for(i = 0, ptr = src; i < 4; i++, ptr += stride){
> > +        diffs[i][0] = ptr[-2*step] - ptr[-1*step];
> > +        diffs[i][1] = ptr[-2*step] - ptr[-3*step];
> > +        diffs[i][2] = ptr[ 1*step] - ptr[ 0*step];
> > +        diffs[i][3] = ptr[ 1*step] - ptr[ 2*step];
> 
> these are ordered in a quite strange way, why arent they:
> diffs[i][0] = ptr[-3*step] - ptr[-2*step];
> diffs[i][1] = ptr[-2*step] - ptr[-1*step];
> diffs[i][2] = ptr[ 0*step] - ptr[ 1*step];
> diffs[i][3] = ptr[ 1*step] - ptr[ 2*step];
> 
> ?

Beats me. It came from the code.
 
> Anyway, is your decoder with the loop filter bit identical to the binary
> decoder?
> If not why not?

Not yet. Both RV30 and RV40 decoders have some troubles with loop filter
and motion compensation (vectors). The reasons are quite usual - the lack
of specs, time, disk space and lazy developer. #2 and 3 are in the progress
of finding, #1 will be written after this is done, nothing to say about #4.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB