Dear All,
according to its specifications, the Jpeg encoder for the DM642 can generate only non-interleaved jpeg images.
Non-interleaved jpeg means that the three color component are placed on three different scans, i.e. in the generated jpeg there are three starts of scan header structures (marker 0xFFDA) each followed by Y, Cb, Cy scans.
In interleaved jpeg, on the contrary, the color components are interleaved in a single scan.
Even if the non-interleaved jpeg complies with the standard, many jpeg decoder does not support it. The jpeg decoder provided with the codec engine of the DM365, for instance, does not support this kind of jpeg. Also the jpeg decoder of the android sdk does not support it.
In order to have a more exploitable jpeg I ported the libjpeg on the DM642. The problem is that it is very slow and I can encode with difficulty the 25 fps half-D1 using all the CPU (so that my audio encoding algorithm stops to work), when the target is 50 fps half-D1.
Profiling the encoding the DCT is not so heavy (7% of cycles): the problem is the Huffman coding.
I would like to collect some suggestion in order to optimize the libjepeg code, now I use the -O3 option, or maybe there is some alternative I have not considered to get the jpeg.