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

DigitAl56K

15th May 2008, 05:34

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

15th May 2008, 05:40

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

15th May 2008, 05:58

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

15th May 2008, 06:02

KEROLiUKAS

15th May 2008, 06:11

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

15th May 2008, 06:32

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

15th May 2008, 06:49

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

15th May 2008, 06:50

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

15th May 2008, 06:53

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

15th May 2008, 06:53

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

15th May 2008, 06:56

^ 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

15th May 2008, 06:58

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

15th May 2008, 07:02

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

15th May 2008, 07:16

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

15th May 2008, 07:26

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

15th May 2008, 07:38

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

15th May 2008, 07:57

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

15th May 2008, 08:30

Is DivX h.264 decoder free?

DigitAl56K

15th May 2008, 08:34

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

15th May 2008, 08:34

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

15th May 2008, 08:47

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

15th May 2008, 08:52

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

15th May 2008, 09:25

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

15th May 2008, 09:28

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

15th May 2008, 09:45

Gabriel_Bouvigne

15th May 2008, 09:53

Fgm ?

Dark Shikari

15th May 2008, 09:54

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

15th May 2008, 10:33

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

15th May 2008, 16:17

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

15th May 2008, 16:24

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

15th May 2008, 17:11

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

15th May 2008, 18:04

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

15th May 2008, 18:15

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

15th May 2008, 20:27

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

15th May 2008, 20:30

Can you give an example?

Dark Shikari

15th May 2008, 20:58

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

15th May 2008, 21:43

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

15th May 2008, 21:44

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

15th May 2008, 23:42

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

15th May 2008, 23:55

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

16th May 2008, 02:03

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

16th May 2008, 07:06

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

16th May 2008, 07:39

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

16th May 2008, 07:49

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

16th May 2008, 08:11

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

16th May 2008, 08:23

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

16th May 2008, 08:42

Is a Linux version planned?

unskinnyboy

16th May 2008, 09:06

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

16th May 2008, 09:44

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

16th May 2008, 10:12

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?

CiNcH

16th May 2008, 10:55

Is the whole H.264 thing now a result of the MainConcept aggregation?

MainConcept is a pretty good H.264 decoder BTW. It may eat up quite some CPU time but it is the most compatible software-only decoder when it comes to integrating it into a streaming environment.

I will have to work out another test with DVBViewer (and PAFF streams) and different H.264 decoders and check/compare DVBSource (buffers/queues) and renderer (jitter, frame dropps) behaviour. [rule 6 material deleted] Think that a streaming environment (push graph scenario) can sometimes be tricky compared to file playback (mostly pull graph scenario).

Shinigami-Sama

16th May 2008, 11:06

geez, problems with dbviewer everywhere, sounds like they're the ones that really need to pull up their socks eh?

looking forwards to a good product like this in divx, its been a while since something big and nice has happened

and just remember, don't let the marketing guys set your price, look at what happened with slysoft, nearly priced themselves out of doom9

CiNcH

16th May 2008, 11:13

"Problem with DVBViewer" here is completely different...

DivX decoder has problems with DVBViewer's DVBSource, CyberLink and Elecard demuxer.

And the jitter I have reported may not even be related to DVBViewer at all: http://forum.doom9.org/showpost.php?p=1138365&postcount=3803

sparky

16th May 2008, 11:27

Sergey A. Sablin

16th May 2008, 13:03

totally OT: just curious, who's tagging divx related thread with "coreavc"? :) (check "Tags" field above "Quick Reply")

the_corona

16th May 2008, 15:47

Very interested, although performance isn't quite there yet.......curious how divx labs can post such radically different results than I get (specific settings that help their decoder and hurt CoreAVC?).

Here's some tests I performed, without filenames for "obvious" reasons (bah...doing SS since formatting is a nightmare here.....):

http://img233.imageshack.us/img233/1765/divxbenchmarkbr2.png

Edit: CPU-Z screenshot (guess useless but whatever)
http://img508.imageshack.us/img508/8563/cpuzoz4.png

Edit 2: OK retested FFDshow with latest rev....I'm impressed, gotten quite a bit faster since I last updated apparently (I switched back to old just to make sure I wasn't testing it differently.....but it is reproducable!) Congrats to FFDShow (and FFMpeg) Team!

_xxl

16th May 2008, 16:01

Why did you use an old ffdshow version?

the_corona

16th May 2008, 16:05

Why did you use an old ffdshow version?

Because that's what I had installed on this box and I thought it doesn't really matter....all I really wanted to compare was CoreAVC/Divx.

I can retest the clips with the latest revision, but do you think there is a point?

Edit: updated first post with newer versions.

DigitAl56K

16th May 2008, 16:06

the_corona: Yesterday I had to repack our binary. I am wondering if it has affected performance. Stay tuned - I will check it out this morning.
On DVBViewer: Reports are that Beta 1 is not working with live streams which may or may not be related to connections to the splitters mentioned by CiNcH. We'll be looking into that shortly.

Ice =A=

16th May 2008, 17:47

So do I see this correctly:
With independent tests CoreAVC ist very considerably faster than DivX (Beta1)?!

I personally would have no problem with that, given the early development state of DivX h264 and the fact that CoreAVC is a full price product and currently holds the record for the fastest h264 software decoding.

However, since the numbers the DivX guys posted are that much more in favour of DivX, I can not stop to wonder and maybe feel a little kidded...

IgorC

16th May 2008, 18:05

D56k

Here is my CPU-Z http://www.uploadgeek.com/uploads456/0/cpuz.PNG

sparky

16th May 2008, 18:31

Please hold on, we're investigating.

BTW you're guys are making sure to turn off the logo before you do your tests, right?

IgorC

16th May 2008, 18:48

I noticed you used the null renderer, how do things play out with the a renderer attached?
The numbers are different with VMR9 but difference between CoreAVC and your decoder is still the same. CoreAVC is still faster.

Please hold on, we're investigating.

BTW you're guys are making sure to turn off the logo before you do your tests, right?
Yes, I disabled logo.

the_corona

16th May 2008, 19:29

Please hold on, we're investigating.

BTW you're guys are making sure to turn off the logo before you do your tests, right?

No, I didn't. While I will turn it off once (if) I'll use it productively, all testes are done with complete default settings.

If you feel the logo impacts performance by that much.....may I suggest you consider removing it. It adds zero value to the customer anyways and frankly, I would assume it annoys most of them...sorry :-)

Edit: Also a very quick tests with only one run each (logo on/off) shows basically no difference.

And while I'm at it, some more things I noticed:
The installer didn't quite create the start menu shortcut right, it points to:
C:\Windows\System32\rundll32.exe C:\PROGRA~2\DivX\DivX Codec H264\DivXDecH264.ax Config

while the files are actually in:
C:\Program Files (x86)\DivX\DivX Codec H264

I'm also pretty sure it should be in quotes (").

The uninstaller is correct though:
"C:\Program Files (x86)\DivX\DivXH264CodecBundleUninstall.exe"

sparky

16th May 2008, 19:39

No, I didn't. While I will turn it off once (if) I'll use it productively, all testes are done with complete default settings.

If you feel the logo impacts performance by that much.....may I suggest you consider removing it. It adds zero value to the customer anyways and frankly, I would assume it annoys most of them...sorry :-)

The logo impacts performance for the first 10 seconds or so. If you're running a test on a 30 second clip, you're not getting an accurate picture. The effect is not big but your numbers will be skewed.

I don't think that logo is that annoying and there are reasons to keep it on by default in the beta.

Can anyone suggest where I might find 300.2006.1080p.BluRay.DTS.x264-CtrlHD.sample.noaudio.mkv?

the_corona

16th May 2008, 19:49

The logo impacts performance for the first 10 seconds or so. If you're running a test on a 30 second clip, you're not getting an accurate picture. The effect is not big but your numbers will be skewed.

Ok then, I just did a quick test and saw hardly any difference, but next benchmarks i'll run I'll make sure to disable it. I'm too tired to perform real tests now (yes. I actually do run each 3 times and average over them ;-))

If you need any of my clips, pm me.

Thnx

IgorC

16th May 2008, 20:54

300.2006.1080p.BluRay.DTS.x264-CtrlHD.sample.noaudio.mkv

http://www.mediafire.com/?1d1i1m39waz

It's from Dark Shikari's x264 blog http://x264dev.multimedia.cx/

sparky

16th May 2008, 21:00

Thank you.

Part of the problem is that Beta 1 uses YUY2 by default, while CoreAVC defaults to YV12. YUY2 is slower. I'm not sure why it didn't show up in Al's tests.

I'll benchmark the 300 clip and we'll try to get you an updated build as soon as we can.

p.s. does anyone know what 'fps' is in TimeCodec? (decoding framerate seems to be 'dfps')

DigitAl56K

17th May 2008, 03:54

KEROLiUKAS

17th May 2008, 06:58

Anybody care to share the tools (or the names) that you guys are using to benchmark this decoder so i could do the same on my machine?

Dark Shikari

17th May 2008, 07:29

Hi all,

I've just posted an update (http://labs.divx.com/node/6455) on the project home page with some of the feedback we've been getting so far, including a note about the color space issue we're seeing that we believe is causing some of you to see different results than we do on our test box for Beta 1.

We'll aim to get a new build out next week.Just as a note, since you're aiming to get lossless support working, I'd like to note that lossless+CABAC has some bitstream issues in current x264 (regression probably a week or two ago), so if you're using the latest and wondering why it won't work in your decoder, it isn't your fault :p

Edit: Fixed (http://git.videolan.org/?p=x264.git;a=commitdiff;h=fcee08ae4a37ed51ac09277805ec9e0b9d96cbb5) in official x264.

LoRd_MuldeR

17th May 2008, 15:26

I did a few quick tests with the DivX H.264 Decoder Beta-1 this morning.
It seems to work 100% fine with a bunch HD trailer I have tested. Performance is also great on my Quadcore.
Congratulations so far, but CoreAVC is still a bit faster...

Here are my result from the "Syriana" 1080p trailer:
[ffdshow-tryouts]
(NULL) User: 45s, kernel: 0s, total: 45s, real: 57s, fps: 74.9, dfps: 58.8
(VMR9) User: 88s, kernel: 0s, total: 89s, real: 109s, fps: 38.3, dfps: 31.1

[DivX H.264 Decoder]
(NULL) User: 10s, kernel: 0s, total: 11s, real: 22s, fps: 309.5, dfps: 148.8
(VMR9) User: 62s, kernel: 0s, total: 63s, real: 72s, fps: 53.8, dfps: 47.2

[CoreAVCDecoder Trial]
(NULL) User: 7s, kernel: 0s, total: 7s, real: 21s, fps: 458.4, dfps: 156.7
(VMR9) User: 48s, kernel: 0s, total: 48s, real: 56s, fps: 70.8, dfps: 60.0

The problem is, the DivX Decoder doesn't work with the H.264 videos I encoded myself (using x264 and Avidemux).
Either the video doesn't run smooth (although CPU load is at ~5%) or 'mplayerc'.exe crashes in module 'divxdech264.ax'.
Tried muxing to several containers (MP4, MKV, AVI), but all of them don't play smooth (except for MP4, MP4 simply crashes).
I also tried 'internal' splitters vs. Haali Media Splitter. No difference...

Here is the file information, as reported by Avinaptic:
[ About H.264 encoding ]

User data: x264
User data: core 59 r839 27c3071
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2008
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=6
User data: deblock=1:0:0
User data: analyse=0x3:0x113
User data: me=umh
User data: subme=7
User data: brdo=1
User data: mixed_ref=1
User data: me_range=24
User data: chroma_me=1
User data: trellis=1
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=6
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=15
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=1
User data: keyint=1000
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=851
User data: ratetol=1,0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=1,00
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20,0
User data: qblur=0,5
User data: ip_ratio=1,40
User data: pb_ratio=1,30
User data: aq=2:1,00
SPS id: 0
Profile: High@L5.1
Num ref frames: 6
Aspect ratio: Square pixels
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Number of frames: 147239
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 60437 ( 41.047 %) ##########
B-slices: 86345 ( 58.643 %) ###############
I-slices: 457 ( 0.310 %)
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

Note: Those files run 100% fine when I use MPC with ffdshow/CoreAVC or MPlayer.

// EDIT

I have uploaded a short sample here:
http://mplayer.somestuff.org/misc/h264_sample.7z

PW is "Remoulade" ;)

Using the DivX H.264 Decoder, I get:
http://img166.imageshack.us/img166/7811/sampledivxtr5.png

Using ffdshow-tryouts for the very same video, I get:
http://img166.imageshack.us/img166/1243/sampleffdsao8.png

Using Haali Renderer and Haali Media Splitter in both cases.

the_corona

17th May 2008, 17:49

Anybody care to share the tools (or the names) that you guys are using to benchmark this decoder so i could do the same on my machine?

I use Haali's Timecodec (http://haali.cs.msu.ru/mkv/timeCodec.exe), and I imagin othe people doing the same.

iwod

17th May 2008, 20:21

I am wondering if Adobe will use this instead for the H.264 decoder inside Flash.
Since the decoder was license from MainConcept and now Mainconcept is part of Divx.

Any chance for a Mac version?

ChronoCross

18th May 2008, 02:37

DigitAl56K

18th May 2008, 02:42

ChronoCross: I see that also. That shouldn't happen and I'll bring it up next week.

Disabled

18th May 2008, 02:50

Is anyone experiencing an issue with divx codec overriding the Coreavc as the preferred decoder? Even after I try to set it again from the coreavc dialog it won't pass up the divx codec for merit. All I can do is uninstall it to play videos with core
I experienced the exact opposite. After installation CoreAVC still decoded the video, but then I hat it prefered in MPC HC, so I disabled Core. Then the MPC internal decoder took over and only after decoding this DivX kicked in...

MarcioAB

18th May 2008, 07:07

I'm using MPC (media player classic). The decoder is not updating the OSD (on-screen display).

Beastie Boy

18th May 2008, 11:04

Is a Linux version planned?

I'm interested in this too. Could be good for a HTPC.

bond

18th May 2008, 12:30

file specs: x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP_cabac_cqm-qmatrix
cpu: pentium3 866mhz

result:
DivxH264 42.83fps
ffdshow 64.48fps
CoreAVC 75.57fps

so it doesnt seem to be very fast on non-multithreading cpus

it also crashed on a baseline profile sample i created with x264: x264-r285_bp_720x288_B0_Ref5_p8x8-i4x4_loop-5_wbp_mp4box.mp4
if you want i can upload it

Manao

18th May 2008, 15:15

It could also be lack of non SSE2 optimizations. Your CPU is becoming quite a relic now :)

Dark Shikari

18th May 2008, 15:22

It could also be lack of non SSE2 optimizations. Your CPU is becoming quite a relic now :)That would surprise me, given that the entire Athlon lineup still benefits from MMX code; it would seem silly to omit such functions.

MarcioAB

18th May 2008, 16:18

I'm using MPC (media player classic). The decoder is not updating the OSD (on-screen display).

LoRd_MuldeR

18th May 2008, 16:30

It could also be lack of non SSE2 optimizations. Your CPU is becoming quite a relic now :)

At least on their project site they claim:
* Optimizations for MMX, SSE, SSE2

BlackSharkfr

18th May 2008, 16:54

i've downloaded the 1st beta and i've tried the codec on my samples.

My first request is to circumvent the nvidia YUV to RGB hardware conversion, which is buggy and reduces the overall contrast, and i don't know if it's possible to correct it by tweaking some hidden option, or if nvidia plans to correct it.
I'm circumventing this bug by forcing each codec to only output RGB (and/or make a software conversion).
So i'd like the remoulade codec to have this feature.

Then i found some bugs :
All my samples were made with x264, some were made with x264-vfw, others were made with Megui. Some with old versions of x264, some with recent ones.

I'm using iZ3D's mediaplayer classic modification, based on mpc 6.5.0.0 with a Stereoscopic 3D output feature, i also have 3dtv.at's stereoscopic player : an other media player with stereoscopic 3D output.
I also have MPC 6.4.9.0, it reacts exaclty like iz3d's mpc.
I also tested with Windows media player 10 (10.00.00.4058).

my system specs are :
Core2duo e4300 1.8GHz OC @ 2.4GHz (equivalent to e6600 with 1/2 cache), it can go much higher but i'm not a crazy OC guy.
2GB ram
Windows xp pro + SP2

Windows media player reads the firsts 5 seconds of all videos correctly, then the image gets cut in two. One half is renderd correctly (bottom left) and the other half is buggy (top right) : it doesn't display all images, only about 2 fps (see screenshot),
It does this with absolutely all my samples.
http://blacksharkfr.free.fr/media/images/remoulade/remouladebugwmp.jpg

Under MPC it's much better, the videos are perfectly watchable but it's not perfect.
All my samples encoded with x264-vfw (either in x264-in-avi or put back in mkv files) have a common problem : the framerate is a little jerky. Playback doesn't look smooth.
although mpc's stats indicate the framerate is good, the sync offset averages 20ms, dev 30ms, and jitter 20ms.
I don't really know what exactly these stats mean, but i know that something's wrong when they're not 0.
Otherwise, all my megui encodes (either in mkv or mp4) work great in MPC. (not in WMP).

I have also tried my 2x720p (1280x1440) stereoscopic video, and it works great in iz3d's mpc mod, but not so well in 3dtv.at's stereoscopic player (cpu useage stuck at 100% + some stuttering) but so does coreAVC in this player, so i believe it's a player issue.

Haven't done performance tests, but cpu useage was very close to what i usually get with coreAVC. But when i look at my cpu useage, i almost never go higher than 50% : so i never saturate any of my 2 cores.

bond

18th May 2008, 17:05

That would surprise me, given that the entire Athlon lineup still benefits from MMX code; it would seem silly to omit such functions.yeah, coreavc prooves that high performance is possible with sse/mmx, so why focus on sse2 instead of the older functions?

Manao

18th May 2008, 17:13

yeah, coreavc prooves that high performance is possible with sse/mmxBut you'll get faster performances on recent CPUs with SSE2, and doing SSE2 and MMX forces you to code twice as much assembly as MMX or SSE2 only. They may not have coded all the functions in both MMX and SSE2.

sparky

18th May 2008, 17:58

Manao is correct, not everything is implemented in MMX/SSE, we'll look into that. Can't promise full SSE optimizations in the immediate future, but we'll try to get rid of major bottlenecks.

BlackSharkfr: what video card are you using? is it an NVidia GeForce 8800 by any chance? We saw this behavior on one PC, and there does not seem to be anything that we do wrong. It looks like a bug in the video driver or the card itself. We don't have a workaround at the moment.

x264-vfw problem is a known issue, related to the way we set timestamps on the outgoing frames. A fix is forthcoming.

I'd like to thank everyone, we're getting a great feedback, hopefully our next beta will be much better!

BlackSharkfr

18th May 2008, 18:13

BlackSharkfr: what video card are you using? is it an NVidia GeForce 8800 by any chance? We saw this behavior on one PC, and there does not seem to be anything that we do wrong. It looks like a bug in the video driver or the card itself. We don't have a workaround at the moment.

My current graphics card is an 8800GTX, but the color contrast is not a graphics card issue, it's a general nvidia driver issue.
My previous graphics card was a 6600gt, and before that i had a 4200Ti/Le.
Whe i used some very old driver (84.something) with these cards everything was fine but with more recent drivers i get the color problem. So i know it's a driver issue.
There is nothing wrong with your codec, it's 100% nvidia's fault, they're perfectly aware of this issue but they've never corrected it.

The problem is that the only way i found to circumvent this issue, is to force players to use software yuv to rgb conversion when available, or to force all codecs to output RGB instead of YV12, when this option isn't available.

Which is why i'm asking for an option to ouput RGB.

sparky

18th May 2008, 18:26

My current graphics card is an 8800GTX, but it's not a graphics card issue, it's a general nvidia driver issue.
My previous graphics card was a 6600gt, and before that i had a 4200Ti/Le.
Whe i used some very old driver (84.something) with these cards everything was fine but with more recent drivers i get the color problem. So i know it's a driver issue.
There is nothing wrong with your codec, it's 100% nvidia's fault, they're perfectly aware of this issue but they've never corrected it.

The problem is that the only way i found to circumvent this issue, is to force players to use software yuv to rgb conversion when available, or to force all codecs to output RGB instead of YV12, when this option isn't available.

Which is why i'm asking for an option to ouput RGB.

I am referring to the weird staircasing effect in the top right corner.

We'll try to do something about the color problem. I suspect there may be a better way than to force rgb, but it will take time to investigate. Short term a "disable YUV" checkbox should do.

LoRd_MuldeR

18th May 2008, 19:12

All my samples encoded with x264-vfw (either in x264-in-avi or put back in mkv files) have a common problem : the framerate is a little jerky. Playback doesn't look smooth.
I have reported a similar problem in my previous post. But those files were not encoded with VFW, but with Avidemux (which is using libx264 directly).
Also the problem with 100% reproducible independent of the AVI container. I tried MKV and MP4 as well, but no difference...

Inventive Software

19th May 2008, 01:28

OK, I think I've signed up to DivX labs. It's been a while since I visited, but I figure since I follow it, I should try it. My desktop's about the same spec as bond's P3 monster, but slightly slower (Celeron 800 MHz), so I'm looking for a decoder that's faster than ffdshow_tryouts and competitive to CoreAVC. Who do I send the PM to? :)

check

19th May 2008, 02:02

My first request is to circumvent the nvidia YUV to RGB hardware conversion, which is buggy and reduces the overall contrast, and i don't know if it's possible to correct it by tweaking some hidden option, or if nvidia plans to correct it.
There are colour control options to fix this in the driver control panel.

Here are some tests from another forum (CCCP (http://www.cccp-project.net/smf/index.php?topic=2692)'s):
On a q6600 with Null renderer:

720x432 High Profile (music video):
DivX beta1: User: 2s, kernel: 0s, total: 2s, real: 6s, fps: 2177.0, dfps: 1049.4
Core 1.6: User: 2s, kernel: 0s, total: 2s, real: 6s, fps: 2312.3, dfps: 932.2

800x600 High Profile (video game cap):
DivX: User: 11s, kernel: 0s, total: 12s, real: 41s, fps: 1416.6, dfps: 411.6
Core: User: 12s, kernel: 0s, total: 13s, real: 43s, fps: 1319.5, dfps: 397.2

1920x1080 BD (spirits within first 512mb):
Divx: User: 9s, kernel: 0s, total: 10s, real: 32s, fps: 318.3, dfps: 97.7
Core: User: 6s, kernel: 0s, total: 6s, real: 33s, fps: 499.6, dfps: 94.4

And one more too: 1280x544 High Profile (720p movie from a 1080i broadcast):
User: 102s, kernel: 1s, total: 104s, real: 534s, fps: 1545.4, dfps: 302.3 CoreAVC
User: 146s, kernel: 2s, total: 148s, real: 520s, fps: 1086.7, dfps: 310.9 DivX

Seems that divx is generally faster here. I disabled the logo, and 'low latency' (the latter just on wild speculation it would slow performance in this style of testing). DivX still seems to crash on a reasonable percentage of streams though.

cyberbeing

19th May 2008, 04:58

My initial results were very similar to the_corona's where Divx H264 was slower then CoreAVC in every test (Like him, I also have a AMD X2 clocked at 2.64Ghz but I have the 2x1MB L2 Cache model): http://forum.doom9.org/showpost.php?p=1138387&postcount=56
I also noticed on average that Divx H264 uses about 5% more CPU then CoreAVC. For example, if CoreAVC was using 20-30% CPU, Divx H264 was usually using 25-35% CPU when both are using YUY2 and Haali Renderer.

All tests done on WinXP Pro SP3 32bit with a Socket 939 AMD X2 4800+ @2.64Ghz, DDR440 2-3-3-6, and 7800GTX 512
________________________________________________________________________
Blu-ray 1920x1080 High 4.1 (CABAC/4 Ref) 25.3Mbps

FFDshow Rev. 1960
User: 3s, kernel: 0s, total: 4s, real: 22s, fps: 226.6, dfps: 40.3

Divx H264 Beta 1
User: 2s, kernel: 0s, total: 2s, real: 19s, fps: 404.4, dfps: 47.8

CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 16s, fps: 485.3, dfps: 54.3
________________________________________________________________________

________________________________________________________________________
1920x800 High 5.1 (CABAC/5 Ref) 16.6Mbps

FFDshow Rev. 1960
User: 3s, kernel: 0s, total: 3s, real: 27s, fps: 273.5, dfps: 38.6

Divx H264 Beta 1
User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 485.4, dfps: 62.5

CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 656.5, dfps: 67.8
________________________________________________________________________

________________________________________________________________________
1920x800 High 5.1 (CABAC/11 Ref) 11.1Mbps

FFDshow Rev. 1960
User: 5s, kernel: 0s, total: 5s, real: 35s, fps: 289.5, dfps: 42.1

Divx H264 Beta 1
User: 3s, kernel: 0s, total: 3s, real: 22s, fps: 451.3, dfps: 68.2

CoreAVC 1.7 Pro
User: 2s, kernel: 0s, total: 2s, real: 19s, fps: 632.4, dfps: 76.1
________________________________________________________________________

________________________________________________________________________
1280x536 High 5.1 (CABAC/6 Ref) 8Mbps

FFDshow Rev. 1960
User: 2s, kernel: 0s, total: 3s, real: 25s, fps: 651.0, dfps: 77.9

Divx H264 Beta 1
User: 1s, kernel: 0s, total: 1s, real: 16s, fps: 1056.5, dfps: 125.4

CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 1741.8, dfps: 131.0
________________________________________________________________________

________________________________________________________________________
1280x532 High 5.1 (CABAC/10 Ref) 3.2Mbps

FFDshow Rev. 1960
User: 5s, kernel: 0s, total: 5s, real: 42s, fps: 703.3, dfps: 95.7

Divx H264 Beta 1
User: 3s, kernel: 0s, total: 3s, real: 25s, fps: 1251.1, dfps: 156.6

CoreAVC 1.7 Pro
User: 3s, kernel: 0s, total: 3s, real: 24s, fps: 1320.9, dfps: 163.7
________________________________________________________________________

________________________________________________________________________
1280x720 High 5.1 (CABAC/16 Ref) 4.1Mbps

FFDshow Rev. 1960
User: 5s, kernel: 0s, total: 5s, real: 28s, fps: 405.2, dfps: 82.7

Divx H264 Beta 1
User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 1001.0, dfps: 148.0

CoreAVC 1.7 Pro
User: 2s, kernel: 0s, total: 2s, real: 14s, fps: 1041.9, dfps: 164.5
________________________________________________________________________

________________________________________________________________________
640x480 High 5.1 (CABAC/16 Ref) 1Mbps

FFDshow Rev. 1960
User: 3s, kernel: 0s, total: 3s, real: 16s, fps: 1150.4, dfps: 260.1

Divx H264 Beta 1
User: 1s, kernel: 0s, total: 2s, real: 8s, fps: 2131.3, dfps: 495.4

CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 7s, fps: 2864.0, dfps: 547.7
________________________________________________________________________

________________________________________________________________________
720x480 High 5.1 (CABAC/10 Ref) 0.8Mbps

FFDshow Rev. 1960
User: 17s, kernel: 0s, total: 18s, real: 78s, fps: 1079.5, dfps: 250.1

Divx H264 Beta 1
User: 9s, kernel: 0s, total: 9s, real: 38s, fps: 2035.6, dfps: 510.3

CoreAVC 1.7 Pro
User: 7s, kernel: 0s, total: 7s, real: 33s, fps: 2579.9, dfps: 589.1
________________________________________________________________________

From these tests Divx H264 Beta 1 is on average 10% slower in dfps then CoreAVC 1.7 Pro on my system.

the_corona: Yesterday I had to repack our binary. I am wondering if it has affected performance. Stay tuned - I will check it out this morning.

Considering I joined the beta after you repacked it, did your testing find out if that was causing a performance hit or not?

MarcioAB

19th May 2008, 05:11

It seems DivX H264 delivers around 15% more fps than ffdshow. Over here with a 720p source I got 10% more when renderer is VMR and 120% more when VMR9 - that is interesting to me because I use subtitles (VMR9).

DivX and CoreAVC similar, specially on VRM9.

Turning Deband ON in ffdshow (what is a must for me because the x264 issue with blocks on dark areas) drops it's speed by 40%. With DivX H264 there is no impact turning deblock on/off, but also the image does not change - I see the blocks. The same with CoreAVC (a little bit more blocks than DivX).

ffdshow:
110 fps (VMR) (CPU @ 80%)
100 fps (VMR9) (CPU @ 80%)

DivX H264
120 fps (VMR) (CPU @ 90%)
118 fps (VMR9) (CPU @ 65%) (Obs: deblock on/off, latency on/off)

CoreAVC
120 fps (VMR) (CPU @ 65%)
119 fps (VMR9) (CPU @ 70%)

CPU 6600@2.40GHz (dual-core) - 1GB RAM DDR2 400MHz - GeForce GTS 8600

KEROLiUKAS

19th May 2008, 06:34

I don't have CoreAVC installed right now, but here's ffdshow vs DivX h.264

Alvin.And.The.Chipmunks.720p:

DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 13s, fps: 812.8, dfps: 99.9

ffdshow
User: 30s, kernel: 0s, total: 30s, real: 30s, fps: 45.5, dfps: 45.4

Unhitched.S01E02.720p:

DivX h.264
User: 1s, kernel: 0s, total: 2s, real: 10s, fps: 708.4, dfps: 133.5

ffdshow
User: 26s, kernel: 0s, total: 26s, real: 26s, fps: 55.7, dfps: 55.5

The.Office.US.S04E09.720p:

DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 12s, fps: 770.1, dfps: 120.5

ffdshow
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 53.8, dfps: 53.7

Superbad.720p:

DivX h.264
User: 1s, kernel: 0s, total: 2s, real: 13s, fps: 758.6, dfps: 116.9

ffdshow
User: 25s, kernel: 0s, total: 25s, real: 25s, fps: 59.7, dfps: 59.3

Tests using build 1723.

Manao

19th May 2008, 06:44

KEROLIUKAS : you forgot to disable the postprocessing in ffdshow ? Or do you have a quad core ?

Yufi

19th May 2008, 07:55

thirding the question about linux- I would LOVE a fast linux h264 decoder that doesn't require hacked together code

kosmonaut

19th May 2008, 09:11

KEROLiUKAS

19th May 2008, 15:09

KEROLIUKAS : you forgot to disable the postprocessing in ffdshow ? Or do you have a quad core ?

Ahhh, probably, i knew it couldn't be this good. I was running default settings on both.

AMD 4200+ x2 AM2

I'll update my results later without post proccesing, and hopefully some CoreAVC results.

Inventive Software

19th May 2008, 17:17

DigitAl56k or SeaBass or myself. What account name did you use?

I sent a PM to DigitAl56k, and I got a response, so I think my ISP's being a bit screwy of late. :)

I've downloaded it, and ran it on a couple test files, so far it seems noticably slower than ffdshow_tryouts. I'm getting timecodec and I'll give some numbers in a bit.

EDIT: 3 hours later, some concrete numbers with ffdshow and DivX. ffdshow wins out this time.

DivX H.264 Decoder
User: 3746s, kernel: 2s, total: 3749s, real: 3824s, fps: 20.1, dfps: 19.7

ffdshow_tryouts rev 1960
User: 3311s, kernel: 2s, total: 3314s, real: 3390s, fps: 22.7, dfps: 22.2

Post-processing was disabled on ffdshow. Single core, Celeron 800 MHz, 128 KB cache, Coppermine P3 based.

I have a copy of CoreAVC I obtained a while back, I'll install and try that and see how it performs.

Ajax_Undone

19th May 2008, 21:52

All of my x.264 HD files encoded with RipBot's 4.0 1080P profile playback at any where from 8.7 FPS to 23.4 FPS Dont know whats up but I get the full 30 FPS with Core... All tested with MPC...

Quad Core Phenom 9500 4 GB 800mhz of ram 32 Bit Windows Vista Ultimate...

KEROLiUKAS

19th May 2008, 23:29

DigitAl56K

20th May 2008, 00:45

Hey guys, we're working on a new build that should perform better on AMD processors.

I'll also contact a few of you later via PM with upload locations for sample clips. I went through PM's at Labs earlier so if you sent us a request check your PM's and e-mail.

Regarding the drawing issue on the nVidia 8800GTX, I have the same model here at my desk with an identical problem. We looked into it for an entire day. I'm asking around for a contact at nVidia so that we can help them reproduce the effect.

Stay tuned :)

KEROLiUKAS

20th May 2008, 01:09

DigitAl56K

20th May 2008, 01:42

Should be real soon KEROLiUKAS, we're just cleaning up a few loose ends.

I also wanted to add a reply on Linux since several people have asked. We actually have a linux build of the decoder but as you can imagine there is a lot of work still to be done on our Windows tool set and these will be the first products to be released. As for a Linux version, if you're interested please start a new thread because here we intend to focus on our current beta. Also note that we can't commit to a timeline for a Linux version, but understanding your intentions around a linux decoder from DivX may help us to prioritize it.

KEROLiUKAS

20th May 2008, 01:45

DigitAl56K

20th May 2008, 01:54

We'll send out an e-mail to the group when it's ready :)

Beastie Boy

20th May 2008, 09:55

I also wanted to add a reply on Linux since several people have asked. We actually have a linux build of the decoder but as you can imagine there is a lot of work still to be done on our Windows tool set and these will be the first products to be released. As for a Linux version, if you're interested please start a new thread because here we intend to focus on our current beta. Also note that we can't commit to a timeline for a Linux version, but understanding your intentions around a linux decoder from DivX may help us to prioritize it.

:thanks:

Manao

20th May 2008, 10:10

KEROLiUKAS : what version of FFDShow are you running ? I don't doubt that DivX is faster than FFDshow on your dual core, but it shouldn't be more than twice faster (see cyberdeing timings, on a relatively equivalent CPU : http://forum.doom9.org/showthread.php?p=1139209#post1139209), so that may be explained by a very old version of FFDShow.

MarcioAB

20th May 2008, 13:29

Any plans to support or collaborate with hardware acceleration ( Windows DXVA ).
It works well with MPC-HomeCinema DXVA-enabled internal decoder, but it does not work directly on GraphEdit with "Use Clock" turned off so, can not compare.

clsid

20th May 2008, 13:30

Yes, ffdshow has become significantly faster in the past months.

CiNcH

20th May 2008, 13:46

It works well with MPC-HomeCinema DXVA-enabled internal decoder, but it does not work directly on GraphEdit with "Use Clock" turned off so, can not compare.

It does not make sense to test DXVA anyway. Bitstream mode is supposed to decode at real-time without CPU intervention.

CiNcH

20th May 2008, 19:51

Concerning the DVBViewer DVBSource problem... I just played a H.264 Blu-Ray m2ts file over the filter and some frames (but very few, only saw a still image with the DivX logo) were decoded until it crashed.

bob0r

20th May 2008, 20:02

@DigitAl56K

If you ever decide to make your product free, x264.nl still needs an x264.ax in the package :D

I am not interested to test the decoder now, as i HATE email, but you can test all Satellite samples yourself:
http://x264.nl/h.264.samples
http://files.x264.nl/h.264.samples.13.apr.2008.europe

DigitAl56K

20th May 2008, 20:56

If you ever decide to make your product free, x264.nl still needs an x264.ax in the package

Believe me when I say there are a lot of supporters for a free decoder, including me! We are looking at the various licensing costs and nothing is off the table, but the truth is that pricing, if any, has not been set yet. When we come closer to an actual release you'll be the second to know ;)

Thanks CiNcH for the additional info on the DVBViewer issue. Regarding DXVA, as I've mentioned on labs several of us are very excited by the idea of DXVA support. Whether this will make the first release or not I'm not sure yet. Our current focus is to round out software decoding, DXVA may depend on the time we have available.

KEROLiUKAS

20th May 2008, 23:26

Inventive Software

21st May 2008, 00:15

Get a newer version. ffdshow's changed quite a bit since then.

MarcioAB

21st May 2008, 01:26

Regarding DXVA, as I've mentioned on labs several of us are very excited by the idea of DXVA support. Whether this will make the first release or not I'm not sure yet. Our current focus is to round out software decoding, DXVA may depend on the time we have available.

On the original post I also suggested "collaboration" with DXVA. I have no idea if that is technically possible but it could be nice to have some kind of DXVA post processing (Deband-like) to remove/minimize blocks. So, CPU usage can stay something between 2% and full-sofware decode. Maybe that could give some uniqueness to DivX H264 ...

tomos

21st May 2008, 03:05

a collabaration would be nice, might get around the problems with decoding AVC files beyond 4.1, e.g pass what you can to the GPU, do the rest with CPU? possible?

KEROLiUKAS

21st May 2008, 04:17

Redone all tests using the latest ffdshow, and added CoreAVC, also disabled logo in DivX h.264.

File 1:

DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 868.0, dfps: 117.6

ffdshow
User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 532.2, dfps: 60.6

CoreAVC
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 1397.0, dfps: 132.1

File 2:

DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 8s, fps: 997.8, dfps: 171.2

ffdshow
User: 1s, kernel: 0s, total: 1s, real: 21s, fps: 742.4, dfps: 68.3

CoreAVC
User: 0s, kernel: 0s, total: 0s, real: 7s, fps: 1600.0, dfps: 197.9

File 3:

DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 9s, fps: 978.7, dfps: 147.7

ffdshow
User: 1s, kernel: 0s, total: 1s, real: 22s, fps: 861.9, dfps: 65.3

CoreAVC
User: 0s, kernel: 0s, total: 0s, real: 8s, fps: 1592.4, dfps: 169.3

File 4:

DivX h.264
User: 1s, kernel: 0s, total: 1s, real: 12s, fps: 923.2, dfps: 126.1

ffdshow
User: 2s, kernel: 0s, total: 2s, real: 21s, fps: 631.3, dfps: 72.2

CoreAVC
User: 1s, kernel: 0s, total: 1s, real: 11s, fps: 1223.2, dfps: 138.4

Tests using build 1945 of ffdshow.

Chart of my data:
http://img153.imageshack.us/img153/289/chartcopy22ro3.jpg

LOL, it took me a few minutes to figure out some Excel stuff.

Sorry for the innaccurate results at first, all sorted out now..

_xxl

21st May 2008, 06:27

Yes, DivX and Core are faster because of frame level parallelism, ffdshow has only cabac splitting.
Please test using one decoding core to see the differences.

Shinigami-Sama

21st May 2008, 06:37

Yes, DivX and Core are faster because of frame level parallelism, ffdshow has only cabac splitting.
Please test using one decoding core to see the differences.

it has slices as well
but not many encodes have slices anymore...

Manao

21st May 2008, 07:20

sparky

21st May 2008, 10:09

As nice as these results look, I'm having a hard time believing that beta1 is 30% faster than CoreAVC on any clip :) maybe there really is something wrong. (Unless it's something like CAVLC + no B-frames + no 8x8). We're getting an X2 set up, we'll get a clearer idea what to expect.

What's the renderer and the graphics card?

Beta 2 is getting real close, I can't make any promises but I'm hoping to push it tomorrow.

KEROLiUKAS

21st May 2008, 15:20

KEROLiUKAS: I still think there's a problem. You're the only guy with a dual core who finds that DivX is faster than CoreAVC.

On a side note, change the name of the video files in your post to something less conspicuous.
On a second side note, don't think I have something against you, it's just that I see strange unexplainable timings and I like to know why.
Yea i think so too, i think that may be the case, as it's really weird... Later today I am going to post screenshots of my settings for Core and you guys can tell me what's wrong... Maybe it was something to do with something else running?

IgorC

21st May 2008, 16:52

KEROLiUKAS

Did you test latest version of CoreAVC 1.7?

KEROLiUKAS

21st May 2008, 23:33

http://img174.imageshack.us/img174/8328/corsetji4.jpg

Ice =A=

21st May 2008, 23:38

You could try switching deinterlacing to "hardware".

KEROLiUKAS

21st May 2008, 23:43

You could try switching deinterlacing to "hardware".

That didn't affect it..But crap i think i know what i did, i turned off deblocking in DivX h.264, gonna do the same in Core and re run the tests...

Edit:

Alright, fixed my original post, with real results, same settings.

Inventive Software

22nd May 2008, 02:32

@KerOLiUKAS: Please don't use offensive language. This is a family forum. :)

KEROLiUKAS

22nd May 2008, 03:09

@KerOLiUKAS: Please don't use offensive language. This is a family forum. :)

IDK what you're talking about :D

(edited it out :P )

Deblocking ON
http://img519.imageshack.us/img519/3459/chartdeblocksv1.jpg

Inventive Software

22nd May 2008, 05:56

CoreAVC wins out in this instance then. :)

Is there a way to batch run timecodec on different decoders?

KEROLiUKAS

22nd May 2008, 14:03

CoreAVC wins out in this instance then. :)

Is there a way to batch run timecodec on different decoders?

Yeah, i was wondering that too. It would be nice to create a batch and have them all run...

MarcioAB

22nd May 2008, 15:49

Is that possible that we all use one same sequence of video (let's say 3K or 4K frames) and check the results relative our hardware differences ?

My results (on Intel 6600 + nVidia 8600 GTS + XP SP3) indicated DivX and CoreAVC almost with the same results.

rack04

22nd May 2008, 16:32

My test Results:

Settings:

http://i11.photobucket.com/albums/a199/rack04/ffdshow1of2.jpg

http://i11.photobucket.com/albums/a199/rack04/ffdshow2of2.jpg

http://i11.photobucket.com/albums/a199/rack04/DivX.jpg

File 1:

General
Complete name : C:\Documents and Settings\xxxxx\Desktop\64827461.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 81.1 MiB
Duration : 1mn 41s
Overal bit rate : 6724 Kbps
Encoded date : UTC 2008-05-21 13:26:03
Tagged date : UTC 2008-05-21 13:26:03
Writing application : Yamb 2.0.0.8 [http://yamb.unite-video.com]

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 2
Codec ID : avc1
Duration : 1mn 41s
Bit rate mode : VBR
Bit rate : 6532 Kbps
Maximum bit rate : 12.6 Mbps
Width : 1280 pixels
Height : 690 pixels
Display aspect ratio : 1.855
Frame rate mode : CFR
Frame rate : 23.976 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.308
Stream size : 78.8 MiB
Encoded date : UTC 2008-05-21 03:03:40
Tagged date : UTC 2008-05-21 13:26:07

Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Duration : 1mn 41s
Bit rate mode : VBR
Bit rate : 188 Kbps
Maximum bit rate : 325 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 2.27 MiB
Encoded date : UTC 2008-05-21 13:26:06
Tagged date : UTC 2008-05-21 13:26:07

DivX H264 Decoder Filter

Renderer = VMR9
User: 4s, kernel: 6s, total: 10s, real: 22s, fps: 226.0, dfps: 110.1

Renderer = NULL
User: 2s, kernel: 0s, total: 2s, real: 15s, fps: 867.4, dfps: 154.8

ffdshow video Decoder

Renderer = VMR9
User: 32s, kernel: 0s, total: 33s, real: 36s, fps: 72.5, dfps: 66.3

Renderer = NULL
User: 31s, kernel: 0s, total: 31s, real: 34s, fps: 76.3, dfps: 71.1

File 2:

General
Complete name : C:\Documents and Settings\xxxxx\Desktop\sample.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 50.5 MiB
Duration : 1mn 8s
Overal bit rate : 6197 Kbps
Encoded date : UTC 2008-05-21 14:07:21
Tagged date : UTC 2008-05-21 14:07:21

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4
Codec ID : avc1
Duration : 1mn 8s
Bit rate mode : VBR
Bit rate : 6096 Kbps
Maximum bit rate : 15.6 Mbps
Width : 1280 pixels
Height : 544 pixels
Display aspect ratio : 2.35
Frame rate mode : CFR
Frame rate : 19.181 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.456
Stream size : 49.7 MiB
Encoded date : UTC 2008-05-21 14:07:21
Tagged date : UTC 2008-05-21 14:07:24

Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : No
Duration : 1mn 8s
Bit rate mode : VBR
Bit rate : 96.0 Kbps
Maximum bit rate : 137 Kbps
Channel(s) : 2 channels
Channel positions : L R
Sampling rate : 48.0 KHz
Resolution : 16 bits
Stream size : 812 KiB
Encoded date : UTC 2008-05-21 14:07:24
Tagged date : UTC 2008-05-21 14:07:24

DivX H264 Decoder Filter

Renderer = VMR9
User: 1s, kernel: 2s, total: 4s, real: 12s, fps: 288.3, dfps: 102.2

Renderer = NULL
User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 998.9, dfps: 128.1

ffdshow video Decoder

Renderer = VMR9
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 762.8, dfps: 84.3

Renderer = NULL
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 998.9, dfps: 91.7

speedxl

25th May 2008, 04:51

Since DivX, its supported in Ps3, it means you will update the ps3 decoder, when this decoder gets released? i hope you are coding too for the cell platform.

Fuse-One

25th May 2008, 16:03

Since DivX, its supported in Ps3, it means you will update the ps3 decoder, when this decoder gets released? i hope you are coding too for the cell platform.

That all depends on Sony not DivX themselves, me thinks.

Brother John

25th May 2008, 19:02

Another single core test from me. Not too much difference from ffdshow. On the whole DivX just works without needing any attention. Nice work for the first beta. 0-255 range output would be nice, but OTOH using ffdshow as postprocessor is no problem and doesn’t seem to change speed noticeably.

TEST RESULTS:
Pentium M Dothan, 1.6 GHz, single core
WinXP
DivX H.264 Beta, defaults, logo disabled. Additionally I tested without multithreading because of my CPU -> no significant difference.
ffdshow_rev1971_20080523_clsid_sse_icl10, defaults

Clip1:
NULL
DivX: User: 1669s, kernel: 2s, total: 1672s, real: 1699s, fps: 101.9, dfps: 100.3
ffds: User: 1821s, kernel: 2s, total: 1823s, real: 1846s, fps: 93.4, dfps: 92.3

VMR9
DivX: User: 1629s, kernel: 9s, total: 1639s, real: 2771s, fps: 103.9, dfps: 61.5
ffds: User: 1837s, kernel: 7s, total: 1844s, real: 2568s, fps: 92.4, dfps: 66.3

Clip2:
NULL
DivX: User: 73s, kernel: 0s, total: 73s, real: 75s, fps: 859.8, dfps: 838.5
ffds: User: 93s, kernel: 0s, total: 93s, real: 96s, fps: 673.1, dfps: 652.0

VMR9
DivX: User: 64s, kernel: 0s, total: 64s, real: 526s, fps: 977.5, dfps: 119.7
ffds: User: 89s, kernel: 0s, total: 90s, real: 526s, fps: 698.7, dfps: 119.8

Clip1 Info
Play duration: 01:53:36 (6816.04 s)
Container type: matroska

[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 716 x 436
Frame aspect ratio: 179:109 = 1.642201
Pixel aspect ratio: 16:11 = 1.454545
Display aspect ratio: 2864:1199 = 2.388657 (~2.35:1)
Framerate: 25 fps

[ About H.264 encoding ]

User data: x264
User data: core 59 r858 0903472
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2008
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=4
User data: deblock=1:0:-1
User data: analyse=0x3:0x133
User data: me=hex
User data: subme=7
User data: brdo=0
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=0
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=4,4
User data: chroma_qp_offset=0
User data: threads=1
User data: nr=0
User data: decimate=1
User data: mbaff=0
User data: bframes=16
User data: b_pyramid=0
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40
User data: rc=crf
User data: crf=18.5
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=1.00
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=2:1.00
SPS id: 0
Profile: High@L5.1
Num ref frames: 4
PPS id: 0
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction

Clip2 Info
Play duration: 00:35:03 (2102.533333 s)
Container type: MP4/MOV

[ Video track ]

Codec: avc1
Resolution: 320 x 240
Frame aspect ratio: 4:3 = 1.333333
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 4:3 = 1.333333
Framerate: 29.970036 fps

[ About H.264 encoding ]

User data:
SPS id: 0
Profile: Baseline@L1.3
Num ref frames: 1
PPS id: 0
Entropy coding type: CAVLC
Weighted prediction: No
Weighted bipred idc: No
Number of frames: 63013
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 62521 ( 99.219 %) #########################
B-slices: 0 ( 0.000 %)
I-slices: 492 ( 0.781 %)
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

plonk420

26th May 2008, 07:38

sorry for being lame, but what's a quick way to get the FPS of a clip when dumping output to null? (yes, i understand it's testing raw decode performance)

DigitAl56K

26th May 2008, 23:11

what's a quick way to get the FPS of a clip when dumping output to null?

Google "Haali Timecodec"

Beta 2 is now available from the Project Rémoulade homepage (http://labs.divx.com/ProjectRemoulade). The list of changes and some of the known-issues can be found over at DivX Labs.

I'll also be taking care of some more group sign-ups this afternoon.

LoRd_MuldeR

27th May 2008, 00:47

Here is some Performance test from my Q6600:

E:\HD\Trailer\Apple\syriana_h1080p.mov

[DivX H.264 Decoder - Beta 2]
User: 9s, kernel: 0s, total: 9s, real: 17s, fps: 355.3, dfps: 191.5

[CoreAVC Decoder - Trial Version]
User: 7s, kernel: 0s, total: 7s, real: 16s, fps: 480.6, dfps: 212.8

[ffdshow-tryouts - rev1971]
User: 33s, kernel: 0s, total: 33s, real: 41s, fps: 102.4, dfps: 81.6

Also the playback problems with my own encodes seem to be solved. Good job! :)

Brother John

27th May 2008, 00:54

A quick test before going to bed: The first 6min from Clip1 in post #139. Logo disabled.

VMR9
Beta1: User: 80s, kernel: 0s, total: 81s, real: 145s, fps: 111.9, dfps: 62.3
Beta2: User: 76s, kernel: 0s, total: 76s, real: 141s, fps: 118.5, dfps: 64.4
ffds: User: 116s, kernel: 9s, total: 125s, real: 146s, fps: 72.3, dfps: 62.2

NULL
Beta1: User: 82s, kernel: 0s, total: 82s, real: 84s, fps: 109.5, dfps: 107.3
Beta2: User: 77s, kernel: 0s, total: 77s, real: 78s, fps: 117.5, dfps: 115.4

One possible bug: For anamorphic video and when using MPC internal splitter (http://sf.net/projects/guliverkli2) DivX ignores the AR info resulting in wrong playback AR if the AR flag is only set in the Matroska container and not in the bitstream. I’m not exactly sure if this is DivX’s fault.

Combinations that fail:
MPC internal + DivX
MPC internal + DivX + ffdshow as postprocessor

Combinations that work:
Haali + DivX
Haali + DivX + ffdshow as postprocessor
Haali + ffdshow
MPC internal + ffdshow

On ffdshow’s "output" tab "set pixel ar" and "allow output format chages" are checked. If the AR flag is set in the bitstream (or bitstream + container) the problem does not occur. Also the MP4 container is not affected.

CPU Info
http://brother-john.net/files/cpu.png
Cache latency computation, ver 1.0
www.cpuid.com

Computing ...

stride 4 8 16 32 64 128 256 512
size (Kb)
1 3 3 3 3 3 3 3 3
2 3 3 3 3 3 3 3 3
4 3 3 3 3 3 3 3 3
8 3 3 3 3 3 3 3 3
16 3 3 3 3 3 3 3 3
32 3 3 3 7 3 3 3 3
64 3 4 5 9 10 10 10 10
128 3 4 5 9 10 10 10 10
256 3 4 5 9 10 11 10 10
512 3 4 5 9 10 10 10 10
1024 3 4 5 9 10 10 10 11
2048 3 4 5 9 14 14 15 15
4096 3 4 5 26 48 170 170 173
8192 3 4 5 26 52 175 174 177
16384 3 4 5 26 51 172 174 173
32768 3 4 5 26 50 173 173 175

2 cache levels detected
Level 1 size = 32Kb latency = 3 cycles
Level 2 size = 2048Kb latency = 10 cycles

cyberbeing

27th May 2008, 04:03

This time the timecodec tests were all done with YV12 because there is now no way to force YUY2 in Divx H264.

Blu-ray 1920x1080 High 4.1 (CABAC/4 Ref) 25.3Mbps

User: 1s, kernel: 0s, total: 1s, real: 20s, fps: 510.9, dfps: 44.0

User: 1s, kernel: 0s, total: 1s, real: 16s, fps: 654.4, dfps: 56.0

User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 434.6, dfps: 50.6
________________________________________________________________________

________________________________________________________________________
1920x800 High 5.1 (CABAC/5 Ref) 16.6Mbps

FFDshow Rev. 1972
User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 478.7, dfps: 41.5

CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 999.0, dfps: 68.9

Divx H264 Beta 2
User: 1s, kernel: 0s, total: 1s, real: 16s, fps: 644.2, dfps: 65.5
________________________________________________________________________

________________________________________________________________________
1920x800 High 5.1 (CABAC/11 Ref) 11.1Mbps

FFDshow Rev. 1972
User: 2s, kernel: 0s, total: 3s, real: 32s, fps: 490.4, dfps: 46.2

CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 19s, fps: 828.7, dfps: 78.5

Divx H264 Beta 2
User: 2s, kernel: 0s, total: 2s, real: 20s, fps: 589.7, dfps: 72.2
________________________________________________________________________

________________________________________________________________________
1280x536 High 5.1 (CABAC/6 Ref) 8Mbps

FFDshow Rev. 1972
User: 1s, kernel: 0s, total: 1s, real: 23s, fps: 1031.2, dfps: 84.2

CoreAVC 1.7 Pro
User: 1s, kernel: 0s, total: 1s, real: 14s, fps: 1534.5, dfps: 137.1

Divx H264 Beta 2
User: 1s, kernel: 0s, total: 1s, real: 15s, fps: 1171.8, dfps: 132.8
________________________________________________________________________

________________________________________________________________________
720x480 High 5.1 (CABAC/10 Ref) 0.8Mbps

FFDshow Rev. 1972
User: 12s, kernel: 0s, total: 12s, real: 71s, fps: 1549.2, dfps: 278.1

CoreAVC 1.7 Pro
User: 10s, kernel: 0s, total: 11s, real: 33s, fps: 1785.5, dfps: 590.2

Divx H264 Beta 2
User: 8s, kernel: 0s, total: 8s, real: 36s, fps: 2257.4, dfps: 543.2

Seems like the speed for Beta 2 is virtually the same as Beta 1 on my AMD X2, but it's possible it might be 1-2% faster.

I also noticed a problem that the uninstaller of Beta 1 is going to delete my whole Divx directory (which I have Divx Pro installed) on reboot. The uninstaller should probably be modified to not delete the whole directory if other Divx stuff is installed.

Edit: Well it seems that even though the uninstaller said it was going to delete the Divx directory on reboot, when I rebooted it didn't.

Inventive Software

27th May 2008, 04:37

I've still to do some representative numbers with deblocking enabled in ffdshow-tryouts and DivX H.264 Beta 1 decoders, but this is the result for H.264 Beta 2 decoder, inloop deblocking enabled, and for some strange reason I can't fathom multithreading enabled on a single core machine (would that make a difference?) Same file as before:

User: 3084s, kernel: 3s, total: 3087s, real: 3146s, fps: 24.4, dfps: 24.0

Seems SSE's really helping. :)

IgorC

27th May 2008, 06:19

Beta 2 is 4% faster then Beta 1 here.
It comes closer to CoreAVC's perfomance

Sample 300.2006.1080p.BluRay.DTS.x264-CtrlHD.sample.noaudio.mkv
CPU: E2160

Divx beta 1

Null
User: 6s, kernel: 0s, total: 6s, real: 36s, fps: 231.9, dfps: 43.9

VMR9
User: 13s, kernel: 0s, total: 13s, real: 48s, fps: 119.2, dfps: 32.9

VMR7
User: 6s, kernel: 12s, total: 18s, real: 42s, fps: 85.2, dfps: 37.7

Divx beta 2

Null
User: 5s, kernel: 0s, total: 5s, real: 35s, fps: 273.2, dfps: 45.6

VMR9
User: 5s, kernel: 0s, total: 5s, real: 46s, fps: 270.3, dfps: 34.2

VMR7
User: 5s, kernel: 8s, total: 14s, real: 39s, fps: 111.2, dfps: 40.4

CoreAVC 1.7

Null
User: 4s, kernel: 0s, total: 4s, real: 32s, fps: 330.3, dfps: 48.7

VMR9
User: 4s, kernel: 0s, total: 4s, real: 44s, fps: 329.2, dfps: 35.8

VMR7
User: 5s, kernel: 4s, total: 9s, real: 35s, fps: 165.4, dfps: 45.8

the_corona

27th May 2008, 08:38

So it's still not faster in Beta2 than CoreAVC despite claims being made over a week ago with an older Version (the scaling of the charts is.......well, very interesting too (read: highly misleading!).

Now it's really no problem that its still slower, even if it'll never be and be like that when it's final or something, it's plenty fast. What I don't like is the mis-guidance that'll have us believe its actually faster (nobody except Divx seems to see this) on you're fancy charts.

Just be honest, give us progress updates and talk to you're (potential) customers not like they are idiots. I would have been far more excited had you stated something like "while you're not quite the fastest, you agressivley continue to work on it, blablabla, but also focus on compatibility and stability" and being able to confirm this rather than "look at us, we're the fastest zomg!" only to find out myself.......no, not really.

Marketing at it's "best".

PS: I will test on both an Intel and AMD machine tonight.

Shinigami-Sama

27th May 2008, 08:57

to be fair
they have 8 thread support and core only has four
so put it on an octobox and it will be faster

but other than I do agree with you

DigitAl56K

27th May 2008, 09:06

@the_corona: I can reliably reproduce that performance on our test box as spec'd in detail on DivX Labs. The system was not specially selected, just one that we had available for testing at the time.

We're currently investigating why the decoder is not performing as well on other systems, which is part of the beta process. Right now we're suspicious that the L2 cache size plays an important role. If that proves to be true we will make adaptations in future betas. The performance information being published at Doom9 and elsewhere by others is helping us to track down these issues. To help us further, when you post performance numbers please also tell us in detail about your CPU as a tool such as CPU-Z reports, including the L2 cache spec.

Beta software is not perfect out of the gate and you'll see further improvements in upcoming releases.

plonk420

27th May 2008, 09:13

beta1:

des-800-wg.mp4 [file (http://www.megaupload.com/?d=VVN85SZ7)]

CoreAVC: User: 7s, kernel: 0s, total: 7s, real: 26s, fps: 1932.0, dfps: 580.7
Divx b1: User: 12s, kernel: 0s, total: 13s, real: 30s, fps: 1179.5, dfps: 500.6
Divx b2: User: 12s, kernel: 0s, total: 13s, real: 28s, fps: 1178.1, dfps: 539.8

des-lossless.mp4 [PNGs 1 (http://www.megaupload.com/?d=DHTBVLH7) / 2 (http://www.megaupload.com/?d=73N7NISE)]

CoreAVC: User: 9s, kernel: 0s, total: 9s, real: 24s, fps: 1679.0, dfps: 634.0
Divx b1: User: 12s, kernel: 0s, total: 13s, real: 30s, fps: 1183.7, dfps: 505.5
Divx b2: User: 12s, kernel: 0s, total: 12s, real: 28s, fps: 1190.9, dfps: 542.7

fallingdown-4800-av-5b.mp4 [link (http://www.megaupload.com/?d=D8QEHW4R)]

CoreAVC: User: 10s, kernel: 0s, total: 10s, real: 55s, fps: 1730.3, dfps: 323.4
Divx b1: User: 16s, kernel: 0s, total: 17s, real: 56s, fps: 1050.2, dfps: 314.5
Divx b2: User: 15s, kernel: 0s, total: 15s, real: 53s, fps: 1147.8, dfps: 335.7

masagin-3200-av.mp4 [link (http://www.megaupload.com/?d=9XC9NN7A)]

CoreAVC: User: 16s, kernel: 0s, total: 16s, real: 73s, fps: 1741.7, dfps: 389.4
Divx b1: User: 28s, kernel: 0s, total: 28s, real: 79s, fps: 1000.4, dfps: 360.7
Divx b2: User: 25s, kernel: 0s, total: 25s, real: 74s, fps: 1104.3, dfps: 383.6

jpod.s01e01.720p.hdtv.x264-hdq.mkv

CoreAVC: User: 36s, kernel: 0s, total: 36s, real: 237s, fps: 1723.7, dfps: 265.6
Divx b1: User: 56s, kernel: 1s, total: 57s, real: 221s, fps: 1095.4, dfps: 285.1
Divx b2: User: 58s, kernel: 1s, total: 60s, real: 236s, fps: 1052.4, dfps: 267.3
User: 54s, kernel: 1s, total: 55s, real: 235s, fps: 1144.6, dfps: 268.2 (2nd run)

test1-200.mkv [link (http://www.megaupload.com/?d=NKXP5QCW)]

CoreAVC: User: 5s, kernel: 0s, total: 5s, real: 20s, fps: 5361.6, dfps: 1474.8
Divx b1: User: 11s, kernel: 0s, total: 11s, real: 22s, fps: 2585.8, dfps: 1306.3
Divx b2: User: 10s, kernel: 0s, total: 11s, real: 21s, fps: 2673.2, dfps: 1378.4

are there any grainy clips to try out there? (what i wouldn't give for a blu-ray of Firefly so i could play or convert Out of Gas...)

plonk420

27th May 2008, 11:27

also, how can i tell if i'm using Beta2? i THINK my results are from b2, but i'm not sure...

edit: i'm rendering to Null
system stats: Phenom 9550 on an RS690 mobo, Vista x64, 4gb DDR2-800, 7600GS. any other important stats i'm missing or things i should try?

SeeMoreDigital

27th May 2008, 16:18

Has anybody here had any success playing AVC video with AAC or AC3 audio streams placed within the .TS container?

AVC "video only" streams placed within the .TS container seem to play okay!

bond

27th May 2008, 16:58

file specs: x264_hp_2pass_720x288_B3-Ref_Ref5_p4x4-i8x8_loop-5_WBP_cabac_cqm-qmatrix
cpu: pentium3 866mhz

result:
DivxH264 42.83fps
ffdshow 64.48fps
CoreAVC 75.57fps

so it doesnt seem to be very fast on non-multithreading cpusrun the same file on beta2:
ffdshow: 64.81
coreavc: 75.53
divxh264: 62.59

so it seems to be now much closer to ffdshow, but not better

it also crashed on a baseline profile sample i created with x264: x264-r285_bp_720x288_B0_Ref5_p8x8-i4x4_loop-5_wbp_mp4box.mp4
if you want i can upload it

the_corona

27th May 2008, 20:37

Ok, some quick tests on my HTPC, on XP SP3 2GB Ram with the following CPU:
http://img382.imageshack.us/img382/1921/cpuzhtpcqb5.jpg

Results are:
- Timecodec priority set to High
- Divx Logo off (all other settings default)
- First Line: Null Renderer, Second Line VMR9

I would go so far as to say it's equaliy fast (good job Divx!) on this machine, even though its still slightly beaten in pretty much every test. But the diff. are so small its completely neglicable (of course it would be good if it could consistantly be faster :-))

74,5 MB 1:59 - 1280x720 @ 23.976 fps 4394 kbps
Core
fps: 793.9, dfps: 117.8
fps: 764.0, dfps: 91.7
Divx Beta 2
fps: 736.3, dfps: 119.5
fps: 686.4, dfps: 91.0

50,7 MB 0:28 - 1280x688 @ 25 fps 14.0 mbps
Core
fps: 962.8, dfps: 74.3
fps: 710.3, dfps: 65.3
Divx Beta 2
fps: 601.8, dfps: 72.0
fps: 677.0, dfps: 62.7

50,5 MB 0:56 - 1280x720 @ 23.976 fps 6790 kbps
Core
fps: 920.3, dfps: 87.2
fps: 760.2, dfps: 72.9
Divx Beta 2
fps: 633.5, dfps: 85.8
fps: 620.0, dfps: 71.4

Something is wrong on my Vista machine, Timecodec seems to be limited to the screens refresh rate, as no clip, no matter how small and no matter what codec gets limited to 60 dfps in VMR9. This wasn't the case last time (Now it only uses like 40% CPU on some clips - but not just Divx, Core too). Any ideas what that could be? I can't really test on AMD now....:-(

DigitAl56K

28th May 2008, 01:44

@the_corona:

Those Intel numbers looks pretty promising - thanks for posting the shot from CPU-Z, that is exactly the kind of information that we need!

To address your earlier point, I have edited the DivX Labs post for beta 1. You can see the new information I've added under our performance charts, and I actually removed the scalability section referring to the 8-core system.

Hope that helps to address your concerns.

To others who have posted performance numbers here, if you can add CPU-Z shots to your posts (or even PM me a link to a screenshot) that would really be helpful.

Flaarn

28th May 2008, 02:17

Has anybody here had any success playing AVC video with AAC or AC3 audio streams placed within the .TS container?

AVC "video only" streams placed within the .TS container seem to play okay!

Most of my clips/samples are broadcast AVC High Definition transport streams & they have either 2.0/5.1 ac3 audio, I have ac3filter installed and playback is ok, with regards to aac, I suspect any issues would be down to the splitter and related audio filters I would think, and how it handles it or not, as the case may be.

Shinigami-Sama

28th May 2008, 09:24

http://mplayer.somestuff.org/misc/h264_sample.7z <- Thanks Mulder

the following are from plonk's following post, thanks as well

des-800-wg.mp4 [file (http://www.megaupload.com/?d=VVN85SZ7)]

fallingdown-4800-av-5b.mp4 [link (http://www.megaupload.com/?d=D8QEHW4R)]

results by Haali's timecodec (http://haali.cs.msu.ru/mkv/timeCodec.exe)

FFDSHOW tryouts build: 1967 -- all defaults
Divx Beta2: all defaults

renderer: null

h264_sample.7z samples:

sample.mp4

Divx: Crash

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 19s, fps: 488.2, dfps: 74.3

~~

sample.avi

Divx: User: 2s, kernel: 0s, total: 3s, real: 12s, fps: 493.3, dfps: 120.7

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 21s, fps: 473.6, dfps: 69.4
~~

sample.mkv

Divx: User: 2s, kernel: 0s, total: 2s, real: 11s, fps: 560.5, dfps: 125.5

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 18s, fps: 446.8, dfps: 78.7

~~

Renderer: VRM 9

sample.mkv

Divx: User: 1s, kernel: 0s, total: 2s, real: 14s, fps: 623.2, dfps: 103.1

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 24s, fps: 442.6, dfps: 59.8

~~

sample.avi

Divx: User: 1s, kernel: 0s, total: 2s, real: 15s, fps: 611.1, dfps: 97.7

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 22s, fps: 442.6, dfps: 67.1

~~

sample.mp4

Divx: Crash

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 24s, fps: 446.8, dfps: 61.2
/H264_sample.7z samples

~~
des-800-wg.mp4

Divx: User: 17s, kernel: 1s, total: 18s, real: 217s, fps: 828.3, dfps: 70.8

FFDSHOW: User: 35s, kernel: 7s, total: 42s, real: 349s, fps: 361.7, dfps: 44.0

~~

fallingdown-4800-av-5b.mp4

Divx: User: 36s, kernel: 3s, total: 39s, real: 366s, fps: 449.5, dfps: 49.0

FFDSHOW: User: 39s, kernel: 8s, total: 48s, real: 583s, fps: 371.2, dfps: 30.7

~~

Renderer: Null

fallingdown-4800-av-5b.mp4

Divx: User: 47s, kernel: 0s, total: 48s, real: 352s, fps: 367.1, dfps: 50.8

FFDSHOW: User: 47s, kernel: 4s, total: 51s, real: 598s, fps: 347.2, dfps: 30.0

~~

des-800-wb.mp4

Divx: User: 36s, kernel: 0s, total: 37s, real: 176s, fps: 414.7, dfps: 87.5

FFDSHOW: User: 38s, kernel: 2s, total: 40s, real: 290s, fps: 377.5, dfps: 53.1

CPU-z info (http://shinigami.ca/cpu-z/cpu-z-pc.jpg)
and some more cache info from cpu-z's latency.exe

Cache latency computation, ver 1.0
www.cpuid.com

Computing ...

stride 4 8 16 32 64 128 256 512
size (Kb)
1 2 3 2 3 2 3 2 2
2 4 3 2 2 2 2 3 2
4 4 10 2 3 3 2 3 3
8 5 5 7 10 9 4 12 6
16 6 7 17 20 33 37 38 40
32 5 7 13 18 24 38 25 38
64 4 8 13 26 43 33 35 42
128 5 4 13 23 44 44 41 36
256 6 8 10 31 42 41 43 32
512 7 14 34 63 96 278 297 144
1024 4 25 36 64 131 398 437 444
2048 8 22 36 65 130 409 447 444
4096 7 17 43 76 138 423 474 395
8192 4 20 38 75 130 475 407 407
16384 7 20 37 78 145 408 412 405
32768 11 21 43 74 133 449 447 404

3 cache levels detected
Level 1 size = 8Kb latency = 3 cycles
Level 2 size = 256Kb latency = 37 cycles
Level 3 size = 512Kb latency = 239 cycles

weird L3
on my CPU?
more likely than I thought

stock speed, will post OC'd results some time later

also I just realized theres 3 other computers(2 laptops) that I can test as well
those will take longer to get to though
all three older econo-models which are being sold for about 400-700$ range

will post more once I grab more samples

also all these tests were done under 'normal' conditions
IE what I normaly do while watching videos
msn, web, winamp going in the background, utorrent, pidgin
average case scenario

plonk420

28th May 2008, 09:42

stride 4 8 16 32 64 128 256 512
size (Kb)
1 3 3 3 3 3 3 3 3
2 3 3 3 3 3 3 3 3
4 3 3 3 3 3 3 3 3
8 3 3 3 3 5 3 3 3
16 3 3 3 3 3 3 3 3
32 3 3 3 3 3 3 3 3
64 3 3 3 3 3 3 3 3
128 3 3 4 5 9 15 15 15
256 3 3 3 6 9 16 15 15
512 3 3 6 10 20 48 48 48
1024 3 4 6 11 21 48 49 50
2048 3 4 12 19 42 118 117 124
4096 3 4 9 21 41 120 123 140
8192 3 3 9 20 40 117 120 135
16384 3 4 9 20 40 118 122 135
32768 4 4 9 21 40 119 126 144

3 cache levels detected
Level 1 size = 64Kb latency = 3 cycles
Level 2 size = 256Kb latency = 15 cycles
Level 3 size = 1024Kb latency = 48 cycles

edit: oops, forgot to pause distributed computing

TEB

28th May 2008, 11:28

Hi. Ive got trouble running timecodec: im getting a empty codec pulldown menu on my windows vista 32 box.
Running graphfilter shows me and ffdshow and hali are infact working as intended... Anyone know what the trouble can be?

plonk420

28th May 2008, 12:14

is it active (as in libavcodec set to decode it) in FFDShow Video Decoder Configuration? (or whatever ffdshow calls it outside of the cccp-project codec pack)

LoRd_MuldeR

28th May 2008, 12:48

FFDSHOW tryouts build: 1967 -- all defaults
Divx Beta2: all defaults

[i]renderer: null

h264_sample.7z samples:

sample.mp4

Divx: Crash

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 19s, fps: 488.2, dfps: 74.3

~~

Oh yes, I can reproduce that crash! But the MKV and AVI version plays fine now...

clsid

28th May 2008, 12:49

TimeCodec requires Haali Media Splitter to be installed in order to function properly.

TEB

28th May 2008, 12:51

is it active (as in libavcodec set to decode it) in FFDShow Video Decoder Configuration? (or whatever ffdshow calls it outside of the cccp-project codec pack)

Im not sure what u mean by "is it active".. What do u define as "it" ? The thing is that timecodec doesnt seem to detect any directshow filters while graphedit does and i can clearly play h.264.ts files and such.. and i see ffdshow pop up.

MatMaul

28th May 2008, 12:59

average dfps with null renderer and indiana_jones_4-tvspot_h720p.mov :
coreavc 1.7 trial : 84.5
ffdshow tryouts rev 1972 : 68.0
divx beta 2 : 81.7
http://img153.imageshack.us/img153/1523/cpuzew8.jpg

plonk420

28th May 2008, 20:45

Im not sure what u mean by "is it active".. What do u define as "it" ? The thing is that timecodec doesnt seem to detect any directshow filters while graphedit does and i can clearly play h.264.ts files and such.. and i see ffdshow pop up.

is ffdshow active as in decoding h.264? or is it only popping up to "process" RAW video?

Shinigami-Sama

28th May 2008, 21:16

Oh yes, I can reproduce that crash! But the MKV and AVI version plays fine now...

heres the info from the crash, happens on both renderers

AppName: timecodec.exe AppVer: 0.0.0.0 ModName: divxdech264.ax
ModVer: 8.1.0.48 Offset: 00018c8f

also why doesn't timecodec have haali renderer in its drop down box?

Shinigami-Sama

28th May 2008, 21:18

Im not sure what u mean by "is it active".. What do u define as "it" ? The thing is that timecodec doesnt seem to detect any directshow filters while graphedit does and i can clearly play h.264.ts files and such.. and i see ffdshow pop up.

you have to select a file first before anything appears in the box

Shinigami-Sama

29th May 2008, 09:09

pm for url

results by Haali's timecodec (http://haali.cs.msu.ru/mkv/timeCodec.exe)

FFDSHOW tryouts build: 1967 -- all defaults
Divx Beta2: all defaults

renderer: null

magasin-3200-av.mp4

Divx: User: 79s, kernel: 1s, total: 80s, real: 513s, fps: 354.3, dfps: 55.6

FFDSHOW: User: 71s, kernel: 6s, total: 78s, real: 844s, fps: 364.1, dfps: 33.8

~~

test-1-200.mkv

Divx: User: 32s, kernel: 1s, total: 33s, real: 127s, fps: 877.7, dfps: 232.0

FFDSHOW: User: 33s, kernel: 2s, total: 36s, real: 238s, fps: 809.1, dfps: 124.4

~~

sample-2-PPS-50fps.mkv

Divx: User: 1s, kernel: 0s, total: 1s, real: 8s, fps: 236.2, dfps: 42.8

FFDSHOW: User: 0s, kernel: 0s, total: 1s, real: 11s, fps: 369.0, dfps: 31.0

~~

SD41_720x576_ref11_bf3.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 542.3, dfps: 120.8

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 20s, fps: 509.1, dfps: 75.8

~~

sw_2_sample.mkv

Divx: User: 3s, kernel: 0s, total: 3s, real: 15s, fps: 352.8, dfps: 76.9

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 478.6, dfps: 50.1

~~
shooter_sample.mkv

Divx: User: 2s, kernel: 0s, total: 3s, real: 15s, fps: 404.0, dfps: 79.9

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 454.5, dfps: 52.9

~~

SD41_1024x544_ref11_bf3.mp4

Divx: User: 3s, kernel: 0s, total: 3s, real: 16s, fps: 451.5, dfps: 91.8

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 27s, fps: 447.4, dfps: 56.6

~~

SD41_720x576_ref15_bf0.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 563.7, dfps: 124.1

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 20s, fps: 479.7, dfps: 76.7

~~

SD41_1024x544_ref15_bf0.mp4

Divx: User: 3s, kernel: 0s, total: 3s, real: 16s, fps: 475.1, dfps: 93.6

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 26s, fps: 477.4, dfps: 58.6

~~

pirates_sample.mkv

Divx: User: 2s, kernel: 0s, total: 3s, real: 15s, fps: 355.6, dfps: 73.8

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 471.8, dfps: 49.5

~~

x3_sample.mkv

Divx: User: 2s, kernel: 0s, total: 3s, real: 18s, fps: 380.3, dfps: 65.1

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 28s, fps: 492.7, dfps: 42.3

~~

Renderer: VRM 9

magasin-3200-av.mp4

Divx: User: 58s, kernel: 218s, total: 276s, real: 575s, fps: 103.3, dfps: 49.6

FFDSHOW: User: 71s, kernel: 6s, total: 78s, real: 844s, fps: 364.1, dfps: 33.8

~~

test1-200.mkv

Divx: User: 19s, kernel: 51s, total: 70s, real: 219s, fps: 417.8, dfps: 134.6

FFDSHOW: User: 32s, kernel: 8s, total: 41s, real: 257s, fps: 721.6, dfps: 114.9

~~

sample-2-PPS-50fps.mkv

Divx: User: 1s, kernel: 0s, total: 1s, real: 9s, fps: 220.7, dfps: 38.7

FFDSHOW: User: 0s, kernel: 0s, total: 0s, real: 12s, fps: 407.2, dfps: 29.8

~~

SD41_720x576_ref11_bf3.mp4

Divx: User: 1s, kernel: 0s, total: 2s, real: 16s, fps: 723.0, dfps: 95.3

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 22s, fps: 422.8, dfps: 68.0

~~

sw_2_sample.mkv

Divx: User: 2s, kernel: 0s, total: 2s, real: 19s, fps: 472.6, dfps: 61.6

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 24s, fps: 447.2, dfps: 47.8

~~

shooter_sample.mkv

Divx: User: 2s, kernel: 5s, total: 8s, real: 19s, fps: 153.0, dfps: 63.0

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 418.8, dfps: 49.7

~~

SD41_1024x544_ref11_bf3.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 20s, fps: 639.6, dfps: 77.4

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 29s, fps: 410.6, dfps: 53.7

~~

SD41_720x576_ref15_bf0.mp4

Divx: User: 1s, kernel: 0s, total: 2s, real: 16s, fps: 779.5, dfps: 97.2

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 560.5, dfps: 62.4

~~

SD41_1024x544_ref15_bf0.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 19s, fps: 665.2, dfps: 79.4

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 28s, fps: 408.9, dfps: 54.1

~~

pirates_sample.mkv

Divx: User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 490.7, dfps: 62.6

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 462.9, dfps: 45.9

~~

x3_sample.mkv

Divx: User: 1s, kernel: 0s, total: 2s, real: 21s, fps: 544.0, dfps: 57.7

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 27s, fps: 452.8, dfps: 44.4

I culled most of the test clips from the MPC-HC thread if you're wondering
more tomorrow
hopefully the laptop

Morbo

29th May 2008, 10:25

How dependant is the GPU with this decoder?

I use a 8800 GTS on desktop,....but would like to do some testing on say an AGP X800XT(coupled to a P4@3ghz).

Of course the 8800 plays 1080p fine,..but the old ATi chokes hard on it(via ffdshow,....do not use core here).

CiNcH

29th May 2008, 12:16

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

Hmm, came across some more similarities. Both, ffdshow and DivX decoder do not connect to Elecard and CyberLink demuxers (crash on connection with GraphStudio which is most likely a bug in GraphStudio, GraphEdit simply refuses connection), and both crash when DVBViewer's DVBSource starts pushing data (resp. when graph is run). Both work flawlessly with Haali Media Splitter.

DVBViewer developer Griga already investigated on the DVBViewer/ffdshow crash and found out that Haali + ffdshow work perfectly with the same source files but seem to have a special communication. Checking pin data, you can see that Haali propagates a lot of information, of particular interest is the Sequence Parameter Set, which DVBSource does not propagate and expects the decoder to find the information within the video stream itself. ffdshow needs this information to work properly...

CiNcH

29th May 2008, 14:20

As I have learnd now, both, ffdshow and DivX seem to expect a MP4/AVC fileheader (within the sequence header) which can't be found in H.264 PES (as used for DVB). DVBViewer developers are reluctant implementing a header conversion as it is not the way it is meant to be.

Here is the pin info propagated by DVBSource filter (and excepted by CyberLink, InterVideo, CoreCodec, MainConcept,...):

2. [DVB Source]/(H.264) -> [MainConcept (Demo) AVC/H.264 Video Decoder]/(AVC/H.264)
Major: MEDIATYPE_Video
Subtype: {8D2D71CB-243F-45E3-B2D8-5FD7967EC09B}
bFixedSizeSamples: FALSE
bTemporalCompression: FALSE
lSampleSize: 1
cbFormat: 132
Format: FORMAT_MPEG2_VIDEO
VIDEOINFOHEADER2:
rcSource: (0,0,1920,1088)
rcTarget: (0,0,0,0)
dwBitRate: 10000000
dwBitErrorRate: 0
AvgTimePerFrame: 400000
dwInterlaceFlags: 1
dwCopyProtectFlags: 0
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0
BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1088
biPlanes: 1
biBitCount: 24
biCompression: 0x34363248
biSizeImage: 6266880
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0
MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 0
dwProfile: 77
dwLevel: 40

MainConcept guys know how to handle that ;) .

DigitAl56K

29th May 2008, 22:24

LoRd_MuldeR: Sample.avi and Sample.mkv should be playing fine as of Beta 2, I have the crash in sample.mp4 logged.

I'm using MPC (media player classic). The decoder is not updating the OSD (on-screen display).

I'm looking at MPC, and I'm not sure what you're referring to by the OSD, can you give me more specific steps to show this problem?

bob0r

29th May 2008, 23:42

x264 has cores*1.5 as threads auto setting.

I think Divx and CoreAVC should have the same feature for decoding!

Dark Shikari

29th May 2008, 23:47

x264 has cores*1.5 as threads auto setting.

I think Divx and CoreAVC should have the same feature for decoding!Depends heavily on the threading implementation and what they've found to be optimal.

cyberbeing

30th May 2008, 01:32

On a ultra low quantizer CRF10 encode I did of a DVD, Divx H264 Beta2 did very well and was less than 1% slower than CoreAVC.

x264 [info]: slice I:723 Avg QP: 6.54 size: 72349
x264 [info]: slice P:24106 Avg QP: 8.22 size: 49321
x264 [info]: slice B:47307 Avg QP: 8.77 size: 19230
x264 [info]: mb I I16..4: 20.3% 56.0% 23.6%
x264 [info]: mb P I16..4: 1.3% 8.7% 1.9% P16..4: 24.9% 25.6% 30.5% 0.5% 0.4% skip: 6.2%
x264 [info]: mb B I16..4: 0.0% 1.2% 0.1% B16..8: 25.9% 1.0% 9.2% direct: 9.8% skip:52.7%
x264 [info]: 8x8 transform intra:73.0% inter:24.1%
x264 [info]: direct mvs spatial:78.7% temporal:21.3%
x264 [info]: ref P 50.0% 15.0% 8.3% 4.5% 3.7% 3.2% 2.8% 1.7% 1.5% 1.6% 1.6% 1.4% 1.4% 1.2% 1.2% 0.9%
x264 [info]: ref B 62.4% 16.8% 6.0% 2.8% 1.9% 1.8% 1.3% 1.0% 1.4% 0.8% 0.8% 0.9% 0.7% 0.8% 0.6%
x264 [info]: kb/s:5719.4

MeGUI x264 Command Line
--crf 10.0 --keyint 240 --min-keyint 12 --deadzone-inter 6 --deadzone-intra 4 --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 6 --partitions all --8x8dct --qpmin 5 --me umh --merange 24 --threads auto --thread-input --sar 1:1 --cqmfile "C:\Program Files\megui\M4G HRM V2.cfg" --progress --no-dct-decimate --no-psnr --no-ssim --aq-mode 1 --aq-metric 3 --aq-strength 0.7 --aq-sensitivity 15.0 --fgo 10

704x480 High 5.1 (CABAC/16 Ref) 5.7Mbps
Timecodec Results VMR9 (all my previous Timecodec results were with null)

FFDshow Rev. 1972
User: 53s, kernel: 8s, total: 61s, real: 539s, fps: 1168.2, dfps: 133.8

CoreAVC 1.7 Pro
User: 19s, kernel: 16s, total: 35s, real: 427s, fps: 2021.3, dfps: 168.9

Divx H264 Beta 2
User: 24s, kernel: 12s, total: 36s, real: 430s, fps: 1961.2, dfps: 167.7

bob0r

30th May 2008, 04:22

Depends heavily on the threading implementation and what they've found to be optimal.

True, but we can't choose how many threads now :)

DigitAl56K

30th May 2008, 04:50

CiNcH: Thanks for your continuing help.

All: It's taking me a little while to work through all the bug reports and PM's I'm receiving here and at DivX Labs. Keep them coming, I'm logging them all slowly but surely!

Shinigami-Sama

30th May 2008, 22:22

pm for url

results by Haali's timecodec (http://haali.cs.msu.ru/mkv/timeCodec.exe)

FFDSHOW tryouts build: 1967 -- all defaults
Divx Beta2: all defaults

CPU-Z info (http://shinigami.ca/cpu-z/cpu-z-laptop.jpg)

renderer: null

magasin-3200-av.mp4

Divx: User: 79s, kernel: 1s, total: 80s, real: 513s, fps: 354.3, dfps: 55.6

FFDSHOW: User: 71s, kernel: 6s, total: 78s, real: 844s, fps: 364.1, dfps: 33.8

~~

test-1-200.mkv

Divx: User: 32s, kernel: 1s, total: 33s, real: 127s, fps: 877.7, dfps: 232.0

FFDSHOW: User: 33s, kernel: 2s, total: 36s, real: 238s, fps: 809.1, dfps: 124.4

~~

sample-2-PPS-50fps.mkv

Divx: User: 1s, kernel: 0s, total: 1s, real: 8s, fps: 236.2, dfps: 42.8

FFDSHOW: User: 0s, kernel: 0s, total: 1s, real: 11s, fps: 369.0, dfps: 31.0

~~

SD41_720x576_ref11_bf3.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 542.3, dfps: 120.8

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 20s, fps: 509.1, dfps: 75.8

~~

sw_2_sample.mkv

Divx: User: 3s, kernel: 0s, total: 3s, real: 15s, fps: 352.8, dfps: 76.9

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 478.6, dfps: 50.1

~~
shooter_sample.mkv

Divx: User: 2s, kernel: 0s, total: 3s, real: 15s, fps: 404.0, dfps: 79.9

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 454.5, dfps: 52.9

~~

SD41_1024x544_ref11_bf3.mp4

Divx: User: 3s, kernel: 0s, total: 3s, real: 16s, fps: 451.5, dfps: 91.8

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 27s, fps: 447.4, dfps: 56.6

~~

SD41_720x576_ref15_bf0.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 12s, fps: 563.7, dfps: 124.1

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 20s, fps: 479.7, dfps: 76.7

~~

SD41_1024x544_ref15_bf0.mp4

Divx: User: 3s, kernel: 0s, total: 3s, real: 16s, fps: 475.1, dfps: 93.6

FFDSHOW: User: 2s, kernel: 0s, total: 3s, real: 26s, fps: 477.4, dfps: 58.6

~~

pirates_sample.mkv

Divx: User: 2s, kernel: 0s, total: 3s, real: 15s, fps: 355.6, dfps: 73.8

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 23s, fps: 471.8, dfps: 49.5

~~

x3_sample.mkv

Divx: User: 2s, kernel: 0s, total: 3s, real: 18s, fps: 380.3, dfps: 65.1

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 28s, fps: 492.7, dfps: 42.3

~~

Renderer: VRM 9

magasin-3200-av.mp4

Divx: User: 58s, kernel: 218s, total: 276s, real: 575s, fps: 103.3, dfps: 49.6

FFDSHOW: User: 71s, kernel: 6s, total: 78s, real: 844s, fps: 364.1, dfps: 33.8

~~

test1-200.mkv

Divx: User: 19s, kernel: 51s, total: 70s, real: 219s, fps: 417.8, dfps: 134.6

FFDSHOW: User: 32s, kernel: 8s, total: 41s, real: 257s, fps: 721.6, dfps: 114.9

~~

sample-2-PPS-50fps.mkv

Divx: User: 1s, kernel: 0s, total: 1s, real: 9s, fps: 220.7, dfps: 38.7

FFDSHOW: User: 0s, kernel: 0s, total: 0s, real: 12s, fps: 407.2, dfps: 29.8

~~

SD41_720x576_ref11_bf3.mp4

Divx: User: 1s, kernel: 0s, total: 2s, real: 16s, fps: 723.0, dfps: 95.3

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 22s, fps: 422.8, dfps: 68.0

~~

sw_2_sample.mkv

Divx: User: 2s, kernel: 0s, total: 2s, real: 19s, fps: 472.6, dfps: 61.6

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 24s, fps: 447.2, dfps: 47.8

~~

shooter_sample.mkv

Divx: User: 2s, kernel: 5s, total: 8s, real: 19s, fps: 153.0, dfps: 63.0

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 418.8, dfps: 49.7

~~

SD41_1024x544_ref11_bf3.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 20s, fps: 639.6, dfps: 77.4

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 29s, fps: 410.6, dfps: 53.7

~~

SD41_720x576_ref15_bf0.mp4

Divx: User: 1s, kernel: 0s, total: 2s, real: 16s, fps: 779.5, dfps: 97.2

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 560.5, dfps: 62.4

~~

SD41_1024x544_ref15_bf0.mp4

Divx: User: 2s, kernel: 0s, total: 2s, real: 19s, fps: 665.2, dfps: 79.4

FFDSHOW: User: 3s, kernel: 0s, total: 3s, real: 28s, fps: 408.9, dfps: 54.1

~~

pirates_sample.mkv

Divx: User: 2s, kernel: 0s, total: 2s, real: 18s, fps: 490.7, dfps: 62.6

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 25s, fps: 462.9, dfps: 45.9

~~

x3_sample.mkv

Divx: User: 1s, kernel: 0s, total: 2s, real: 21s, fps: 544.0, dfps: 57.7

FFDSHOW: User: 2s, kernel: 0s, total: 2s, real: 27s, fps: 452.8, dfps: 44.4

DeathTheSheep

31st May 2008, 04:01

With my t7200 C2D, when directshowsourcing a long 720p anime AVC mkv with Haali splitter through Virtualdub, I get the following for total time (average of 3 trials each) running an "analysis pass" with direct stream copy (so no video actually rendered to screen):
CoreAVC Pro 1.7 defaults: 8min07sec
DivX-b2 no logo, defaults: 7min31sec
ffdshow r1943sse defaults: 12min11sec

Direct stream copy was used so that little overhead resulted from the "analysis pass." For me, this is a real-life scenario. All three decoders utilized 100% cpu, though ffdshow fluctuated a bit more than the others. Source encoded with...r714, 3ref, 3bframes, and so on. I made sure the hard-drive was not the limiting factor, just to make sure...

Yep, DivX is the clear winner here. Beta2 also seems to work fine with VfW, from what I've tried...great! The filter loads up in WMP more speedily than ffdshow or CoreAVC, too, which is literally the first thing I noticed when I installed it. ;) I have not tried beta 1, ever.

Dark Shikari

31st May 2008, 07:36

DivX beats CoreAVC by a small margin (~5%) when decoding LosslessTouhou.mkv.

By the way, thanks for implementing lossless mode :p:cool:

DigitAl56K

1st June 2008, 02:02

Dark Shikari & DeathTheSheep, this is good to hear!

For others: We're continuing to improve the decoder for better performance on a wider range of processors. Stay tuned on that front.

By the way, thanks for implementing lossless mode :p:cool:

If you have any remaining problem clips let me know and I can set up an account for you to upload them. In fact, if you have a selection of lossless clips from various encoders I'd love to get them into our regression suite to ensure compatibility going forward. Shoot me a PM if you'd like to help us out and I'll hook you up with an FTP account :)

Dark Shikari

1st June 2008, 02:11

In fact, if you have a selection of lossless clips from various encodersWait, there are multiple encoders that support lossless mode? ;)

I've heard there are, but I haven't seen any on the consumer level; at least from what I can see none of the ones installed on my computer do.

If you want samples for regression tests, check out Jarod's file repository (http://files.x264.nl/); if I recall correctly it has a whole load of broadcast streams of various bizarre formats (MBAFF, PAFF, etc) that you can test your decoder on.

DigitAl56K

1st June 2008, 02:15

When you wrote:

One general note about lossless: the original lossless profile specified has been removed from the H.264 standard (but everyone still uses it).

I had taken "everyone" to mean "many encoders". If there are no others that makes our life easier!

Is there is anonymous ftp access to the file system(s) publicly presented via http at x264.nl? Or could you upload a zip for me if I give you an FTP account?

Dark Shikari

1st June 2008, 02:19

I had taken "everyone" to mean "many encoders". If there are no others that makes our life easier!I'm not sure, of course, since there are a ton of features that aren't widely used but still have implementations.

Example: Grayscale mode. Extremely easy to support in any encoder and took me only a few lines of code in x264 to support, but basically useless because it only saves a couple bits (literally) by not coding chroma CBP. I know Ateme and some others have this implemented too. Despite the fact that its widely "implemented," you'll probably never actually find a stream that uses it... :p (nor does ffmpeg support decoding it).

LoRd_MuldeR

2nd June 2008, 03:22

Result for "Big Buck Bunny" animated short movie:

E:\HD\big_buck_bunny_1080p_h264.mov
MP4/MOV, 1920 x 1080, Main@L4.1, CAVLC, 9282 kbps,

[ffdshow-tryouts SVN-r1977]
User: 80s, kernel: 0s, total: 81s, real: 123s, fps: 175.1, dfps: 116.1

[DivX H.264 Decoder Beta-2]
User: 40s, kernel: 0s, total: 41s, real: 66s, fps: 346.0, dfps: 214.9

No CoreAVC Decoder this time. Trial period has expired :o

sparky

2nd June 2008, 04:07

Checking pin data, you can see that Haali propagates a lot of information, of particular interest is the Sequence Parameter Set, which DVBSource does not propagate and expects the decoder to find the information within the video stream itself. ffdshow needs this information to work properly...

DivX decoder can interpret the SPS, whether it is in the sequence header or in the video stream. For instance, it will work with the standard DirectShow AVI demux if H.264 is properly packetized into AVI (with a copy of all relevant SPS and PPS in every keyframe chunk). So will ffdshow and CoreAVC.

I seem to recall that there is a known issue - the decoder may crash if it receives a frame for which it does not have SPS/PPS yet. Maybe that's what's happening.

As I have learnd now, both, ffdshow and DivX seem to expect a MP4/AVC fileheader (within the sequence header) which can't be found in H.264 PES (as used for DVB). DVBViewer developers are reluctant implementing a header conversion as it is not the way it is meant to be.

I'm not sure what you mean by that.

Wait, there are multiple encoders that support lossless mode?

I've been able to create a few lossless clips with JM. The version I used (12.2 IIRC) had a few bugs but it worked well enough to test lossless implementation.

BTW, good to know that it's working for you.

basically useless because it only saves a couple bits (literally) by not coding chroma CBP.

It may only save a couple bits by not coding chroma CBP, but it saves considerable amount of decoding time because your frames are 33% smaller and you don't have to do chroma MC.

According to my tests, CoreAVC does not support monochrome either, 1.6 for sure, I think 1.7 does not either. (Even though it's much easier to implement than lossless)

CiNcH

2nd June 2008, 08:04

Correction:

DVBSource delivers only the H.264 Elementary Stream. PES header is removed. Contained PTS are converted to DirectShow-PTS and presented via the IMediaSample-Interface.

Sagittaire

2nd June 2008, 22:19

Wait, there are multiple encoders that support lossless mode? ;)

I've heard there are, but I haven't seen any on the consumer level; at least from what I can see none of the ones installed on my computer do.

If you want samples for regression tests, check out Jarod's file repository (http://files.x264.nl/); if I recall correctly it has a whole load of broadcast streams of various bizarre formats (MBAFF, PAFF, etc) that you can test your decoder on.

x264, elecard and Ateme support lossless mode.
Ateme support mbaff and paff.
Ateme support fgm, subpartition, adaptative inloop matrix.

You can certainely find stream with these profil on this forum.

plonk420

4th June 2008, 06:53

i DID notice one thing upon a quick examination just now... skipping around in a file took a while to give me a picture (my encode was only 3 refs, 5 bframes), opposed to CoreAVC's near instant image.

DigitAl56K

4th June 2008, 07:34

@plonk420: I see that also, we can try to improve it.

MarcioAB

5th June 2008, 02:20

I'm looking at MPC, and I'm not sure what you're referring to by the OSD, can you give me more specific steps to show this problem?

Sorry, I mixed things. I was so used with ffdshow OSD that I forgot DivX was not going through that.

TEB

5th June 2008, 11:08

Processors Information
------------------------------------------------------------------------------------

Processor 1 (ID = 0)
Number of cores 1 (max 1)
Number of threads 2 (max 2)
Name Intel Pentium 4 560
Codename Prescott
Specification Intel(R) Pentium(R) 4 CPU 3.60GHz
Package Socket 775 LGA (platform ID = 4h)
CPUID F.3.4
Extended CPUID F.3
Core Stepping D0
Technology 90 nm
Core Speed 3667.6 MHz (18.0 x 203.8 MHz)
Rated Bus speed 815.0 MHz
Stock frequency 3600 MHz
Instructions sets MMX, SSE, SSE2, SSE3
L1 Data cache 16 KBytes, 8-way set associative, 64-byte line size
Trace cache 12 Kuops, 8-way set associative
L2 cache 1024 KBytes, 8-way set associative, 64-byte line size
FID/VID Control no
Features
----------------------------------------------------------
FFDSHOW 1975 -> null renderer
User: 5s, kernel: 1s, total: 7s, real: 183s, fps: 64.3, dfps: 2.7
DivX H.264 Filter Beta2 -->null renderer
User: 7s, kernel: 3s, total: 10s, real: 103s, fps: 46.4, dfps: 4.8

falcon2000eg

5th June 2008, 18:57

this file play fine with coreavc and ffdshow but crashed the divx codec it is an old file with old x264 build here media info output

General
Complete name : E:\vip film\aristocrates\the aristocrats1.mkv
Format : Matroska
File size : 140 MiB
Duration : 44mn 18s
Overal bit rate : 441 Kbps
Encoded date : UTC 2005-12-04 15:06:35
Writing application : mkvmerge v1.6.0 ('Ist das so') built on Oct 14 2005 15:22:41
Writing library : libebml v0.7.5 + libmatroska v0.7.7

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 44mn 16s
Nominal bit rate : 375 Kbps
Width : 400 pixels
Height : 272 pixels
Display aspect ratio : 1.471
Frame rate : 29.970 fps
Original frame rate : 14.985 fps
Colorimetry : 4:2:0
Scan type : Progressive
Bits/(Pixel*Frame) : 0.115
Writing library : x264 core 41 svn-381M
Encoding settings : cabac=1 / ref=1 / deblock=1:1:1 / analyse=0x3:0x133 / me=hex / subme=6 / brdo=1 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / chroma_qp_offset=0 / slices=1 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=2 / wpredb=1 / keyint=350 / keyint_min=25 / scenecut=40 / pass=2 / bitrate=375 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=10 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30
Language : English

Audio
Format : Vorbis
Codec ID : A_VORBIS
Duration : 44mn 18s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz

here is a sample
http://www.4shared.com/file/50241124/2d772013/the_aristocrats-1-001.html

BetaBoy

9th June 2008, 10:52

LoRd_MuldeR

10th June 2008, 02:05

Okay, I repeated the test. This time with CoreAVC included :)

E:\HD\big_buck_bunny_1080p_h264.mov
MP4/MOV, 1920 x 1080, Main@L4.1, CAVLC, 9282 kbps

[DivX H.264 Decoder Beta-2]
User: 41s, kernel: 0s, total: 41s, real: 65s, fps: 344.7, dfps: 217.7

[CoreAVC Decoder Professional v1.7.0]
User: 31s, kernel: 0s, total: 31s, real: 59s, fps: 448.9, dfps: 241.0

[ffdshow-tryouts SVN-r1993]
User: 81s, kernel: 0s, total: 84s, real: 130s, fps: 169.5, dfps: 109.7

E:\HD\PlanetEarthSample.mkv
MKV, 1920 x 1088, High@L5.1, CABAC, 5008 kbps

[DivX H.264 Decoder Beta-2]
User: 22s, kernel: 0s, total: 23s, real: 62s, fps: 431.3, dfps: 160.2

[CoreAVC Decoder Professional v1.7.0]
User: 16s, kernel: 0s, total: 17s, real: 93s, fps: 587.2, dfps: 106.9

[ffdshow-tryouts SVN-r1993]
User: 25s, kernel: 8s, total: 34s, real: 362s, fps: 290.2, dfps: 27.6

sparky

10th June 2008, 07:50

[DivX H.264 Decoder Beta-2]
User: 40s, kernel: 0s, total: 43s, real: 76s, fps: 332.5, dfps: 186.9

[CoreAVC Decoder Professional v1.7.0]
User: 31s, kernel: 0s, total: 31s, real: 59s, fps: 448.9, dfps: 241.0

Why did it go from 215 dfps to 187 dfps?

Is this with the full movie (700 mb)?

LoRd_MuldeR

10th June 2008, 11:06

Why did it go from 215 dfps to 187 dfps?

Is this with the full movie (700 mb)?

I'm not sure. And yes, it's the entire movie (691 MB).

EDIT: Just did another pass and it seems that ~215 is the correct value. Something must have screwed up my result last time :o

Sophocles

14th June 2008, 15:59

The system used for this demo specifications are. CPU Screenshot included;

CPU: E8400 Overclocked to 3549.7 MHz

Memory: 2 Gigabytes of Corsair

Graphcis Card: ATI HD 3870:

Time Code: Video HighRes.mkv (downloaded from this thread)

ffdshow:

null:User: 58s, kernel: 0s, total: 58s, real: 59s, fps: 8.6, dfps: 8.5

VMR9: User: 59s, kernel: 0s, total: 59s, real: 59s, fps: 8.4, dfps: 8.3

CoreAVC Pro 1.7 is unable to open this file.

DiVx H.264 Beta 2:

null: User: 6s, kernel: 0s, total: 6s, real: 27s, fps: 75.3, dfps: 18.5

VMR9: User: 6s, kernel: 0s, total: 7s, real: 27s, fps: 68.2, dfps: 17.9

Video: Downloaded from this thread: 300.2006.1080p.BluRay.DTS.x264-CtrlHD.sample.noaudio

ffdshow:

null” User: 34s, kernel: 0s, total: 34s, real: 34s, fps: 46.4, dfps: 45.9

VMR9: User: 35s, kernel: 0s, total: 35s, real: 36s, fps: 44.8, dfps: 44.0

CoreAVC:

Null: User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 784.1, dfps: 99.9

VMR9: User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 708.4, dfps: 95.4

DiVx H.264 Beta 2:

null:User: 2s, kernel: 0s, total: 2s, real: 16s, fps: 537.8, dfps: 99.4

VMR9: User: 2s, kernel: 0s, total: 2s, real: 17s, fps: 590.3, dfps: 93.2

Sophocles

14th June 2008, 16:04

Sorry I forgot to add a screenhot for the previous post. As noted with all the other tests DiVx H.264 decoder did well but ran consistently slower than CoreAVC, except for the first run using the High Res Clip where it wouldn't even open.

http://www.dvdhounds.com/forums/attachment.php?attachmentid=687&stc=1

BetaBoy

14th June 2008, 17:50

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

I wanted to comment 2160p.... you are getting errors in playing back such files in CoreAVC 1.x because we do not support it at this time. However, in CoreAVC 2.0 we have already added Quad HDTV support and if needed, we can add it to the upcoming 1.8.x or 1.9.x, but we would prefer not too at this time, as such resolutions could potentially slow decoding.

x264lover

15th June 2008, 00:46

Sorry, didn't mean to interrupt but... will we able to encode into DivX h.264 with your tools or is it just a h264 decoder? And will DivX support other audio codecs such FLAC, AAC?

I know it's off-topic but I gotta ask it.

See you.

Sophocles

15th June 2008, 03:11

x264lover

One of my hopes as well, although we can already do that with other *.264 flavors. My hope is that it will also be followed by a DiVx certified player that will permit burning an HD backup to a standard dual layered disc with 720P/1080P.:devil:

x264lover

15th June 2008, 21:51

Yeah!

It would be great.
I love x264, I mean watching videos and all with this codec but I don't know how to use it properly.

Sophocles

15th June 2008, 22:24

I love x264, I mean watching videos and all with this codec but I don't know how to use it properly.

You will get the hang of it with a little time and practice. If you want to start encoding your own movies there are some decent easier to use applications that will simplify things a bit such as FairUse Wizard.

DigitAl56K

16th June 2008, 19:57

the_corona

17th June 2008, 11:21

I'll be starting another thread on that in a little while ;)

Can you give us any news on the decoder? Is a Beta 3 coming soon? Can we expect further speed improvement or is work focused on bug-fixes/compatibility from now on?

:thanks:

sparky

17th June 2008, 21:12

Beta 3 is coming. Current target is early next week. You'll see some further speed improvements. We're mostly targeting AMD's and older systems, but you'll see some gains on a P4 as well. We're also fixing bugs as we become aware of them. Beta 3 will take care of DVBViewer issues and fix a number of reported crashes.

Shinigami-Sama

18th June 2008, 09:45

well I just got xp64 running on my laptop
xp32 coming soon
looking forward to doing some tests now that all my machines are running

iwod

23rd June 2008, 07:39

I'll be starting another thread on that in a little while ;)

How long is a little while :devil::devil:

DigitAl56K

23rd June 2008, 16:34

How long is a little while :devil::devil:

I prefer to avoid giving dates because we don't want to set your expectations too early - the next beta will be released when we're happy with it. It's possible that you might see something this week :)

Ajax_Undone

25th June 2008, 19:25

@ DigitAl56K wondering if you guys there at Divx are going to be releasing Divx 7 with A CLI Codec... It would be Very beneficial if you did for avs apps...

DigitAl56K

25th June 2008, 21:11

Yes, there will be a CLI encoder available and it will accept avs input.

Sophocles

25th June 2008, 22:47

Yes, there will be a CLI encoder available and it will accept avs input.

I'm interested, when can we know more?

Ajax_Undone

25th June 2008, 23:05

Thank you very very much

DigitAl56K

25th June 2008, 23:27

Sophocles,

It's currently in its early stages, and again I don't like committing to dates before I'm reasonably confident in them, but a "baseline" will first be released through Project Rémoulade at DivX Labs and we'll then be looking for feedback on the kind of features and adaptations you would most like to see in order to fulfill your needs and to make it suitable for becoming an option in some of the GUI front-ends that are developed by Doom9 members.

Sophocles

26th June 2008, 01:59

Good enough, thanks for the reply. There seems a lot to look forward too.;)

Ranguvar

26th June 2008, 03:11

Yes, there will be a CLI encoder available and it will accept avs input.
Keep the good news coming :D

Can I ask a question, though? As Dark Shikari said before, why doesn't DivX simply make an x264 GUI? I'm sure there's a reason, but I'm not business-minded enough to see it :)

Dark Shikari

26th June 2008, 03:17

Keep the good news coming :D

Can I ask a question, though? As Dark Shikari said before, why doesn't DivX simply make an x264 GUI? I'm sure there's a reason, but I'm not business-minded enough to see it :)Probably because they spent a lot of money buying Mainconcept and now have to justify that purchase somehow ;) </cynic>

DigitAl56K

26th June 2008, 04:17

Well, there are many reasons. Here are a few off the top of my head: x264 is GPL'd, so what happens when we want to license an encoder library to a commercial partner so that their software can output DivX files? What do we do if we want to add some algorithm enhancement to an encoder without necessarily divulging the source? How can we provide an encoder to CE manufacturers and others that absolutely must comply to all of the profile specifications that we develop when such strict compliance is not necessarily the goal of x264? If we want to distribute an encoder to end users we can also be held accountable for all of the intellectual property it contains, so we have to be able to be accountable for and thus to control the source - something that isn't possible with x264.

I could go on, but these are just a few reasons why we might need to have our own encoder even though we recognize that x264 itself is also very good encoder.

HTH

Probably because they spent a lot of money buying Mainconcept and now have to justify that purchase somehow ;) </cynic>

If only the accounting team were busy justifying expenditures of that size! Then it would be easier for me to slip some new hardware into our budget! ;)

Dark Shikari

26th June 2008, 04:30

Well, there are many reasons. Here are a few off the top of my head: x264 is GPL'd, so what happens when we want to license an encoder library to a commercial partner so that their software can output DivX files?You do what my company does--separate binary. It adds nearly no overhead and is trivial--and better yet it lets you use other GPL'd libraries in the process too.
What do we do if we want to add some algorithm enhancement to an encoder without necessarily divulging the source?You stop being so secretive, especially considering rule 1 of video encoding: any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product. ;)How can we provide an encoder to CE manufacturers and others that absolutely must comply to all of the profile specifications that we develop when such strict compliance is not necessarily the goal of x264?x264 is strictly compliant. Even if it wasn't, you could fix that, and such a thing would be far easier than developing a (worse) competitor.If we want to distribute an encoder to end users we can also be held accountable for all of the intellectual property it contains, so we have to be able to be accountable for and thus to control the source - something that isn't possible with x264.If you think making your own encoder makes you immune to MPEG-LA fees, you are sorely mistaken; the MPEG-LA does not make any distinction between GPL'd and non-GPL'd encoders when dealing with license fees.

I do understand the real reason though: NIH syndrome (http://en.wikipedia.org/wiki/Not_Invented_Here). Its very hard to convince a company to avoid re-inventing the wheel.

I welcome yet another competitor though; the more encoders there are in the marketplace, the better x264 looks by comparison.

DigitAl56K

26th June 2008, 04:41

Well, as I've said, there are many reasons and those are just a few. Perhaps it does not help to list them all and do a play-by-play analysis, so I'm not going to dissect your reply. The fact is that there will be a DivX encoder.

NIH Syndrome = funny ;)

Sophocles

26th June 2008, 05:21

Probably because they spent a lot of money buying Mainconcept

Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?

Shinigami-Sama

26th June 2008, 05:23

Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?

purchase agreements
bad code?
lazy coders on that project?
broke after that purchase?
ect
ect
ect

Dark Shikari

26th June 2008, 05:28

Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?How do you know that isn't what they're doing? :devil:

cyberbeing

26th June 2008, 06:43

I welcome yet another competitor though; the more encoders there are in the marketplace, the better x264 looks by comparison.
Which just confuses the issue for some of us since DiVx now owns Mainconcept which has an H.264 encoder, and which already has a simple graphical user interface? What's to prevent DiVx from adapting Mainconcept's encoder to suit DiVx' needs?
How do you know that isn't what they're doing? :devil:
I never really considered Mainconcept's H264 to be a poor encoder (isn't it the best of the commercial encoders???). In MSU's comparison tests it was neck and neck with x264 and in some cases better. I know x264 has made a lot of improvements since then but you never know, after some improvements of their own and a written-from-scratch Divx H264 encoder based on Mainconcept H264 IP, it may actually end up equal to or better than x264 :eek:.

If they really do succeed with making a decoder all around faster than CoreAVC then I give them a 50% chance of making an encoder that is all around better than x264 ;).

If they don't succeed with making a decoder all around faster than CoreAVC then I give them a 10% chance :devil:.

DigitAl56K

26th June 2008, 09:11

Guys, let's not turn this into a deathmatch before we've even released anything! I can understand that Dark Shikari is proud of x264. At the same time (and looking across threads) there is no need to suggest that because x264 exists nobody else should make an encoder or that one product must perfectly fit the needs of everybody. What's wrong with having two choices and the freedom to pick whichever you like, knowing that either can get the job done well?

With regard to MainConcept and DivX: over time knowledge will be shared, people from either team will contribute their expertise to each others work and hopefully the products that are produced become stronger as a result. At some point although there are two businesses and each may offer different products and services we should consider that they're not necessarily entirely separate. For example, anyone who has installed the DivX H.264 Decoder beta is already running code that brings together work from both teams.

Back to the encoder: If you have joined Project Rémoulade you'll have access to it as soon as it becomes available. Before then this discussion is likely to turn into a lot of speculation ;)

Dark Shikari

26th June 2008, 13:31

I never really considered Mainconcept's H264 to be a poor encoder (isn't it the best of the commercial encoders???). In MSU's comparison tests it was neck and neck with x264 and in some cases better.Unfortunately for Mainconcept, in the real world, PSNR doesn't actually ensure good visual quality. (http://mirror05.x264.nl/Dark/x264vsElecard/) :p (Note "Elecard" uses the Mainconcept SDK here). No psy RDO was used in that test either (didn't exist at the time). I've done more tests on other clips since then and Mainconcept pretty much sucks visually. Its a complete blurry mess that throws away detail at every chance it gets. It does have some advantages over x264--more aggressive B-frame decision and hierarchical motion estimation--but this isn't enough to compensate for its weaknesses IMO.

The MSU tests are honestly quite awful; just look back to their Xvid vs DivX comparisons where they turned on the deblocking on one product but not on the other and then went on for quite some time about how the one with the deblocker looked better.

If you are looking for a good encoder that can compete with x264, you might want to look more towards the professional arena, where you can find such industry leaders as Ateme and Scientific Atlanta. Of course, as companies that primarily produce hardware encoders, they have their own advantages and disadvantages with regard to quality.

Anyways, on the issue of DivX, I agree with Digital56k here; this is getting silly given that none of us have actually seen the encoder yet ;)

stax76

26th June 2008, 14:25

A cmdl encoder and mkv is what the people want, that was quite obvious. From my view a cmdl encoder means I have to build and maintain a GUI and every other frontend has to build and maintain GUI. Every guide and tutorial can only target a certain frontend. While it might be fun for some frontend authors to code codec relatated features like a codec GUI, for me it's not. Different frontends would only provide different subsets of available options, different bugs, poor documentation, does DivX really wants such a mess? I have a proposal how to achieve a unified GUI, if nobody else like DivX will build it, then I might do. It's not hard at all, all you need is a portable executable build with a tool like QT, wxWidgets, Lazarus etc., you have to pass the settings to the app using a simple file and after the app is closed read the settings back, thats it, every kid can program something like that. To make it realy easy for frontend authors the file would just contain the command line, this way the frontend wouldn't even have to build the command line. A frontend author might be able to add complete DivX support to his application in less than an hour.

Sergey A. Sablin

26th June 2008, 14:59

It does have some advantages over x264--more aggressive B-frame decision and hierarchical motion estimation--but this isn't enough to compensate for its weaknesses IMO.

hierarchical motion estimation? where do you take all these? :D

Dark Shikari

26th June 2008, 15:03

hierarchical motion estimation? where do you take all these? :DI'm making a fair assumption that Mainconcept uses pyramidal motion search unless the documentation is wrong and "motion search range" is actually "motion vector range". Feel free to correct me, of course.

No sane algorithm except pyramidal/hierarchical allows search ranges such as "64", "128", "256", "512", etc.

Of course, the documentation could just be wrong (not unlikely, given that one part of it stated that the non-SATD MB comparison metric was Median Absolute Difference rather than what it actually is, Mean Absolute Difference). Can't blame everyone for bad English :p

It'd probably be pretty easy to test whether its pyramidal or not; create a contrived situation where an object moves 200 pixels across the screen with no warning and see if the motion search catches it.

Sergey A. Sablin

26th June 2008, 20:32

I'm making a fair assumption that Mainconcept uses pyramidal motion search unless the documentation is wrong and "motion search range" is actually "motion vector range". Feel free to correct me, of course.

No sane algorithm except pyramidal/hierarchical allows search ranges such as "64", "128", "256", "512", etc.

nobody actually cares about real algorithm search range at any particular point, while everybody cares about the distance from (0,0), ie real movement, which can be caught by algorithm.

Of course, the documentation could just be wrong (not unlikely, given that one part of it stated that the non-SATD MB comparison metric was Median Absolute Difference rather than what it actually is, Mean Absolute Difference). Can't blame everyone for bad English :p
after this you simply can't, cause it is Sum of Absolute Differences. ;)

Dark Shikari

26th June 2008, 20:41

after this you simply can't, cause it is Sum of Absolute Differences. ;)Mean Absolute Difference is a bad, but often-used name in technical papers for SAD. They mean the same thing of course. Blame Elecard for using it in their docs/interface for the Mainconcept SDK encoder.

Manao

26th June 2008, 20:45

No sane algorithm except pyramidal/hierarchical allows search ranges such as "64", "128", "256", "512", etc.A logarithmic search could (see http://forum.doom9.org/showthread.php?p=1152700#post1152700).
any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product.I disagree. Trellis quantization can't be RE'd just looking at the encoded file. So are motion estimation, bframe decision, scene cut decision, and most high level algorithms.

Dark Shikari

26th June 2008, 20:48

A logarithmic search could (see http://forum.doom9.org/showthread.php?p=1152700#post1152700).The odds of a really really long range logarithmic search being lucky enough to get a good candidate when checking at 256-pixel range is absurdly low, to the point where its basically useless; in fact I would suspect false positives would make it worse than a shorter range search. That's why UMH checks so many locations; a diamond search at range 256 is totally useless. A pyramidal search, however, does allow you to do such long-range checks effectively.
I disagree. Trellis quantization can't be RE'd just looking at the encoded file. So are motion estimation, bframe decision, scene cut decision, and most high level algorithms.True. Some of them can be reverse-engineered code-wise, of course. If something is truly new both theoretically and practically, its highly doubtful it would be reverse-engineered simply because one would have nothing to go on in doing so.

Ajax_Undone

27th June 2008, 05:22

@ Stax

I think Divx should hold a competition for the best GUI front end app for there CLI Codec... When released of course...;)

sparky

29th June 2008, 11:00

You stop being so secretive, especially considering rule 1 of video encoding: any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product.

It does not seem to work that way with video decoding. CoreAVC has been out with essentially no performance improvements for close to 2 years and yet no one has been able to release a superior competing project via reverse engineering.

If you think making your own encoder makes you immune to MPEG-LA fees, you are sorely mistaken; the MPEG-LA does not make any distinction between GPL'd and non-GPL'd encoders when
dealing with license fees.

One of the basic principles of a successful company: ensuring freedom to operate. If you're going to release a project, make sure it does not infringe any patents. It's much easier to do that with a clean-room implementation than with an open-source project that was written by unknown developers implementing algorithms of unknown origin. Can you be sure that, in all the years of development of x264, no one has slipped any patented motion search or scene detection algorithms into it? Or even filed a patent application for an algorithm before committing the code into your repository? We certainly can't, either. The difference between you and DivX is, if something like that comes up, no one will bother going after poor x264 folks, they will sue any companies using x264's source. If we were to use your project, either by redistributing the source or simply by referring users to you, we'd potentially be risking losing huge amounts of money on litigation.

Not sure if that falls under "NIH syndrome".

(Disclaimer: I am not a lawyer, all my interpretations of patent law are nothing but my personal conjectures, and I'm not making any statements, either explicit or implied, about any projects we ever used, do use at the present time, or might use at any time in the future - open-source or otherwise, and this whole discussion is purely theoretical)

You stop being so secretive, especially considering rule 1 of video encoding: any sufficiently useful algorithm can and will be reverse-engineered, made better, and implemented in a competitor's product.

Usefulness is not limited to algorithms.

A while ago I needed to do a test comparing, among other things, x.264 and DivX MPEG-4 encoder. Obviously, x.264 beat DivX in terms of overall PSNR. Less obviously, x.264 beat DivX in terms of PSNR at fixed encoding frame rate. One area where DivX was far superior was maximum encoding speed. With a 640x352 source, DivX exceeded 200 fps in two fastest modes, and the fastest combination of features I could find for x.264 could only reach ~42 fps (albeit with higher PSNR). My conclusion was that x.264 was never targeted at high-speed encoding.

Suppose that we come out with an encoder that can do reasonable-quality H.264 at the maximum speed that is five times what x.264 can achieve. (equivalently, an encoder that can encode in real time in 5 times the resolution) Can you match this result? Sure. Will reverse engineering help you achieve that goal? Not much - mostly you'll just have to optimize your existing code.

Dark Shikari

29th June 2008, 16:21

It does not seem to work that way with video decoding. CoreAVC has been out with essentially no performance improvements for close to 2 years and yet no one has been able to release a superior competing project via reverse engineering.CoreAVC is primarily faster because of things that are not something that one would keep "secret"; efficient code structure which could be done by any good coder if they really really put a lot of effort into it. Their assembly was quite good--and has already all been reverse-engineered by various people. The main issue is that there's nobody who is willing to work full-time on, say, ffmpeg, for the purpose of making it faster than CoreAVC. The amount of work involved would be very large.

If I had to give a single big reason CoreAVC is fast, its because of the SSE2 deblocking, which exists in x264 but hasn't been ported to ffmpeg.One of the basic principles of a successful company: ensuring freedom to operate. If you're going to release a project, make sure it does not infringe any patents. It's much easier to do that with a clean-room implementation than with an open-source project that was written by unknown developers implementing algorithms of unknown origin. Can you be sure that, in all the years of development of x264, no one has slipped any patented motion search or scene detection algorithms into it? Or even filed a patent application for an algorithm before committing the code into your repository? We certainly can't, either. The difference between you and DivX is, if something like that comes up, no one will bother going after poor x264 folks, they will sue any companies using x264's source. If we were to use your project, either by redistributing the source or simply by referring users to you, we'd potentially be risking losing huge amounts of money on litigation.

Not sure if that falls under "NIH syndrome".

(Disclaimer: I am not a lawyer, all my interpretations of patent law are nothing but my personal conjectures, and I'm not making any statements, either explicit or implied, about any projects we ever used, do use at the present time, or might use at any time in the future - open-source or otherwise, and this whole discussion is purely theoretical)It is physically impossible to implement an H.264 encoder without violating thousands of patents. This is why the MPEG-LA exists and charges licensing fees.

A while ago I needed to do a test comparing, among other things, x.264 and DivX MPEG-4 encoder. Obviously, x.264 beat DivX in terms of overall PSNR. Less obviously, x.264 beat DivX in terms of PSNR at fixed encoding frame rate. One area where DivX was far superior was maximum encoding speed. With a 640x352 source, DivX exceeded 200 fps in two fastest modes, and the fastest combination of features I could find for x.264 could only reach ~42 fps (albeit with higher PSNR). My conclusion was that x.264 was never targeted at high-speed encoding.Not really a good test, because you're comparing between two totally different video standards, one of which is inherently a lot more complex. x264 also probably didn't have modes that were as fast as DivX's. Of course, now, things have changed; x264 is now faster on fastest settings than Xvid is on fastest settings. I haven't tested DivX, but I've never heard about DivX being particularly faster than Xvid (in singlethreaded mode at least, which is what I was testing).Suppose that we come out with an encoder that can do reasonable-quality H.264 at the maximum speed that is five times what x.264 can achieve. (equivalently, an encoder that can encode in real time in 5 times the resolution) Can you match this result? Sure. Will reverse engineering help you achieve that goal? Not much - mostly you'll just have to optimize your existing code.There is a certain amount of inherent overhead in encoding--things that you have to do in order to perform the encoding process. It will be quite obvious from the output stream which parts of the encoding such a "fast encoder" chose to ignore, since at that kind of speed you're not even going to be considering any complex algorithms and most "speed-related" decisions will be partition related or intra prediction mode related. I might not be able to tell the difference between an encoder using "subme 1" or "subme 3", but if an encoder comes up with a "subme 0" it will likely be quite clear what shortcut was taken.

Just glancing at x264's profile now, here's some "non-subtle" things you could do to make an encoder faster than x264 when using absolute fastest Baseline Profile settings:

1) Use fewer predictors for the motion search (saves ~1%)
2) Drop the qpel motion search entirely (saves ~5%)
3) Don't analyse intra blocks at all in inter frames (saves ~2%)

Note that since some of these reduce quality at a given bitrate dramatically, to compensate one will have to use higher bitrate--which slows down the entropy encoding.

sparky

29th June 2008, 19:49

It is physically impossible to implement an H.264 encoder without violating thousands of patents. This is why the MPEG-LA exists and charges licensing fees.

You're missing the point. First there's a group of well known patents that belongs to members of MPEG-LA and they have to be implemented by anyone who implements an H.264 encoder or decoder. We'd pay license fees for that and we'd be covered. The problem really is that there may be other _unknown_ patents outside the standard patent pool covering parts of x.264. Theoretically, someone could even file a patent application for a certain motion search algorithm, slip that algorithm into x.264 as "subme=5", wait for a successful company to come up, and then go after them in court for patent infringement, with the intention of cashing in.

Not really a good test, because you're comparing between two totally different video standards, one of which is inherently a lot more complex. x264 also probably didn't have modes that were as fast as DivX's. Of course, now, things have changed; x264 is now faster on fastest settings than Xvid is on fastest settings. I haven't tested DivX, but I've never heard about DivX being particularly faster than Xvid (in singlethreaded mode at least, which is what I was testing).

My tests were done about a year ago. I also haven't heard about XviD being particularly faster than DivX in fast modes. I could rerun some tests if you suggest fast settings for x.264.

It will be quite obvious from the output stream which parts of the encoding such a "fast encoder" chose to ignore, since at that kind of speed you're not even going to be considering any complex algorithms

You could have two encoders implementing *exactly* the same algorithms and yet you'd have massive differences in performance. Decoder operation is fully specified in standard, but speeds of different decoders can be vastly different. Just compare JM vs. ffmpeg vs. CoreAVC. Even if you rip all the assembly out of CoreAVC and stick it into JM (theoretically speaking) JM would still be a lot slower.

neuron2

29th June 2008, 19:51

Guys, this is OT for this thread. Please take it to PM ir start a new thread. Thank you.

sparky

29th June 2008, 19:55

Guys, this is OT for this thread. Please take it to PM ir start a new thread. Thank you.

We're discussing a future command-line H.264 encoder that's part of Project Remoulade, how's that off-topic?

neuron2

29th June 2008, 20:03

@sparky

You're discussing patents, etc. Take it elsewhere and don't argue about it here in this thread. Send me a PM if you have any objection.

This thread is DivX's thread about their Project Remoulade. Don't hijack it for other purposes.

Shinigami-Sama

29th June 2008, 23:49

I have to agree with sparky Don
patents relate to the encoder so I fail to see how its off topic
these posts on the other hand complaining about it...

neuron2

30th June 2008, 00:33

I clearly instructed you guys to send me a PM if you want to discuss it and you have wilfully ignored my instructions. So you are struck for rule 16. Again, do not pollute this thread with off-topic argumentation.

mdoubledragon

13th July 2008, 08:26

Is this thread still active? Are we still going to see announcements of next releases of Divx AVC decoder here? There has been no activity since two weeks now.

cyberbeing

13th July 2008, 10:19

I'm assuming the long delay means that the Beta 3 decoder and the first Beta of the AVC encoder will be released at the same time.
Either that or sparky (Divx Team) has just decided to keep Beta 3 for himself because he is now feeling unloved at Doom9 after the Divx h264 encoder (incl. patent) discussion get shut down by neuron2. :devil:

DigitAl56K

14th July 2008, 20:03

We're trying to make sure that Beta 3 will work nicely with a handful of DVB apps and this has taken some time because we need to support more splitters, improve format negotiations, provide better error resilience and so forth. We don't require the betas to be perfect but we are aiming for a certain standard of quality before we release.

Sorry for the delay, I'm really hoping we'll get this out in the very near future and that it will be worth the wait.

Dark Shikari

14th July 2008, 20:13

Good news: DivX supports PCM macroblocks correctly in both CABAC and CAVLC, as far as all my tests show; Elecard Streameye doesn't, Carbon Coder doesn't, and ffmpeg didn't (until Michael and I fixed the bugs, that is--latest revision is fine).

Only other decoders I've tested that support them correctly are CoreAVC and JM.

cyberbeing

15th July 2008, 08:07

DigitAl56K, were you able to get the performance increases you were expecting (+10-15%?) out of AMD cpus in order to put it in line performance wise with CoreAVC?

mdoubledragon

16th July 2008, 08:04

sparky

16th July 2008, 19:15

Also, please inform us if the AVC decoder is going to make it to Linux or are we again going to be left out in cold? If CoreAVC was released for Linux, I am sure people would be willing to pay for it. Divx AVC decoder can exploit this market segment to gain its due share rapidly, but that is if you guys let it.

Our AVC decoder already works on Linux, but there are other issues involved besides just making it work. We can't release the source, so it would have to be binary-only, compiled for specific x86 Linux distros. Our internal API is not compatible with existing apps. The low-maintenance option would be to release it and forget it, but I don't think it would be used much. Alternatively, we'd have to work on adding a mplayer/libavcodec-compatible API wrapper, work with open-source developers to integrate it into existing apps, that detracts time from core development, and the question remains how open those developers would be to helping us.

We will look into available options. At this time I think that an eventual release of an AVC decoder for Linux in some form is likely but not a sure thing.