DiAVC decoder, yet another fast H.264 high profile decoder

[schweinsz]

I am happy to anounce that the DiAVC, another high profile decoder is released.

http://www.di-avc.com/

The supported features:
I Slice, P Slice, B Slice
weighted_pred_flag = 0, 1
MBAFF and PAFF
Custom Quantization Matrix
CAVLC and CABAC
Deblocking Filter
Multi-reference frames
Direct_8x8_inference_flag = 1 or 0
IPCM
Constrained_intra_pred_flag = 1 or 0
transform 8x8 and 4x4
weighted_bipred_idc = 0,1,2
Multi-Core supporting

Limitations:
Need CPU with SSE2


The DiAVC alpha version includes DiAVC.ax and a tool named DiAVC Setting.exe to set the default H.264 decoder.

Where can i get it?

[_xxl]

Multi-Core supporting

Are you using a frame level parallelism?
Open source?

[Guest]

The attachment contained a virus (win32/nsanti) and so was deleted. I give the benefit of the doubt this time. If it occurs again, you'll be banned, schweinsz.

[schweinsz]

Originally Posted by neuron2

The attachment contained a virus (win32/nsanti) and so was deleted. I give the benefit of the doubt this time. If it occurs again, you'll be banned, schweinsz.

What is your anti-virus software? I use the McAfee and it never report virus. I have used some the self-modified code, junk code and code metmorphic to protect the software.

For example,

#define pushSrcDstAssign {__asm push dst __asm push src __asm push ptkn}
#define emitJunkByte4(a, b, c, d) { __asm _emit a __asm _emit b \
__asm _emit c __asm _emit d}

void assign_u32_adjst(PVOID dst, PVOID src)
{
u32 token = 1, *ptkn = &token;

if((unsigned int)dst > 0x100) goto pushdsttEd;
emitJunkByte4(0x80, 0xe8, 0xcc, 0xd4)

pushdsttEd:
pushSrcDstAssign

if((unsigned int)src < 0x80000000)
goto popdsttEd;
emitJunkByte4(0x78, 0x28, 0x34, 0x6e)

popdsttEd:
__asm int 2dh
__asm add esp, 12
}

[schweinsz]

Originally Posted by _xxl

Are you using a frame level parallelism?
Open source?

Yes, I will use the fame level parallelism, but it will be finished after 1.5 week.

[schweinsz]

Originally Posted by schweinsz

What is your anti-virus software? I use the McAfee and it never report virus. I have used some the self-modified code, junk code and code metmorphic to protect the software.

For example,

#define pushSrcDstAssign {__asm push dst __asm push src __asm push ptkn}
#define emitJunkByte4(a, b, c, d) { __asm _emit a __asm _emit b \
__asm _emit c __asm _emit d}

void assign_u32_adjst(PVOID dst, PVOID src)
{
u32 token = 1, *ptkn = &token;

if((unsigned int)dst > 0x100) goto pushdsttEd;
emitJunkByte4(0x80, 0xe8, 0xcc, 0xd4)

pushdsttEd:
pushSrcDstAssign

if((unsigned int)src < 0x80000000)
goto popdsttEd;
emitJunkByte4(0x78, 0x28, 0x34, 0x6e)

popdsttEd:
__asm int 2dh
__asm add esp, 12
}

Besides, the self-generated code is generated on the stack and then it is executed.

[Dark Shikari]

Originally Posted by schweinsz

Besides, the self-generated code is generated on the stack and then it is executed.

Code with an executable stack is inherently dangerous.

Self-modifying code doesn't actually protect the program, since it is trivial (read: takes me less than 5 minutes) to dump a program's memory. But its certainly a great excuse for enabling options that allow one to more easily hide viruses in a program.

Originally Posted by schweinsz

The throughput is about 19mbps with 50% CPU fullness (single thread on a dual-core CPU). Because the DiAVC's development is in early stage, there are many space to be optimized to get a faster decoder, such as the un-optimized MC, transform8x8 and CABAC decoding.

A decoder isn't fast because you say it's fast. It's fast because it is fast. What you described is not fast, it is in fact quite slow. Now, some day, it might be fast, but today it is not.

[schweinsz]

Originally Posted by Dark Shikari

Code with an executable stack is inherently dangerous.

Self-modifying code doesn't actually protect the program, since it is trivial (read: takes me less than 5 minutes) to dump a program's memory. But its certainly a great excuse for enabling options that allow one to more easily hide viruses in a program.A decoder isn't fast because you say it's fast. It's fast because it is fast. What you described is not fast, it is in fact quite slow. Now, some day, it might be fast, but today it is not.

Probably I have a bad core duo cpu, I ever tested the DiAVC on my friend's laptop and found that the DiAVC is faster on a Pentium M 1.73GHz than it is on a core duo CPU of 1.86GHz now. You can try it on your CPU. besides, I use the coreavc to play a movie with H.264 bitstream of 4Mbps, and I found the CPU fullness is more than 70%.

[Dark Shikari]

Originally Posted by schweinsz

You can try it on your CPU.

How, by magically teleporting it from your computer to mine?

[schweinsz]

Originally Posted by _xxl

Are you using a frame level parallelism?
Open source?

I will open some critical algorithm I use in the DiAVC, but I will not open all source.

[schweinsz]

Originally Posted by Dark Shikari

How, by magically teleporting it from your computer to mine?

I have created a web site for the DiAVC decoder.

[Casshern]

Do i understand you correctly: you say that DiAVC is 5 times faster than coreavc on a single processor machine - 19Mbit/s vs. 4 MBit/s?

That would be impressive.

But i remain sceptical and do not like the code-obfuscation. What are you trying to protect? Optimizations to well known-algorithms?
Are you really sure you did not use any open source? Without insinuating anything: Are you aware that the two major reasons for obfuscation are hiding viruses/trojans and/or hiding open-source origin? There are other and better ways to protect intellectual property.

To me it doesn't make sense and i will not beta test an obfuscated program.

regards,
Casshern

[Dark Shikari]

The only "SSE" I see in this program is unbelievably bad compiler-generated assembly...

1000290d:       66 0f 6f c8             movdqa xmm1,xmm0
10002911:       66 0f 74 c8             pcmpeqb xmm1,xmm0

10004c00:       f3 0f 7e 02             movq   xmm0,[edx]
10004c04:       f3 0f 7e 08             movq   xmm1,[eax]
10004c08:       66 0f e0 c1             pavgb  xmm0,xmm1
10004c0c:       49                      dec    ecx
10004c0d:       66 0f d6 00             movq   [eax],xmm0
10004c11:       03 d6                   add    edx,esi
10004c13:       03 c6                   add    eax,esi
10004c15:       85 c9                   test   ecx,ecx
10004c17:       75 e7                   jne    0x10004c00

10008e71:       66 0f 60 c0             punpcklbw xmm0,xmm0
10008e75:       66 0f 6f d0             movdqa xmm2,xmm0
10008e82:       66 0f 60 d0             punpcklbw xmm2,xmm0
10008e8a:       66 0f 70 c2 00          pshufd xmm0,xmm2,0x0

(Well, OK, so I saw an iDCT that didn't look too awful, but that's about it...)

[schweinsz]

Originally Posted by Casshern

Do i understand you correctly: you say that DiAVC is 5 times faster than coreavc on a single processor machine - 19Mbit/s vs. 4 MBit/s?

That would be impressive.

But i remain sceptical and do not like the code-obfuscation. What are you trying to protect? Optimizations to well known-algorithms?
Are you really sure you did not use any open source? Without insinuating anything: Are you aware that the two major reasons for obfuscation are hiding viruses/trojans and/or hiding open-source origin? There are other and better ways to protect intellectual property.

To me it doesn't make sense and i will not beta test an obfuscated program.

regards,
Casshern

No, I never mean that the DiAVC is 5 times faster than the coreavc. The 19Mbps is tested using the bitstream of resolution 1280x720 generated by JM13.0 using the CABAC and Hierarchical B frames. But the 4Mbps bistream is downloaded from the internet and It is 1920x1088 and I dont know the detail about it. The 70% CPU fullness includes the audio decoding, video decoding and rendering.

I never use any open source in the DiAVC. The code-obfuscation
is to hide the anti-debug "int 2dh". I never insert virus in the DiAVC because I want to sell it online in future.

Now I have deleted any anti-debug code in the DiAVC. You can try it.

[schweinsz]

Originally Posted by Dark Shikari

The only "SSE" I see in this program is unbelievably bad compiler-generated assembly...

1000290d:       66 0f 6f c8             movdqa xmm1,xmm0
10002911:       66 0f 74 c8             pcmpeqb xmm1,xmm0

10004c00:       f3 0f 7e 02             movq   xmm0,[edx]
10004c04:       f3 0f 7e 08             movq   xmm1,[eax]
10004c08:       66 0f e0 c1             pavgb  xmm0,xmm1
10004c0c:       49                      dec    ecx
10004c0d:       66 0f d6 00             movq   [eax],xmm0
10004c11:       03 d6                   add    edx,esi
10004c13:       03 c6                   add    eax,esi
10004c15:       85 c9                   test   ecx,ecx
10004c17:       75 e7                   jne    0x10004c00

10008e71:       66 0f 60 c0             punpcklbw xmm0,xmm0
10008e75:       66 0f 6f d0             movdqa xmm2,xmm0
10008e82:       66 0f 60 d0             punpcklbw xmm2,xmm0
10008e8a:       66 0f 70 c2 00          pshufd xmm0,xmm2,0x0

(Well, OK, so I saw an iDCT that didn't look too awful, but that's about it...)

Yes, you are right. I code the motion compensation, IDCT and the deblocking filter using the intrinsic functions (http://msdn.microsoft.com/en-us/libr...3a(VS.80).aspx) and compile it using the VC 2008. I have found it very bad and I will code it using the pure assembly code in future.

[schweinsz]

Originally Posted by Dark Shikari

The only "SSE" I see in this program is unbelievably bad compiler-generated assembly...

(Well, OK, so I saw an iDCT that didn't look too awful, but that's about it...)

There are many places using SSE2 besides motion compensation, idct and deblocking filter. For example, the MV median prediction uses the SSE2.

[Dark Shikari]

Originally Posted by schweinsz

I have found it very bad and I will code it using the pure assembly code in future.

And thus another assembly programmer is enlightened

[roozhou]

I believe VC's inline-assembly is as powerful GCC's.

[CruNcher]

I find it funny schweinsz that you know you can't protect your software but still try it and create many interoperability problems (i would understand it though if you would provide that system) with that in the way, why not just give up and accept how it is ?, at least for the current Hardware architecture
The energy you invested into that lines for the extra protection are totaly lost in the end anyways and you knew it from the beginning so what did you win where is the sense behind this ?