Perfomance of ffdshow and divx decoders.

[IgorC]

Tested video:
http://trailers.divx.com/Dreamworks/SharkTale_HD.zip

Tested versions:
ffdshow 2079 clsid (no pp)
divx 6.8.4 (no pp, no logo)



System: Windows XP SP3. CPU E2160 (2x1.8Ghz)

Results:
NULL:
ffdshow
User: 20s, kernel: 0s, total: 20s, real: 20s, fps: 166.6, dfps: 166.4

divx
User: 11s, kernel: 0s, total: 11s, real: 23s, fps: 293.1, dfps: 139.6


VMR9:
ffdshow
User: 22s, kernel: 0s, total: 22s, real: 38s, fps: 147.5, dfps: 87.9

divx 6.8.4
User: 8s, kernel: 0s, total: 9s, real: 44s, fps: 358.9, dfps: 74.9

ffdshow uses 1 core (50% LOAD)
divx uses 2 cores (approx. 80% load)

[Dark Shikari]

Its completely meaningless to do a benchmark between two different levels of threading; all it says is that "multithreading is faster than single threaded decoding," which everyone knows is obvious.

A more useful comparison would be to either do:

1. A singlethreaded-only comparison
or
2. A comparison of ffmpeg-mt and divx, both multithreaded

[IgorC]

ffdshow was faster
look at real time.

[Dark Shikari]

ffdshow was faster
look at real time.Oh wow, I didn't even notice that.

OK, so this means despite it being a war of single vs multithreaded, DivX still loses? :p

[IgorC]

Yes.
I also very surprised by the results.
Divx also loads CPU more during playback in MPC than ffdshow does.

[clsid]

Things will even be better when ffmpeg-mt hits trunk :)

[MasterNobody]

Tested video: same SharkTale sample.

Tested versions:
ffdshow_rev2079_20080815_clsid (pp: off)
DivX 6.8.4 (pp: off; film effect: off; logo: off)

System: Windows XP SP3. CPU Athlon XP 1600+ (1.4Ghz)

NULL
ffdshow
User: 39s, kernel: 0s, total: 39s, real: 42s, fps: 85.1, dfps: 79.2

DivX
User: 52s, kernel: 0s, total: 52s, real: 56s, fps: 63.4, dfps: 58.9

VMR9
ffdshow
User: 36s, kernel: 0s, total: 36s, real: 49s, fps: 90.9, dfps: 67.6

DivX
User: 54s, kernel: 0s, total: 55s, real: 72s, fps: 60.5, dfps: 46.0
Conclusion: ffdhow significantly faster on one core CPU.

[IgorC]

So is it really important to have multithreading for ASP when actual cpus only use one core to decode 720p 1080p videos in real time?

Does it matter if there is mp3 decoder multithreaded for quad cores?

Does it matter if there is AVC decoder for quad cores when 2 cores are more than enough to decode high bitrate dual layer Blu-ray streams?

With all respect to Divx I see no usefullness around support of multithreading (2 cores) for ASP and (4 cores) for H.264 decoding.
1 core is enough to decode ASP and 2 are for H.264.

[Sharktooth]

why not? try playing uber high res encodes...

[Mercury_22]

Still with ffdshow on Intel video "cards" I can't play many DX50 (encoder XviD build 37) files on Vista=EVR output (just a black screen & sound) but with DivX I can play the same files without no problem look here http://forum.doom9.org/showthread.php?p=1171099#post1171099 ! Why ? :helpful:

The problem it's only with ffdshow + Intel video "cards" & EVR output ! :confused: if I use VMR output or other video card ffdshow has no problem :confused:

[clsid]

That clearly is a driver issue. You could try disabling YV12 in ffdshow output settings.

[Mercury_22]

That clearly is a driver issue. You could try disabling YV12 in ffdshow output settings.

That was my first thought too, but why DivX it's working ? (no YV12 in DivX ?) :helpful:

Thanks ! Disabling YV12 in ffdshow output settings solved the "problem" :thanks:

Do you know how to do the same thing in MPC-HC (if I use internal filters) ? :helpful:

[IgorC]

why not? try playing uber high res encodes...
I mean practical use: 720-1080p 3-20 mbps. >99%
Nowdays it's very uncommon to see video with resolution bigger than 1080p.

[clsid]

The DivX decoder perhaps outputs YUY2 by default.

The internal decoder of MPC-HC has no option to configure the output colorspace.

Disabling YV12 is just a workaround. The real source of the problem are buggy drivers.

[IgorC]

For the same shark tale HD trailer.
For both divx and ffdshow: MPC (ovelay mixer), no pp, no logo, no film effect, nothing.

http://img206.imageshack.us/img206/5220/allgz0.png

VLC is considerably faster due to built-in decoder.

[CruNcher]

VLC and Mplayer are generaly less CPU intensive because of their close relationship with the parser/splitter/decoder/renderer (no dshow and windows overhead like reading extensions in registry, searching correct filter, creating a graph and initializing sync over dshow, optimal parseing/decoding workflow ect) result = reduced start time and alot less CPU stress @ playback ah and no dshow hell problems, for people without Hardware Accelleration capabilities there is no other choice then VLC or Mplayer except maybe CorePlayer and Betaplayer ;)

[Mercury_22]

The DivX decoder perhaps outputs YUY2 by default.

The internal decoder of MPC-HC has no option to configure the output colorspace.

Disabling YV12 is just a workaround. The real source of the problem are buggy drivers.

Just to let you know Xvid it's working too because it has "NO Force" on Output Colorspace by default which means that ffdshow it's the only one ( and MPC-HC ) who has Forced by default YV12 Colorspace output :confused:

[clsid]

I don't think that ffdshow forces YV12 output. If the renderer accepts YV12 input, then it will get YV12 input. The fact that your drivers are buggy is not ffdshow's fault. Note that I am certainly not an expert with regard to ffdshow's code. I have read and understood maybe 1% of it.

[tetsuo55]

i wonder, how does the xvid decoder compare?

It's not only about speed of decoding but also about image quality (does the same frame look the same on all decoders?)
And the handeling of errors and broken files.

[IgorC]

Afaik Xvid and ffdshow produce the same output without pp as it indicates exactly the same SSIM result http://forum.doom9.org/showthread.php?t=119262
Don't know about other decoders.

[tetsuo55]

Afaik Xvid and ffdshow produce the same output without pp as it indicates exactly the same SSIM result http://forum.doom9.org/showthread.php?t=119262
Don't know about other decoders.

Ok so Xvid and ffdshow used to have equal quality with PP disabled.
Xvid was way slower too even with PP disabled.

Could you re-test xvid like you did above? those results from dec 2006 might look different now?

All in all it looks like i should use ffdshow instead of xvid..

I wonder how the deblocking filter for ffdshow now compares to xvid?

[clsid]

Xvid has not been updated in almost a year. So I highly doubt you'll see much of a difference.

[tetsuo55]

Xvid has not been updated in almost a year. So I highly doubt you'll see much of a difference.

then ffdshow wins by default, i'm going to switch to ffdshow for Divx/Xvid then.

Are there any other codecs where ffdshow beats the competition?

[Sharktooth]

Wmv...

[CruNcher]

WMV (VC-1) might someone should add only in Software Decoding mode vs GPU that is not the case then even Microsofts Decoder beats it (but this is a general case and goes for every Codec that is GPU supported, wich are Mpeg-2,VC-1 and H.264 currently) :)

[IgorC]

I obtained different results with dual channel memory.

The same PC e2160, WinXP sp3.
Null output.

Old results with DDR2 512 MB 667 Mhz single channel
ffdshow dfps: 166.4
Divx dfps: 139.6

Results with DDR2 1Gbx2 667 Mhz dual channel
ffdshow 2489 dfps: 192.0
Divx dfps: 211.9
CorePlayer 1.2.5 dfps: 235.7

ffdshow and Coreplayer use 1 core (~50% load)
Divx uses 2 cores (~ 80% load)

[squid_80]

Wow, someone actually testing CorePlayer? Could you try a test clip with qpel and/or gmc?

[IgorC]

I don't have qpel gmc videos right now.