IPP 5.3 and H.264 UMC threading implementation

[sschaem]

I need clarification on this behaviour:

H.264 decoder withN (2+) threaded enabled always use a minimum of 50% of the CPU (even decoding a trivial 160x120 10fps video on a 2.4ghz core2 processor)

Forcing single thread decoding drop the CPU usage dramaticly (to under 5% ) So I see a 10x CPU efficiency boost by disabling IPP5.3 threading code.

VTune point the issue to thread synchronization function spinlocking....

Is this a known limitation/issue ? or I'm missing something on how to invoke the decoder?

So at this time I'm forcing single threaded decoding , work like a charm, but most system cant decode 1080p on a single core... I need to enable 2+ core.

Right now I hack my code to detect the resolution and only enable 2+ thread when the res is 1080... and I cant sleep at night!

Thanks for any details,

Stephan

PS: I used to work with DirectShow for many years, nearly drove me insane, that only to say thatI can clearly recognize UMC to be a gem. Many thanks for investing into this effort, its massive and brilliant work.

[Intel_C_Intel]

We are seeing the same exact problem since upgrading to 5.3 from 5.1.

In addition, we have lots and lots of H264 movies that no longer play correctly that did play just fine with the 5.1 LIB (and of course, work with other media players).

Given the amount of time and effort required to download and install the upgrade only to then learn that it *must* use VC8 (even though the release notes clearly say it will work with VC6), and thus have to go out and get VC8, install, setup and convert projects.... we are *really*disappointed that the 'upgrade' is in fact a substantial step backwards.

Update: We found some of the decoding issues. They are related to the change in behaviour of GetFrame() in the H264 decoder. We are all very, very surprised to see this function act differently with the same data vs. 5.1. Since the is *NO* documentation on how these functions work, one would expect at least a comment in the source saying that it now returns with data left in the buffer whereas the previous version consumed all the data.

It still loads up 100% of one of the cores meaning that 50% CPU utilization is a given even for the simplest of streams.

[sschaem]

So whats the scoop on that ?

I see more user have posted the same problem, some actually dropping IPP h264from their software because of this.

Any word? even stuff like "We dont plan to fix this problem in the near future" would be apreciated.

Stephan