Hi all,

well, I am working with the AT91sam9m10-g45-ek (rev A) devkit,
I've done some tests to display (or simply decompress into a RGB file) a JPEG file.

And I meet some performance problems !

When I use the gst-launch program (that use the plug-in that use the hardware acceleration, the x170 DSP), I get my picture (800*600) in about 600-700 ms.
And I've cross compiled the djpeg library (that is purely a software jpeg library), and with the same picture, it takes about 50ms.
It's not normal to get 600ms to decompress a jpeg file with a specialized hardware, when pure software just takes 50ms ????!!!!

Could someone tell me using the gst-launch (to take advantage of the hardware acceleration) (or maybe there is another way?), if there is a better command line than the one I'm using ?
Using different buffers configuration maybe, or allowing to avoid some useless pause ?

I don't understand why it seems to sleep so long time !!!

time gst-launch filesrc location=/var/ramdisk/mypicture.jpg ! x170 output=RGB16 output_width=800 output_height=480 codec=JPEG ! fbdevsink sync=false

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
real 0m 0.72s
user 0m 0.63s
sys 0m 0.07s

Thanks for any help you could give me (and to the community)

I 've mentioned the software JPEG decompression takes 50ms,
in fact this takes between 180ms and 400ms.
But that's still faster than the hardware decompression using gst-launch.

Someone could tell me if there's a way to reduce the time spent in gst-launch. (600-700ms to decompress a JPEG using the x170 Hantro hardware dsp) !!
I'm thinking particularly about PAUSED... status.

thanks a lot.

Alex

I finally found a way to get more traces (I maybe previously redirected the standard output to /dev/null !)

Well, using gst-launch I have these messages:

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 48953596 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

What I see is that something takes 48 ms (I don't know what?), but the total spent time is about 700ms, but I see at the screen the picture a very short time before gst-launch is terminated.

Maybe the buffer is drained. Do you feed the data through the DMA controller. If so, try to fiddle around with the DMA settings:
1) MATRIX_MCFG
2) DMAC_GCFG - LOCK_IF, LOCK_B, LOCK_IF_L
3) DMAC_CTRLB - try to choose different layers for source and destination