[FFmpeg-devel] Jpeg2000 decoders comparison

Claudio Freire klaussfreire at gmail.com
Fri Jul 5 23:22:16 CEST 2013


On Fri, Jul 5, 2013 at 2:39 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Thu, Jul 04, 2013 at 08:13:43PM -0300, Claudio Freire wrote:
>> On Thu, Jul 4, 2013 at 7:54 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Thu, Jul 04, 2013 at 10:34:06PM +0200, Nicolas BERTRAND wrote:
>> >> Hi,
>> >> I made some perf test to compare jpeg2000 native deocoder with libopenjpeg.
>> >> I compared the perfs according the number of threads allocated and
>> >> the number of resolutions levels (lowres)
>> >>
>> >>
>> >> The strange stuff is: in a many core machine( bi xeon, so 12coresx2)
>> >> , the jpeg2000 decoder is blocled at some fps, and addition of cores
>> >> no help at all. In reverse with libopenjpeg more we add core, more
>> >> the decode is fast.
>> >> In a 4 coresx2 machines. the results are more as expected, and
>> >> native jpeg2000 decoder is faster in almost all cases.
>> >>
>> >> In native jpeg2000 decoder, code looks somewhere blocked or still
>> >> waiting. But where or how? Right now, no idea why.
>> >
>> > A simple way to find out where something is blocked (assuming its
>> > blocked alot) is to use gdb and hit crtl-c and the look at the
>> > backtraces of all the threads
>>
>> Another simple way is to use oprofile[0]
>
> I don't know why anyone (excluding people for mysterious reasons stuck
> at ancient kernel versions) would still be using oprofile.
> perf is a replacement that doesn't need special kernel modules,
> and is far easier to use.

Or, rather, stuck with a hammer because everything's a nail.

I didn't know perf. Gotta get to know it.


More information about the ffmpeg-devel mailing list