[FFmpeg-devel] Jpeg2000 decoders comparison

[Reimar Döffinger]

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.