Announcing Project Rémoulade [DivX H.264 codec]

[DigitAl56K]

It is with great pleasure that I can finally unveil Project Rémoulade (http://labs.divx.com/ProjectRemoulade) and its first release, the DivX H.264 Decoder!

DivX H.264 Decoder Beta 1 decodes H.264 High, High 10, and High 4:2:2 profile streams including full interlace support and is multithreaded for accelerated decoding on up to 8 CPUs. Based on our own testing, we believe that it may be the fastest decoder currently available, but we'd like to get your feedback too.

We're looking for people interested in testing this beta as well as future releases from the project. We're starting out with a closed group with limited capacity and over the coming hours/days we'll be sending out invitations to participate. Although I plan to contact a number of the forum members here at Doom9 with invitations you will need a free account at DivX Labs (http://labs.divx.com) in order to join the Project Rémoulade group. If you don't get an invitation in the next 24 hours (please be patient) and you would like to participate it's important that you follow the instructions at the bottom of the Beta 1 article (i.e. create a DivX Labs account (http://labs.divx.com/user/register) and send me a PM (http://labs.divx.com/privatemsg/msgto/11) via DivX Labs with your details). Note that I will also reply to PM's through Doom9 but without your DivX Labs user name it's impossible to add you to the group.

[Dark Shikari]

DivX H.264 Decoder Beta 1 decodes H.264 High, High 10, and High 4:2:2 profile streams including full interlace support and is multithreaded for accelerated decoding on up to 8 CPUs. Based on our own testing, we believe that it may be the fastest decoder currently available, but we'd like to get your feedback too.Finally, an alternative to CoreAVC! Better yet it, supports formats that even CoreAVC doesn't (and so far have had generally very minimal support overall). This could lead to more encoders supporting those formats. Good work!

We're looking for people interested in testing this beta as well as future releases from the project. We're starting out with a closed group with limited capacity and over the coming hours/days we'll be sending out invitations to participate. Although I plan to contact a number of the forum members here at Doom9 with invitations you will need a free account at DivX Labs (http://labs.divx.com) in order to join the Project Rémoulade group. If you don't get an invitation in the next 24 hours (please be patient) and you would like to participate it's important that you follow the instructions at the bottom of the Beta 1 article (i.e. create a DivX Labs account (http://labs.divx.com/user/register) and send me a PM (http://labs.divx.com/privatemsg/msgto/11) via DivX Labs with your details).I look forward to participating :p

[kosmonaut]

Well, it's strange to have to think about it, but does this thread need to moved over to the H.264/AVC forum? ;)

Big kudos to Al for getting everything in shape to share. We do really look forward to your feedback, good and bad, as we recognize this is just the first step in what is sure to be a long process, to get to where we want DivX H.264 ultimately to be. We surely know we're stepping into a crowded area, but our goal is to create technologies and tools that benefit everybody in the community. Hopefully we won't make too many mistakes along the way, but I'm very confident you all will let us know when we do!

If anybody has any questions don't hesitate to contact DigitAl56k or myself, or come to DivX Labs and let us know directly.

[SeaBass]

tomorrow we will add an email alias for the project to make it easier for people sign up.

It will be projectremoulade at divx dot com. That way I don't have to keep reading Al's PMs :P and we can all add users to the project.

[KEROLiUKAS]

tomorrow we will add an email alias for the project to make it easier for people sign up.

It will be projectremoulade at divx dot com. That way I don't have to keep reading Al's PMs :P and we can all add users to the project.
Haha, you sneaky Bass.

Btw, anyone hungry for a screenshot atleast, check here:
http://connunity.com/forum/viewtopic.php?t=157

[Dark Shikari]

I notice you intentionally didn't use VBV or AQ in your x264 test encode...

<Dark_Shikari> apparently DivX beta decoder is a LOT better than CoreAVC the more threads you add (at least according to their graphs) (for 4 or 8 cores)
<Dark_Shikari> for single CPU difference is marginal
<Dark_Shikari> oddly, they disabled AQ when encoding their streams
<pengvado> they have a deblocking optimization that depends on constant qp. </cynic>

[DigitAl56K]

We didn't intentionally not use them, we just needed to create a couple of test clips specifically for the beta (rather than re-use the clips we run during development), and I didn't set those options.

We added you to the Project Rémoulade group, and you should have access to the Beta 1 download from the group homepage. Please test the decoder for yourself and let us know how you get on, the more feedback the better :)

Note that the last chart on our page is specifically around scalability, and was run on an 8-core box, but CoreAVC only supports 4 threads (shown on the chart). I will edit the labs article now to make that clearer. If you want to compare how the DivX decoder scales with multi-threading look at the single vs dual core charts above. Again, you can also run your own tests!

[Dark Shikari]

We didn't intentionally not use them, we just needed to create a couple of test clips specifically for the beta (rather than re-use the clips we run during development), and I didn't set those options.--aq-strength 0 was explicitly set, unless you're just saying that you weren't the one to set the options :p

We added you to the Project Rémoulade group, and you should have access to the Beta 1 download from the group homepage. Please test the decoder for yourself and let us know how you get on, the more feedback the better :)Thanks, I'll grab a copy!

[KEROLiUKAS]

--aq-strength 0 was explicitly set, unless you're just saying that you weren't the one to set the options :p
Thanks, I'll grab a copy!
Could it have been defaults?

[DigitAl56K]

--aq-strength 0 was explicitly set, unless you're just saying that you weren't the one to set the options :p

Oops! I had forgot that I did that, it was an accidental result of re-using some previously created batch scripts! Looking forward to your results with aq :)

[KEROLiUKAS]

^ Hehe, you're only human, everybody forgets... :P

I'm not too good with these encoding terms, so is there a chance that aq is going to alter the results in a big way?

[Dark Shikari]

This is actually quite impressive.

I tested it on my ultimate torture clip: A 2160p (!!) 50fps 100 mbps video (http://mirror05.x264.nl/Dark/HighRes.mkv).

On a Core 2 Duo 2Ghz T7200:

DivX FPS: 8.7
CoreAVC FPS: N/A, it crapped out when I tried to TimeCodec it.
FFDshow-Tryouts rev1355 FPS: 3.7

:cool:

I'm also getting steady 60-75% CPU usage for decoding 10 megabit 1080p "300". Quite nice. My next step will be to throw absolutely bizarre H.264 streams at it until it breaks.

I'm not too good with these encoding terms, so is there a chance that aq is going to alter the results in a big way?Doubtful.

[KEROLiUKAS]

This is actually quite impressive.

I tested it on my ultimate torture clip: A 2160p (!!) 50fps 100 mbps video (http://mirror05.x264.nl/Dark/HighRes.mkv).

On a Core 2 Duo 2Ghz T7200:

DivX FPS: 8.7
CoreAVC FPS: N/A, it crapped out when I tried to TimeCodec it.
FFDshow-Tryouts rev1355 FPS: 3.7

:cool:

I'm also getting steady 60-75% CPU usage for decoding 10 megabit 1080p "300". Quite nice.

Doubtful.
Cheers to those results, this will be big in the future of h.264.

I'm going to sleep now, you have fun playing with your codec, hehe.


Regards,
Karolis.

[Dark Shikari]

Ugh... first bit of dissatisfaction.

DivX's decoder incorrectly ignores the header bit that states "qp0 should be interpreted as lossless." Unfortunately, this means that despite the DivX decoder's incredibly fast CABAC decoding it is completely useless for dealing with lossless content. Both CoreAVC and FFDshow can handle the lossless content correctly.

I would hope this would not have been ignored given the implementation of such relatively obscure features like High 10 and 4:2:2, which are much more difficult to implement than lossless, which literally consists of a couple dozen lines of code in order to bypass iDCT/dequant (basically trivial).

[DigitAl56K]

DivX's decoder incorrectly ignores the header bit that states "qp0 should be interpreted as lossless."

Thanks! I'll log it.

Please keep in mind when you're testing that this is beta 1, whereas the other decoders you've been using have been available publicly for quite some time - i.e. we do expect some issues to come up.

We'll nail as many as possible as quickly as possible and get beta 2 up for you guys.

[Dark Shikari]

Thanks! I'll log it.

Please keep in mind when you're testing that this is beta 1, whereas the other decoders you've been using have been available publicly for quite some time - i.e. we do expect some issues to come up.Of course :) I was just hoping that you weren't planning to omit the feature :p

One general note about lossless: the original lossless profile specified has been removed from the H.264 standard (but everyone still uses it). In its place, they added a new one which uses a limited form of pixel prediction, making it slightly better (but not nearly as good as if it used a good prediction method, like paeth/median). As far as I can tell, nobody supports this yet, so it isn't particularly important to implement it.

Now, the question comes up: how do you tell the difference between these two lossless profiles? The answer is the profile ID--encoders should correctly write the ID, so if you want to include support for both lossless modes, you can check the profile ID to check which one should be used.

[Dark Shikari]

Hmm, it appears there's still a lot of room for improvement here. As far as I can tell, DivX's decoder contains no SSE3, no SSSE3, and no SSE4 :p

SSSE3 is useful for palignr (luma MC) and pmaddubsw (chroma MC), for example.

There's also some general serious fail in the code, such as emms being put after some assembly functions, which wastes clocks since floating point code is never or almost never used in a decoder (emms should be put before float functions, not after asm functions). There's also the fact that I'm seeing the frame pointer being used, in other words the code was compiled without -fomit-frame-pointer or its <insert compiler name here> equivalent.

I also get the feeling from reading some extremely bad assembly in here that this was built using an autovectorizing compiler of some sort. For example, an 8x7 VSAD (for adaptive deinterlacing, I assume) that keeps its sum in a GPR and repeatedly adds to it from MMX registers (WTF?!). That must be slowing down the function by at least a factor of 3 or 4.

[_xxl]

Is DivX h.264 decoder free?

[DigitAl56K]

Is DivX h.264 decoder free?

The beta version is free. The final pricing model hasn't been fully decided yet so I won't be able to answer that definitively until later in the year.

[kosmonaut]

Is DivX h.264 decoder free?

The decoder is currently only available to participants in the beta test. You can join at DivX Labs (http://labs.divx.com/ProjectRemoulade).

[sparky]

Hmm, it appears there's still a lot of room for improvement here. As far as I can tell, DivX's decoder contains no SSE3, no SSSE3, and no SSE4 :p

SSSE3 is useful for palignr (luma MC) and pmaddubsw (chroma MC), for example.

This is correct. To my knowledge, CoreAVC does not contain any SSE3, either. (My knowledge could be outdated) We will add support of these instruction sets eventually.

There's also some general serious fail in the code, such as emms being put after some assembly functions, which wastes clocks since floating point code is never or almost never used in a decoder (emms should be put before float functions, not after asm functions). There's also the fact that I'm seeing the frame pointer being used, in other words the code was compiled without -fomit-frame-pointer or its <insert compiler name here> equivalent.

I also get the feeling from reading some extremely bad assembly in here that this was built using an autovectorizing compiler of some sort. For example, an 8x7 VSAD (for adaptive deinterlacing, I assume) that keeps its sum in a GPR and repeatedly adds to it from MMX registers (WTF?!). That must be slowing down the function by at least a factor of 3 or 4.

Does not sound familiar at all. Care to copy/paste the code?

The decoder is part of a bigger source tree, there was no effort to "prune" dead code for this release. You could be seeing some assembly that is not used by the H.264 decoder. For example, ASP encoder does use floating point. That should cover most instances of 'emms'. But you have a good point.

[Dark Shikari]

This is correct. To my knowledge, CoreAVC does not contain any SSE3, either. (My knowledge could be outdated) We will add support of these instruction sets eventually.Yup, I don't think it does. I have seen use of lddqu in Elecard though, and FFDshow of course uses SSSE3 for luma/chroma MC.The decoder is part of a bigger source tree, there was no effort to "prune" dead code for this release. You could be seeing some assembly that is not used by the H.264 decoder. For example, ASP encoder does use floating point. That should cover most instances of 'emms'. But you have a good point.Ah, that would explain why I found an MPEG-4 iDCT in there! :p

Here's the code I found:

1008962e: 55 push %ebp
1008962f: 89 e5 mov %esp,%ebp
10089631: 81 ec 08 00 00 00 sub $0x8,%esp
10089637: 89 7d f8 mov %edi,0xfffffff8(%ebp)
1008963a: 31 c9 xor %ecx,%ecx
1008963c: 8b 45 08 mov 0x8(%ebp),%eax
1008963f: 8b 7d 0c mov 0xc(%ebp),%edi
10089642: 01 f8 add %edi,%eax
10089644: 0f 6f 00 movq (%eax),%mm0
10089647: 0f 6f 0c 38 movq (%eax,%edi,1),%mm1
1008964b: 0f f6 c1 psadbw %mm1,%mm0
1008964e: 0f 7e c2 movd %mm0,%edx
10089651: 01 d1 add %edx,%ecx
10089653: 8d 04 78 lea (%eax,%edi,2),%eax
10089656: 0f 6f 00 movq (%eax),%mm0
10089659: 0f f6 c8 psadbw %mm0,%mm1
1008965c: 0f 7e ca movd %mm1,%edx
1008965f: 01 d1 add %edx,%ecx
10089661: 01 f8 add %edi,%eax
10089663: 0f 6f 08 movq (%eax),%mm1
10089666: 0f f6 c1 psadbw %mm1,%mm0
10089669: 0f 7e c2 movd %mm0,%edx
1008966c: 01 d1 add %edx,%ecx
1008966e: 0f 6f 04 38 movq (%eax,%edi,1),%mm0
10089672: 0f 6f 0c 78 movq (%eax,%edi,2),%mm1
10089676: 0f f6 c1 psadbw %mm1,%mm0
10089679: 0f 7e c2 movd %mm0,%edx
1008967c: 01 d1 add %edx,%ecx
1008967e: 8d 04 78 lea (%eax,%edi,2),%eax
10089681: 0f 6f 04 38 movq (%eax,%edi,1),%mm0
10089685: 0f f6 c8 psadbw %mm0,%mm1
10089688: 0f 7e ca movd %mm1,%edx
1008968b: 01 d1 add %edx,%ecx
1008968d: 0f 6f 0c 78 movq (%eax,%edi,2),%mm1
10089691: 0f f6 c1 psadbw %mm1,%mm0
10089694: 0f 7e c2 movd %mm0,%edx
10089697: 01 d1 add %edx,%ecx
10089699: 31 c0 xor %eax,%eax
1008969b: 8b 55 10 mov 0x10(%ebp),%edx
1008969e: d1 e2 shl %edx
100896a0: 39 d1 cmp %edx,%ecx
100896a2: 0f 9e c0 setle %al
100896a5: 0f 77 emms
100896a7: 8b 7d f8 mov 0xfffffff8(%ebp),%edi
100896aa: 89 ec mov %ebp,%esp
100896ac: 5d pop %ebp
100896ad: c3 ret

Akupenguin simplified this to the following (using x264 nasm syntax):
cglobal vsad, 2,3
lea r2, [r1*3]
movq mm0, [r0]
movq mm1, [r0+r1]
movq mm2, [r0+r1*2]
movq mm3, [r0+r2]
lea r0, [r0+r1*4]
movq mm4, [r0]
movq mm5, [r0+r1]
movq mm6, [r0+r1*2]
psadbw mm0, mm1
psadbw mm1, mm2
psadbw mm2, mm3
psadbw mm3, mm4
psadbw mm4, mm5
psadbw mm5, mm6
paddd mm0, mm1
paddd mm2, mm3
paddd mm4, mm5
paddd mm0, mm2
mov r2, r2m
paddd mm0, mm4
shl r2
xor eax, eax
movd r1, mm0
cmp r1, r2
setle al
ret

I'm also noticing some other interesting stuff--you chose to put dequant as part of the iHCT process instead of as part of the entropy decoding process.

(This would be a whole lot easier if we could get an unstripped debug build, but like that'll ever happen... :p)

[sparky]

Okay. That code is very old and it is part of ASP deblocking.

This would be a whole lot easier if we could get an unstripped debug build, but like that'll ever happen...

that'll take all the challenge out of it, won't it? We only give unstripped debug build to employees, sorry. You're lucky that Al forgot to ASProtect the filter :P

BTW do you have any lossless files we could test?

[Dark Shikari]

that'll take all the challenge out of it, won't it?Perhaps, but running oprofile in order to identify specific non-obvious functions (e.g. CABAC) does get annoying after a while... :p

[DigitAl56K]

Hey guys,

Although I don't like to do so, I feel I do need to point out that the license with this software does not allow reversing, decompiling, disassembling, and so forth.

Dark Shikari: Your comments are welcome, but let's avoid a public disassembly of the binaries (I do realize we asked you to post a code snippet earlier). You can contact sparky by PM or e-mail for lower-level development issues if you like.

Thanks for your understanding :)

[Gabriel_Bouvigne]

Fgm ?

[Dark Shikari]

Hey guys,

Although I don't like to do so, I feel I do need to point out that the license with this software does not allow reversing, decompiling, disassembling, and so forth.

Dark Shikari: Your comments are welcome, but let's avoid a public disassembly of the binaries (I do realize we asked you to post a code snippet earlier). You can contact sparky by PM or e-mail for lower-level development issues if you like.

Thanks for your understanding :)I was going to avoid posting all actual disassembly until you guys asked me to, and I'd be happy to not post anything else (that was what I was going to do anyways! :p). I fully understand not posting code particularly in the case that the beta isn't actually public yet. If you want me to elaborate on any more general lower-level comments in a manner that requires you to see the code I'm referring to, I'd be happy to PM it on request instead of post it.

Of course, prohibiting "disassembly" in a license is not merely completely unenforceable (both legally and practically) but totally silly given how trivial disassembly is (objdump -d). And if you think that people actually obey rules about not disassembling programs, well, you might want to look at certain striking similarities between some code in CoreAVC, ffmpeg, and x264... ;)
Fgm ?Good question. Support for FGM in DivX would pave the way for x264 support of FGM.

[DigitAl56K]

Thanks Dark Shikari. Instead of discussing the intricacies of dissassembly and software licenses, let me just say that this will save me hours of thoroughly entertaining chit chat with our legal team in the morning ;)

Gabriel: We don't have FGM yet. Perhaps a discussion of features the x264 team is interested in working on and the order that they want to accomplish them might make for an interesting (but separate) thread. It's important to keep in mind that we're in the middle of preparing the future generation of DivX right now and we often can't elaborate too much on our roadmap ("Hey! Here's a super-fast H.264 decoder. Surprise!"), but there are times where we can aim to align our work to support other projects. If we can understand your priorities we can build a better codec. Thanks for your work on LAME btw.

[Dark Shikari]

Heh, after more glancing around dissassembly my overall comment would be that if DivX has already managed to get faster than CoreAVC with this, lets just say they have a very wide margin in which to improve it ;). I suspect most of the efficiency here must be from overall code optimization rather than particularly ingenious ASM, which demonstrates yet again the sheer complexity of H.264 and how much good coding practices matter for performance. An oprofile of ffmpeg is a great way to see this; a massive amount of time is spent in many pure C functions (fill_caches, etc). Whatever design improvements DivX made in order to avoid a lot of this overhead: good job, the result is quite impressive.

The most important thing here is that there's finally a competitor for CoreAVC... perhaps this will force the Core guys to get working :p

Edit: Perhaps FFDshow might have been used a bit too much as a model during DivX development...
22:19 < checkers> apparently it gives bit identical output to ffdshow
22:19 < checkers> including errors in ffdshow decoding :|

[BetaBoy]

The most important thing here is that there's finally a competitor for CoreAVC... perhaps this will force the Core guys to get working :p

Done.... CoreAVC 2.0 on the devel deck. But as I said in the other thread its good to see DivX with something 'new' and its great to have competition it only makes for better products.

[Inventive Software]

Wow! Nice going guys. Finally, an alternative to CoreAVC. Hows interlacing handled? I know it's only been a day, but if it can handle all the streams bob0r keeps throwing at CoreAVC and failing, then you lot are clear winners.

[CiNcH]

Got some PAFF samples from DVB broadcasts working through GraphStudio (with Haali Media Splitter). DVBViewer with its demuxer crashes for the time being...

http://www.dvbviewer.info/forum/index.php?act=attach&type=post&id=14061

[sparky]

Heh, after more glancing around dissassembly my overall comment would be that if DivX has already managed to get faster than CoreAVC with this, lets just say they have a very wide margin in which to improve it ;). I suspect most of the efficiency here must be from overall code optimization rather than particularly ingenious ASM, which demonstrates yet again the sheer complexity of H.264 and how much good coding practices matter for performance.

Come on, our ASM isn't nearly as bad as you say :) (but if you have any specific ideas how to improve it by a very wide margin, feel free to shoot a PM )

Edit: Perhaps FFDshow might have been used a bit too much as a model during DivX development...

FFDshow hasn't been used at all. The decoder produces output that's bitexact with JM.

[Inventive Software]

FFDshow hasn't been used at all. The decoder produces output that's bitexact with JM.

So it's just sheer luck that the decoder gives the same errors that ffdshow does? If so, would be good to kick errors on both sides.

[sparky]

Can you give an example?

[Dark Shikari]

Come on, our ASM isn't nearly as bad as you say :) (but if you have any specific ideas how to improve it by a very wide margin, feel free to shoot a PM )I suspect a lot of the "bad" ASM is old stuff that isn't used in the decoder, due to (as you said) the total mess of a source tree here, with old ASP stuff and so forth.

I'll probably go through it with oprofile in a few days to find what's actually used and see if its really as bad as the initial unused functions demonstrated, or if those are just outliers :p

[DigitAl56K]

Once again, this is beta 1, i.e. not yet perfect! We will clean up the project sources as we move closer to a release.

I would look at it this way: Despite the flaws you think it may have if the decoder is already extremely fast and you believe it still has room for improvement then that is a good thing. If you think the decoder could be more efficient, but it is already outperforming the other decoders, then they could be more efficient still. Maybe we can try to be less negative unless it's really warranted :)

BTW - I've just gone through my PM's and a whole bunch of people should now have access to the download.

@BetaBoy: Agreed. The choice of two powerful H.264 decoders is better than one :)

On DVBViewer: Seems to be a common problem there, we'll take a look at it. We have a few DVBViewer users in the Rémoulade group now.

[Dark Shikari]

Despite any flaws you think it may have, if the decoder is already extremely fast and you believe it still has room for improvement then that is a good thing. Also, if you think the decoder could be more efficient, but it is already outperforming the other decoders, then they could be more efficient still.That was actually the entire point of my posts to begin with :)

I was surprised that it managed to be significantly faster than Core given the lack of optimization on many levels, which obviously means that if those missing optimizations are added, it'll be even better. And everyone benefits from that.

[ChronoCross]

Just remember to take it with a grain of salt because we all know about Divx's "incredible speed increases" in their encoder were proven to be nothing but marketing hype. :devil:

[DigitAl56K]

Wow, that's quite a flame! hehe :)

Please sign up at Labs and send me your account name so I can get a copy into your hands ;)

[ChronoCross]

Wow, that's quite a flame! hehe :)

Please sign up at Labs and send me your account name so I can get a copy into your hands ;)

What can I say, I'm a skeptic. PM sent.

[Ajax_Undone]

Oh my I just might **** and die in the most embarrassing way so Digit how much will this little add-on cost me the consumer.... Once Officially released that is...

[DigitAl56K]

Please don't do that. It may be embarrassing and could lead to death. As I mentioned earlier, pricing hasn't been decided yet. We'll be making that decision a little later in the year.

[Ajax_Undone]

no prob bro by the way sent a pm about 10 min ago... :)

ps I didnt mean to ask I was just curious and hadnt read the whole post just as yet

[Ajax_Undone]

Will the Dr or Converter be updated to use this codec or has this been even discussed? Or are you guy making a new encoder app all together...

[DigitAl56K]

I can't elaborate too much on that yet, Ajax, but when the time comes you'll see more products released through Project Rémoulade at DivX Labs, and of course I'll also post updates here at Doom9.

[Henrikx]

Is a Linux version planned?

[unskinnyboy]

Very good news, and long awaited. What I am awaiting with even more eagerness is the unveiling of the encoder bit of Project Rémoulade. Will have to see how that compares to the other H.264/AVC encoders, namely, x264, Ateme etc. Would we see some DivX-certified AVC standalone players soon then? Let's wait and see...

[IgorC]

Here Divx decoder has comparable speed with last version of fastest H.264 decoder CoreAVC 1.7

CPU E2160
Timecodec. Render: Null.

1080p (300.2006.1080p.BluRay.DTS.x264-CtrlHD.sample.noaudio.mkv) . Divx H.264 decoder crashes in MPC while seeking or repetitve playback
CoreAVC
User: 5s, kernel: 0s, total: 5s, real: 33s, fps: 308.5, dfps: 48.5

Divx
User: 6s, kernel: 0s, total: 6s, real: 36s, fps: 234.5, dfps: 43.4

720x304p x264 at 980 kbits
CoreAVC
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 1315.4, dfps: 336.4

Divx
User: 0s, kernel: 0s, total: 0s, real: 3s, fps: 1248.5, dfps: 314.7

Dirty_1080p QT H.264 CAVLC trailer
Divx
User: 22s, kernel: 0s, total: 22s, real: 69s, fps: 161.1, dfps: 51.8

CoreAVC
User: 17s, kernel: 0s, total: 17s, real: 60s, fps: 208.4, dfps: 59.2


720x304p_v2 sample
divx
User: 2s, kernel: 0s, total: 2s, real: 10s, fps: 1414.2, dfps: 353.6

coreavc
User: 2s, kernel: 0s, total: 2s, real: 9s, fps: 1515.9, dfps: 370.5


20 Mbits 1080p
Coreavc
User: 13s, kernel: 0s, total: 13s, real: 55s, fps: 234.3, dfps: 56.2

Divx
User: 15s, kernel: 0s, total: 16s, real: 61s, fps: 191.3, dfps: 50.7

I also checked CPU load during playback in MPC. Divx charged CPU slightly more than CoreAVC 1.7 . But Divx decoder did nothing bad at all and enough close to CoreAVC. Smooth 1080p playback and multithread support are great. On that 2K 100 Mbit sample has borked output and only at 7.6 fps.

[DigitAl56K]

Thanks for posting your results. That's a little larger of a difference than we saw, I'm interested in some screenshots of CPU-Z on your box if you don't mind.

I noticed you used the null renderer, how do things play out with the a renderer attached?