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

[Keiyakusha]

Originally Posted by schweinsz

btw: I can not get to the picture and the video you post.

Sorry, I don't understand. You can't download it?
EDIT: if so - try this...

By the way, with Haali renderer this is not really a problem. At first I just not realized that DiAVC outputs only YV12. Haali accepts only YUY2, so I just need additional transform filter.

[schweinsz]

Originally Posted by Keiyakusha

Sorry, I don't understand. You can't download it?
EDIT: if so - try this...

By the way, with Haali renderer this is not really a problem. At first I just not realized that DiAVC outputs only YV12. Haali accepts only YUY2, so I just need additional transform filter.

Yes, I can't download it. I get it now from your new address. Thank you very much.

[Astrophizz]

Good news, I did some test on longer clips (I had been using ~30 second ones before) and DiAVC is the fastest for me! This is really impressive.

I get the blinking too and videos start out green (Haali renderer). Seeking causes the image to freeze also.

[Avish]

64-bit XP is not supported yet, right?? Coz MPC-HC just hangs when I try to play anything with DiAVC.

[Kurtnoise]

Originally Posted by Keiyakusha

Can't get it work under win7. Every app that trying to use it just hangs so I even can't construct any graph...

works for me only w/ the madVR or VMR9 as renderer...

[schweinsz]

Originally Posted by Avish

64-bit XP is not supported yet, right?? Coz MPC-HC just hangs when I try to play anything with DiAVC.

Yes, there is only 32-bit version now. I must re-code all assembly code for 64-bit version in future.

[Kurtnoise]

@schweinsz : any chance to add lossless contents support in diAVC ?

[schweinsz]

Originally Posted by Kurtnoise

@schweinsz : any chance to add lossless contents support in diAVC ?

Adding lossless contents support is not a complex task. But I'll start work on it after all other more important tasks are finished, such as improving the speed, filter bug fix, compatibility, 64-bit version, etc.

[Dark Shikari]

Originally Posted by schweinsz

Adding lossless contents support is not a complex task. But I'll start work on it after all other more important tasks are finished, such as improving the speed, filter bug fix, compatibility, 64-bit version, etc.

Adding 64-bit assembly is a huge task, especially if you don't intend to do what x264 does and use a 32-bit/64-bit abstraction system. Lossless is a couple hours at most by comparison.

Also, note there are two lossless modes: the old one (profile_idc=144) and the new one (profile_idc=244). Old one is just replacing dct with a direct subtraction, while the new one involves some pixel prediction and thus is slightly trickier.

[schweinsz]

Originally Posted by Dark Shikari

Adding 64-bit assembly is a huge task, especially if you don't intend to do what x264 does and use a 32-bit/64-bit abstraction system. Lossless is a couple hours at most by comparison.

After I finish the DiAVC, I'll do some works to improve the x264.

Originally Posted by Dark Shikari

Also, note there are two lossless modes: the old one (profile_idc=144) and the new one (profile_idc=244). Old one is just replacing dct with a direct subtraction, while the new one involves some pixel prediction and thus is slightly trickier.

I know this, but that only add some intra-prediction function, and replace some function pointer of intra-prediction.

[Dark Shikari]

Originally Posted by schweinsz

After I finish the DiAVC, I'll do some works to improve the x264.

I was referring to the system for having both types of assembly; if you have to copy/paste all the assembly to get 32-bit and 64-bit versions it gets quite messy.

Originally Posted by schweinsz

I know this, but that only add some intra-prediction function, and replace some function pointer of intra-prediction.

Yup, it's not too complicated.

[schweinsz]

Originally Posted by Dark Shikari

I was referring to the system for having both types of assembly; if you have to copy/paste all the assembly to get 32-bit and 64-bit versions it gets quite messy.

Yes, I have understanded you. I will code all 64-bit assembly code to get fastest speed. Actually the 64-bit have more things to do because we can take a full use of the 64-bit general register.

[Dark Shikari]

Originally Posted by schweinsz

Yes, I have understanded you. I will code all 64-bit assembly code to get fastest speed. Actually the 64-bit have more things to do because we can take a full use of the 64-bit general register.

But on WIN64 you have the atrocious API that requires callee-save xmm6-xmm15, which seriously limits what you can do (since if you can get a 10 cycle speedup by using 8 more registers, you've probably lost performance because of the loads/stores...).

[schweinsz]

Originally Posted by Dark Shikari

But on WIN64 you have the atrocious API that requires callee-save xmm5-xmm15, which seriously limits what you can do (since if you can get a 10 cycle speedup by using 8 more registers, you've probably lost performance because of the loads/stores...).

Oh, VERY bad news for me. Thank you very much. I don't know this limitation ever.

[Dark Shikari]

Originally Posted by schweinsz

Oh, VERY bad news for me. Thank you very much. I don't know this limitation ever.

The Windows 64-bit API is very weird and you should do some research on it before you start writing assembly code.

You should look at common/x86/x86inc.asm in x264; it contains macros for handling of the three calling conventions (32-bit, 64-bit, win64). Win64 is extremely weird and is completely incompatible with all other 64-bit calling conventions (which use the standard one).

In addition to the callee-save XMM registers, it also has a different general-purpose register calling convention, probably just to annoy people.

And the above is a typo, it's xmm6-xmm15 that are callee-save.

[squid_80]

The most annoying thing is the exception handling restrictions - if you touch the stack pointer you are supposed to set up a frame pointer, have properly formed epilogs/prologs and make sure the special exception handling data is included in the binary. (I say "supposed to" because it will still run without it but if an exception/crash happens the app will be immediately terminated, even if an exception handler is meant to catch it.)

MS gets the middle finger for keeping rsi/rdi non-volatile as well.

[schweinsz]

Originally Posted by squid_80

The most annoying thing is the exception handling restrictions - if you touch the stack pointer you are supposed to set up a frame pointer, have properly formed epilogs/prologs and make sure the special exception handling data is included in the binary. (I say "supposed to" because it will still run without it but if an exception/crash happens the app will be immediately terminated, even if an exception handler is meant to catch it.)

MS gets the middle finger for keeping rsi/rdi non-volatile as well.

The DiAVC is designed to prevent from debugging by the use of "exception handle".

[schweinsz]

Which splitter can split the dmb contents in http://samples.mplayerhq.hu/V-codecs/h264/dmb/? I found that those bitstreams crash the haali media splitter.

[slavickas]

you may try MPC-HC splitter, though havent tested those files myself

[schweinsz]

Where can I get some H.264 bitstreams with mbaff and weighted prediction? The jm can't produce the bitstreams.