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 ! :scared:

[hellfred]

So ffdshow will decode VP6 too... interesting ! :scared:
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) :D

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 (http://cvs.sourceforge.net/viewcvs.py/libvp62/libvp62/VP62/VP62.cpp?rev=1.1.1.1&view=markup)

[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]

@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]

So ffdshow will decode VP6 too... interesting ! :scared:
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]

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]

Could be cool to have a ffmpeg2vp6 like we have for theora :)lol, me wants a ffmpeg2h265 :rolleyes: :p

[Sirber]

lol, me wants a ffmpeg2h265 :rolleyes: :pCare to explain more? I don't get it.

[hellfred]

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.
I am not sure if I understood you correct.
I wanted to express that ppl are advised to change
int x = 8;
int y = x/2;tounsigned int x = 8;
unsigned y = x >> 1;
So they are supposed to use unsigned int together with the shift operator.
here (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_clang_bitwise_shift_operators.asp).
Hellfred

Small programm to test:
#include <iostream>
using namespace std;
int main() {
unsigned int x = 8;
x = x >> 1; // x/2
cout << x << endl;
x = x >> 1; // x/2
cout << x << endl;
unsigned int y = 2;
y = y << 1; // y*2
cout << y << endl;
y = y << 1; // y*2
cout << y << endl;
return 0;
}
will outputhaibane@LapLap:~/tmp$ g++ shift.cpp -o shift
haibane@LapLap:~/tmp$ ./shift
4
2
4
8

[akupenguin]

I am not sure if I understood you correct.
I wanted to express that ppl are advised to change
int x = 8;
int y = x/2;tounsigned int x = 8;
unsigned y = x >> 1;
So they are supposed to use unsigned int together with the shift operator.
That was not quite the advice. First, since x is a constant, the math will be optimized away either way. So consider:
int munge0(int x) { return x/2; }
If x is really always nonnegative, that should be changed to any one of
int munge1(int x) { return x>>1; }
int munge2(unsigned int x) { return x/2; }
int munge3(unsigned int x) { return x>>1; }
...which are all equivalent, and faster than the 1st version.
munge1 though munge3 will be compiled into a single shift instruction. munge0 can't, because (-1)>>1 != (-1)/2

[IgorC]

I'm not a video dev so don't push on me hard but maybe if they used signed int it will be also possible to verifire if integer is negative (complement to 2) by masking it with something like 0x80 and do optimisation only if integer >0

Nice decoder but still no information about it from on2 (they are too busy with a new generation of vp8/vp9 :p )

[hellfred]

Thanks for enligthning me, akupenguing.
Can you suggest a source that will teach me lots of c/c++ tweaks like the use of the shift operator for division with 2^n on unsigneded integers. I had c / c++ lessons only for about 1 year at university, and they mainly covered the basic. So I do need to learn those tricks to be ever able to understand the sourcecode of projects like x264/mplayer/ffmpeg. And understanding is required before I am able to help with such projects.

Hellfred

[bratao]

I think that its Official code, not Reversed code..
The code is So clear , commented and dosnt have Magics numbers

[dimzon]

I think that its Official code, not Reversed code..
The code is So clear , commented and dosnt have Magics numbers
Or stolen...

[gabest]

munge1 though munge3 will be compiled into a single shift instruction. munge0 can't, because (-1)>>1 != (-1)/2
Not a single shift, but it can be done with two additional instructions: (eax = -1)
(-1)>>1: sar eax, 1
(-1)/2: cdq / sub eax, edx / sar eax, 1

[Sirber]

@dizmon

you should update your post "On2 VP7 is great in quality but it is unusable for long-term video backup puposes!" since now VP62 is opensource ;)

[dimzon]

@dizmon

you should update your post "On2 VP7 is great in quality but it is unusable for long-term video backup puposes!" since now VP62 is opensource ;)
Done ;)

[Sirber]

anyone heard of a CLI VP6 encoder that input AVS?

[dimzon]

anyone heard of a CLI VP6 encoder that input AVS?
Just wait a little - it will be assimilated by ffmpeg

[Adz]

so let me get this right, there will soon be an ffmpeg build with the ability to produce VP6 based FLV files?

I currently use ffmpeg alot to produce FLV files, not sure what the video codec name is but it's pretty bad in comparison to equivelent sized WMV's i've produced. This would be great.

[hellfred]

anyone heard of a CLI VP6 encoder that input AVS?Sirber, you are ahead of time. Though the project aims to implement both the decoder and encoder for VP6, there is only the decoder at the moment. So you have to go ask On2 for any encoder app.

Hellfred

[Adz]

sorry to go OFT, but are there any better codecs that can be used in FLV (and decodable by standard flash player) that are better than the one built into ffmpeg (sorry dont know name of the actual codec used ffmpeg).

[Sirber]

@hellfred

Thanks for the info!

[celtic_druid]

Looks like the project has been removed.

[Sirber]

CVS still online. Get it while it's avalible :D

[Sirber]

Here's a link to the files:

libvp62.tar.bz2 (http://www.mytempdir.com/535123)

[hellfred]

Here's a link to the files:

libvp62.tar.bz2 (http://www.mytempdir.com/535123)
This file was reported as illegal material.
Access to the file is temporary blocked.

Gone, too.

Hellfred

[Sirber]

Want another link?

Files are still on CVS in any case: http://cvs.sourceforge.net/viewcvs.py/libvp62/

[edit]

new link (http://tinyurl.com/osft4)

[temporance]

Well, that was zapped pretty quickly by the powers that be. Here's a theory...

On2 must be pretty scared of their codecs' source escaping into the wild because the source could be used to prove patent infringement. Without the source, patent holders like AT&T and Microsoft can only guess that VP6 might tread on their IP.

Having looked at the source, it's interesting that, for a proprietary, independent codec, VP6 shares so many tools with MPEG-4 pt2 and pt10 (H.264).

I'll stop now, I'm being mischevious...

Edit: Naturally I'm not alleging intentional patent infringement on On2's part - my point is that even the most upstanding public company will find it incredibly difficult to create a video codec without treading on multiple patents. By keeping the algorithm closed, companies can ensure they do not place potentially incriminating evidence (source code) in the hands of the "prosecution" (patent holders).

[bond]

i guess on2 contacted sourceforge and this hosting company to remove the code. this either means:

1) the source was leaked and therefore on2's copyright was violated
2) on2 doesnt like their format to be publically known (which in fact now is the case no matter if the code gets removed from sf)

now regarding 2) i wonder whether reverse engineering is illegal? or whether offering code that uses someone elses patents is illegal without having the approval from the patent holder (same case as libdts)

[Selur]

maybe they took the code of the java applet and just ported it,...

[Sharktooth]

any official statements from on2?

[Sirber]

new link:

link! (http://www.yourfilehost.com/media.php?cat=other&file=libvp62.tar.bz2)

next time is torrent :sly:

[B.F.]

VP6 in ffdshow...
Interesting :D

[Sirber]

got deleted again...

Should I got for torrent?

[celtic_druid]

Put it up on your own server. Then we can see if On2 emails you to take it down and why.

[dimzon]

Put it up on your own server. Then we can see if On2 emails you to take it down and why.
Yes, it's fine solution! Bcz I asked On2 multiple times about legality of this decoder and dosn't got answer at all! But next day after my letter libvp62 project @ sf.net was closed :scared:

[celtic_druid]

So if you hadn't asked, then maybe they never would have noticed? Although presumably whoever got Siber's files deleted read this thread.

If I were On2 and I had gotten the project removed, etc. then I wouldn't discuss it either if I didn't have to.