LGPL VP6 decoder released

[bond]

someone released on sourceforge a vp6 decoder under the lgpl:
http://sourceforge.net/projects/libvp62
http://cvs.sourceforge.net/viewcvs.py/libvp62/

i have no idea whether it works (correctly), but maybe someone is interested in this (eg what encoding tools vp6 uses, eg compared to vp3, aso...)

[celtic_druid]

Just tried the sample flv player and it seems to work fine. No obvious decoding bugs/glitches.

[Sirber]

no news about that on On2 website.

[PatchWorKs]

So ffdshow will decode VP6 too... interesting !

[hellfred]

Originally Posted by PatchWorKs

So ffdshow will decode VP6 too... interesting !

Not through libavcodec, as they will not include c++ code. (The vp6 decoder lib in question is programmed in c++). But maybe Milan will include it directly, as he did with many other libraries.

Hellfred

[bond]

meh vp6 is outdated, why didnt the guy reverse engineer vp7 (if he reverse engineered it)

edit: anyone having an idea what on2 changed from vp3/theora to vp6?

[Sirber]

Why would they change? Xiph guys took 2 years to rename VP3 to Theora

Seriously, they didn't od it for VP4 and VP5. Why VP6?

[MfA]

The guy reverse engineered it because it's needed for flash decoding.

[Sirber]

Or it's stolen code...

[Nic]

Wow! What a tiny amount of code too. Just a couple of thousand lines.

Nice find Bond,

-Nic

[hellfred]

I am not really good at c and c++ but isn't allocating variables on the stack over and over in a loop very slow?

void VP62::iDCT8x8(int b)
{
    int src = 0;
    int dst = 0;
    int row, col;
    short *output = block8x8[b];
    int scoeff[64]; // Scaled coeffs
    int c;

    for(c = 0; c < 64; c++) {
	scoeff[zigzag[c]] = coeff420[b][c] * coeffScale[c];
    }

// 64277 = Cos   PI/16	* 65536
#define COS_1_16 64277
// 60547 = Cos 2xPI/16	* 65536
#define COS_2_16 60547
// 54491 = Cos 3xPI/16	* 65536
#define COS_3_16 54491
// 46341 = Cos 4xPI/16	* 65536
#define COS_4_16 46341
// 36410 = Cos 5xPI/16	* 65536
#define COS_5_16 36410
// 25080 = Cos 6xPI/16	* 65536
#define COS_6_16 25080
// 12785 = Cos 7xPI/16	* 65536
#define COS_7_16 12785

    for(row = 0; row < 8; row++) {
	int x0 = scoeff[src];
	int x1 = scoeff[src + 1];
	int x2 = scoeff[src + 2];
	int x3 = scoeff[src + 3];
	int x4 = scoeff[src + 4];
	int x5 = scoeff[src + 5];
	int x6 = scoeff[src + 6];
	int x7 = scoeff[src + 7];
	if (x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7) {
	    int t0 = ((COS_1_16 * x1) >> 16) + ((COS_7_16 * x7) >> 16);
	    int t1 = ((COS_7_16 * x1) >> 16) - ((COS_1_16 * x7) >> 16);
	    int t2 = ((COS_3_16 * x3) >> 16) + ((COS_5_16 * x5) >> 16);
	    int t3 = ((COS_3_16 * x5) >> 16) - ((COS_5_16 * x3) >> 16);
	    int u0 = (COS_4_16 * (t0 - t2)) >> 16;
	    int u1 = (COS_4_16 * (t1 - t3)) >> 16;
	    int u2 = t0 + t2;
	    int u3 = t1 + t3;
	    int t4 = (COS_4_16 * (x0 + x4)) >> 16;
	    int t5 = (COS_4_16 * (x0 - x4)) >> 16;
	    int t6 = ((COS_2_16 * x2) >> 16) + ((COS_6_16 * x6) >> 16);
	    int t7 = ((COS_6_16 * x2) >> 16) - ((COS_2_16 * x6) >> 16);
	    int u4 = t4 - t6;
	    int u5 = t4 + t6;
	    int v0 = t5 + u0;
	    int v1 = u1 - t7;
	    int v2 = t5 - u0;
	    int v3 = u1 + t7;
	    scoeff[src] = u5 + u2;
	    scoeff[src + 7] = u5 - u2;
	    scoeff[src + 1] = v0 + v3;
	    scoeff[src + 2] = v0 - v3;
	    scoeff[src + 3] = u4 + u3;
	    scoeff[src + 4] = u4 - u3;
	    scoeff[src + 5] = v2 + v1;
	    scoeff[src + 6] = v2 - v1;
	}
	src += 8;
    }

    src = 0;
    for(col = 0; col < 8; col++) {
	int x0 = scoeff[src];
	int x1 = scoeff[src + 8];
	int x2 = scoeff[src + 16];
	int x3 = scoeff[src + 24];
	int x4 = scoeff[src + 32];
	int x5 = scoeff[src + 40];
	int x6 = scoeff[src + 48];
	int x7 = scoeff[src + 56];
	if (x0 | x1 | x2 | x3 | x4 | x5 | x6 | x7) {
	    int t0 = ((COS_1_16 * x1) >> 16) + ((COS_7_16 * x7) >> 16);
	    int t1 = ((COS_7_16 * x1) >> 16) - ((COS_1_16 * x7) >> 16);
	    int t2 = ((COS_3_16 * x3) >> 16) + ((COS_5_16 * x5) >> 16);
	    int t3 = ((COS_3_16 * x5) >> 16) - ((COS_5_16 * x3) >> 16);
	    int u0 = (COS_4_16 * (t0 - t2)) >> 16;
	    int u1 = (COS_4_16 * (t1 - t3)) >> 16;
	    int u2 = t0 + t2;
	    int u3 = t1 + t3;
	    int t4 = (COS_4_16 * (x0 + x4)) >> 16;
	    int t5 = (COS_4_16 * (x0 - x4)) >> 16;
	    int t6 = ((COS_2_16 * x2) >> 16) + ((COS_6_16 * x6) >> 16);
	    int t7 = ((COS_6_16 * x2) >> 16) - ((COS_2_16 * x6) >> 16);
	    int u4 = t4 - t6;
	    int u5 = t4 + t6;
	    int v0 = t5 + u0;
	    int v1 = u1 - t7;
	    int v2 = t5 - u0;
	    int v3 = u1 + t7;
	    output[dst] = (short)((u5 + u2 + 8) >> 4);
	    output[dst + 56] = (short)((u5 - u2 + 8) >> 4);
	    output[dst +  8] = (short)((v0 + v3 + 8) >> 4);
	    output[dst + 16] = (short)((v0 - v3 + 8) >> 4);
	    output[dst + 24] = (short)((u4 + u3 + 8) >> 4);
	    output[dst + 32] = (short)((u4 - u3 + 8) >> 4);
	    output[dst + 40] = (short)((v2 + v1 + 8) >> 4);
	    output[dst + 48] = (short)((v2 - v1 + 8) >> 4);
	} else {
	    output[dst] = 0;
	    output[dst +  8] = 0;
	    output[dst + 16] = 0;
	    output[dst + 24] = 0;
	    output[dst + 32] = 0;
	    output[dst + 40] = 0;
	    output[dst + 48] = 0;
	    output[dst + 56] = 0;
	}
	src++;
	dst++;
    }
}

Taken from VP62.cpp

[Nic]

@hellfred: Compilers are pretty good at optimizing things like that. I noticed things like that in SNOW, but when I came to look at the optimized assembler of it, I realised the compiler had already taken care of it.

-Nic

[hellfred]

Originally Posted by Nic

@hellfred: Compilers are pretty good at optimizing things like that. I noticed things like that in SNOW, but when I came to look at the optimized assembler of it, I realised the compiler had already taken care of it.

-Nic

And on the other hand on the ffmpeg mailing list, ppl get advised to use unsigned integers and shift operators instead of devisions with integers (int, a/2^n) to squeez as much speed out of c/c++ code as possible. Strange world...

Hellfred

[dimzon]

I hope this is not stolen code!

[Sharktooth]

more info: http://libvp62.sourceforge.net/

[hellfred]

Originally Posted by hellfred

Not through libavcodec, as they will not include c++ code. (The vp6 decoder lib in question is programmed in c++). But maybe Milan will include it directly, as he did with many other libraries.

Hellfred

Ooophs, it looks like i was wrong about libavcodec:

[Ffmpeg-devel] VP62 libraries now Open Source
Alex Beregszaszi alex at fsn.hu
Mon Mar 20 19:53:28 CET 2006
Hi,

> > > Please stop considering the inclusion of the code as it is into ffmpeg.
> > > Big parts of the code could reuse vp3.c and our rangecoder. 
> > > 
> > 
> > who is volunteering for adding the missing bits in ffmpeg then?
> 
> I'm considering doing it.

How far are you? As I planned/started it today. If you have more time
than I, take it :)

So two developers from ffmped mailing lists plan to enhance libavcodec's vp3 decoder to be able to decode vp6.2, too. Let's see if they will actually do it. But wasn't one of vp6's strong points the postprocessing of the decoder. It will be hard to replace it.

Hellfred

[Sirber]

Could be cool to have a ffmpeg2vp6 like we have for theora

[akupenguin]

Originally Posted by hellfred

And on the other hand on the ffmpeg mailing list, ppl get advised to use unsigned integers and shift operators instead of devisions with integers (int, a/2^n) to squeez as much speed out of c/c++ code as possible. Strange world...

That's unsigned integers or shift operators... because x/2 is not the same as x>>1 for signed x, so no compiler is allowed to optimize one into the other.

[bond]

Originally Posted by Sirber

Could be cool to have a ffmpeg2vp6 like we have for theora

lol, me wants a ffmpeg2h265

[Sirber]

Originally Posted by bond

lol, me wants a ffmpeg2h265

Care to explain more? I don't get it.