Jpeg image decoding using VPU on iMX53 running Android 2.3

[prabhurammuruga]

Hi

I am working on iMX 53 and Android 2.3 build,

I need to use the VPU to decode jpeg images (software decoding works fine but going for VPU to achieve better performance)
I had checked the mxc_vpu_test and the config files(config_dec), there are options for decoding movie formats like MJPG , MPEG etc. But I could not see any options for JPEG image decoding ???

So is it possible to use VPU for decoding image file (jpg | bmp | png) efficiently ?

And will I be able to get considerable performance improvement over software decoding.

Software decoding takes ~300 ms in  NativeImageDecode() method and I use BitmapFactory,

Thank you,

[LeonardoSandova]

I found this related discussion thread: Re: i.MX6Q: Can the VPU decode JPEG image?

[VladanJovanovic]

I'd recommend to check "i.MX5x_Linux_VPU_API.pdf" for some info on how you'd do that in your app, maybe mxc_vpu_test doesn't implement MJPEG functionality (haven't checked though). There's STD_MJPG enum described there, which seems to imply MJPEG. Not sure if it means you can also do standard JPEGs, but I see documents mentions that there is "Baseline ISO/IEC 10918-1 JPEG compliance".

[mwsealey · Accepted solution]

The real answer is; yes, it can decode a standard JPEG - the MJPEG format is not much more than a slim container, and turns out to be simply a sequence of appended JPEG data once per frame. MJPEG multiplexer tools really just strip JPEG header information and use the container format instead (some MJPEG movies are AVI, you can put it in a Quicktime movie, or there is a slightly special MJPEG format).

The real question is what does the VPU expect as the start of data for JPEG and what real information does it need on top? Once you figure that out it should just work. This should all be handled and explained in libvpu or libvpuwrapper depending on the BSP version; the VPU test tool just uses this library very simply (most of it is an MPEG4 stream parser, actually rendering the video is tiny) so just looping over the different parts of the encoded JPEG until it renders would be an okay test. The i.MX6 has a somewhat separate JPEG decoder unit compared to the i.MX5.

There were some restrictions on the size of JPEG able to be decoded last time I read through, something like 2048x2048 so your run of the mill 5 megapixel image from your camera won't be able to be accelerated, and rendering tiny thumbnails on a desktop file manager or so probably spends more time doing kernel context switch to the VPU driver than decoding the JPEG (look at libjpeg-turbo optimizations from Linaro for this). I do recall errata too; but by the time you run into them you cannot tell except from a subjective view (there is no functional test to see if the JPEG will not be "compatible" and use software instead).

Decoding BMP: there will be no benefit as BMP is usually totally uncompressed, the only real issue is you end up decoding them backwards (they are encoded bottom to top) and RLE compression (rarely used) is possible on a 7MHz 68000 without any significantly user noticeable time taken. I think I saw some LZW compressed BMP once; but just once.

PNG decompression would be a great acceleration, QorIQ for example has a gzip compression/decompression engine inside which would help for this (probably by passing it through /dev/crypto or the netlink crypto API on Linux) - if we ever see a new i.MX processor this would certainly reduce power consumption and improve for loading webpages and so on both in total (most web content is compressed with gzip).. but the i.MX5 and 6 simply don't have this or any reasonable analogue. There are some patches around for libpng to use NEON which give a reasonable, but barely noticable performance gain mainly through more efficient memory copy (Qualcomm wrote these) and something for the adler32 algorithm.. and some for libpng written by Linaro that improve the built-in libpng filter functions (if you load a RGBA8888 PNG and ask for a target buffer format of RGB565 it will convert it to this with NEON for you).