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

[CiNcH]

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]

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]

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

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?

Also can you tell which colorspace is negotiated between the decoder and the renderer, in both cases?

[Sergey A. Sablin]

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

[the_corona]

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]

Why did you use an old ffdshow version?

[the_corona]

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]

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

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]

D56k

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

[sparky]

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]

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]

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]

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]

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]

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]

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]

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.

[KEROLiUKAS]

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]

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]

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]

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]

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]

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

[DigitAl56K]

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

[Disabled]

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]

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

[Beastie Boy]

Is a Linux version planned?

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

[bond]

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]

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

[Dark Shikari]

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]

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

[LoRd_MuldeR]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[Yufi]

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

[kosmonaut]

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? :)

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

[KEROLiUKAS]

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.