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]

Originally Posted by IgorC

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?

[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.ph...99#post1171099 ! Why ?

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

[clsid]

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

[Mercury_22]

Originally Posted by clsid

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

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

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

[IgorC]

Originally Posted by Sharktooth

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.



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]

Originally Posted by 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.

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

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