DM365 jpeg decoder with interleaved images

The libjpeg provided by indipendent jpeg group supports interleaved scans. Nevertheless it runs very very slowly on DM365. This the performance comparison between the TI Jpeg codec (on a interleaved image) and ijpeg library;

First case:

jpeg encode with TI lib at 25 fps
jpeg decode with TI lib at 11 fps
CPU load 50%

Second case:

jpeg encode with TI lib at 6 fps
jpeg decode with IJPEG lib at  2 fps
CPU load 100%

It's a pity that TI lib does not support non-interleaved scans.

Can you please elaborate your eaxct need. The various input anf output formats supported are listed in Q13 of http://processors.wiki.ti.com/index.php/DM365_Codecs_FAQ.

regards

Yashwant

Thank you Yashwant,

    I need to decompress with the DM365 the jpeg encoded by the jpeg encoder of the TMS320DM642 which provides non-interleaved scans.

The DM365 decoder can not support non interleaved scans.

If you see, at the i/p side, Jpeg decoder of DM365 indeed supports planer format like YUV 420. Is that not OK ? 

regards

Yashwant

Hi, 
    I refer to the non-interleaved scan. According to the library specs it is not supported.

The same issue was addressed here:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/8046/246563.aspx#246563

Is it possible (is there some documentation) to exploit the co-processor to make faster the standard IJPEG lib?

Thank you!

Can you please share a Jpeg file? We would like to check it out.

regards

Yashwant

Dear Yashwant,

   here I share two files:

2821.jpegs.zip

 The DM365.jpg was encoded with the DM365 TI jpeg library and can be decoded with the same library.

The DM642 was encoded with the DM642 lib and can not be decoded with the DM365 TI lib.

The difference in the scans can be observed looking at the marker which defines the scan header structure 0xFFDA.

DM365, interleaved scan (there is only one scan with the three components interleaved):

0xFFDA (marker)

0x000C (scan header length)

0x03 (numer of components in scan)

0x01 (Scan component selector: scan 1)

0x00 (DC bits 0:3 and AC bits 4:7 entropy coding table selector for scan 1)

0x02 (Scan component selector: scan 2)

0x11 (DC bits 0:3 and AC bits 4:7 entropy coding table selector for scan 2)

0x03 (Scan component selector: scan 3)

0x11 (DC bits 0:3 and AC bits 4:7 entropy coding table selector for scan 3)

...other scan header bytes followed by the scan for the three components

Hi,

I got a confused, Sorry. DM36x only support interleaved scan.

But you should be able to configure DM642 Jpeg encoder to produce single interleaved scan. I check the Jpeg user guide for DM642, it should be able to encode streams compatible with DM365. Can you use that option ?

regards

Yashwant

Hi,
   as far as I am concerned, the DM642 can not produce a single interleaved scan.

Look also at the constraints defined in the introduction (section 1) of the SPRA704: "Each scan contains a complete image component. A single image component is contained in a scan" i.e. non-interleaved. 

Regards.

Hi Yashwant,

   I don't know anything about gstreamer but it seems it can be used to write custom codec which exploit the co-processor instead of arm. If it is the case I could use gstreamer to port the IJPEG library which, I tested, supports interleaved scans. What do you think about this possibility?

thank you.