comparison of ffmpeg and ipp H264 decoder

[mehrotra_kk]

Hi,
Is there a performance comparison available for ffmpeg and ipp H264 decoder?

We have made the performance comparison between the two and found that ipp (v 6.1) H264 decoder (single thread) is substantially poor(by more than 40% in terms of cpu taken) than ffmpeg h264 decoder (single thread) for any type of input H264 encoded clip. Is this an expected behaviour for ipp to be substantially bad as compared to ffmpeg?

People in our organistaion are pushing us to change to ffmpeg from ipp if this is really the case . what should we do now?


regards
abhishek mehrotra

[mehrotra_kk]

did i put my query in the right place? no replies yet?

abhishek

[Chao_Y_Intel]

Hello,

CPU usage is not a good way to benchmark for performance. There is some known problem that may increase CPU usage.

Please check this article:

http://software.intel.com/en-us/forums/showthread.php?t=75300

I also suggest you to use \audio-video-codecs\application\umc_h264_dec_con application to benchmark the H.264 performance. It provides more accurate performance data.

Thanks,
Chao

[mehrotra_kk]

I cannot use the application \audio-video-codecs\application\umc_h264_dec_con for ffmpeg. so the only way i can compare is use my own application and keeping all other things constant use ipp H264 decoder in first run and use ffmpeg H264 decoder in the second run and then take the cpu % or the time taken to complete decoding (when number of threads are 1 and we have single session running). This is how i am comparing right now.

Still i did not get the answer to my main (important) query that whether there is any performance comparison available between ipp H264 dec and ffmpeg H264 dec?

regards
abhishek

[Chao_Y_Intel]

abhishek,

I do not have FFMPEG data at hand now, but the result is something unexpected for me.

When you test with umc_h264_dec_con application, it just wants to make sure your test get the correct performance with IPP UMC sample code.

umc_h264_dec_con measure the the maxum framerate that the decoder can achieve. If you want to measure the one threading performance, set threading to 1 to run the application. For example, the H.264 decoder can achieve 120 fps. Suppose the frame rate is 30. so it only needs possibly about 25% ( 30/120) CPU resource ( one core).

Thanks,
Chao

[mehrotra_kk]

Ok ,
i understand your point. The way you are calculating the performance is good if we take both ipp h264 decoder and ffmpeg decoder with single thread. Even if i calculate your ways the performance of ffmpeg H264 decoder is substantially (40%-50%) better than ipp h264 decoder without a doubt.

Here is more info on comparison: for a typical HD input 30 fps, ipp h264 decoder gives max 18-20fps o/p whereas ffmpeg h264 decoder gives max 35 fps o/p on a 2.3 ghz linux m/c.


I have another query: is intel ipp sample code / library using cache on the system in an optimal way? I did not see anywhere that the code is cache sensistive.


It would be good if you can provide some camparative analysis between intel and ffmpeg codecs.

What I would really like to see from intel is that the codecs from intel on single thread should be as good as codecs from ffmpeg on single thread.

Another point is that with every release i would expect intel to publish the performance improvements with respect to previous release all comparisons done with single thread (in the case here i was expecting a performance comparison of all the codecs from ipp 6.1 to ipp 7).


regards
abhishek

[PaulF_IntelCorp]

Hello Abhishek,

Providing performance comparisons between IPP functions and other applications is a very tricky business. There are simply too many variables involved in any such comparison.

In the case of ffmpeg comparisons, you also have to be sure you are comparing encode/decode at similar quality levels. Measuring the performance of one encoder operating at a high quality level against one operating at a low quality level will provide substantially different measurements, but will not necessarily be a "fair" comparison of the two encoders.

It is my understanding that ffmpeg does use some "short cuts" in their codecs to achieve higher performance, at the expense of some quality degradation. For many users this is not an issue. There is no simple way for us to make a one-to-one comparison that will necessarily fit your requirements -- so we cannot provide any comparisons. You need to make those comparisons yourself and determine which tradeoffs are appropriate to your application.

Our goal with the UMC library that is built on the IPP functions is to provide you with an example that can be incorporated into your own application and can be customized to meet your specific needs, and still achieve a high level of performance on Intel hardware.

Paul