DM6446 jpeg decoder example

Are you trying to build this to run on the ARM or DSP?  If you only want to run it on the ARM, you can use it as a local codec and do not need a server.

On the DSP.   We have gotten "fim"  to decode and show a jpeg image on the ARM (albeit on a later kernel level), but are trying to call the jpegdec remote server.

I have a couple of variables in play here.

• I am not 100% that I have built the remote codec server correctly. But I think I have.
  
  • There are numerous app notes and wiki pages on what seems to be an evolving method of building the codec servers, it is hard to tell which method should be used as the examples I have found often use the older depreciated methods
  • I HAVE been able to add a  mpeg3dec DSP codec to the dvsdk  "decode" demo and it runs fine, and I followed the same procedure to build the jpegdec codec and server, so I assume it is built correctly.
• what I dont have is an arm-side example of an application that will call the jpegdec image decoder.
  • We had a previous application on the DM355 that caled its jpeg decoder fine
  • I have found a DM355 jpegdec example in ths sdk
  • I have found a CCS  test example buried in the jpegdec codec package itself
  • I have found a DMAI display example, but does not invoke a codec.
• I(we) are not experienced davinci programmers. My programmer has developed embedded linux systems for many years, but the TI toolchain is a different, very complicated  beast. I am a hardware / assembly level  guy trying to brute force these demos.
• We are also caught up in the API differences between the MV4 (2.6.10), MV5 (2.6.18), and GIT (2.6.31.rc7) kernels ... what we are using in this case is the MV5 2.6.18 DVSDK release

The closest example I have to use as a starting point is the DM355 example  found in the dvsdk at ~/dvsdk_2_00_00_22/examples/dm6446/jpegdec>. 

I have replaced its local jpegdec invocation with the remote jpegdec codec server and rebuilt with package=dm6446.  It compiles without error, and appears to run, but the codec server returns a decoded value of zero, so something is not being setup or called correctly.

root@192.168.1.112:/test# ./jpegdec frida_720x480.jpg frida.yuv
@0x000ac13d:[T:0x4001df50] jpegdec - main> jpegdec
open engine:     decode
@0x00199e06:[T:0x4001df50] jpegdec - Processing buffer 222546 bytes...
@0x0019a011:[T:0x4001df50] jpegdec - image decoded: 0 x 0
@0x001a040d:[T:0x4001df50] jpegdec - app done.
root@192.168.1.112:/test#

I was wondering if there was a better "starting point" than this DM355 example, and if the calling API btween the jpeg decoders allowed what I am trying to do to work without modifying other than the codec invocation. I looked at and compared the DSP jpegdec input parameters ... they looked compatible at first blush to the ones that were setup by the DM355 code.

Tiger Team said:

• We are also caught up in the API differences between the MV4 (2.6.10), MV5 (2.6.18), and GIT (2.6.31.rc7) kernels ... what we are using in this case is the MV5 2.6.18 DVSDK release

MV5 is the correct version you should be working wtih.  The Montavista tools were upgraded from MV4 to MV5 between DVSDK 1.30 and DVSDK2.0 releases.  For now, I would stay away from using the GIT kernel as it is still being updated. 

Tiger Team said:

I have replaced its local jpegdec invocation with the remote jpegdec codec server and rebuilt with package=dm6446.  It compiles without error, and appears to run, but the codec server returns a decoded value of zero, so something is not being setup or called correctly.

Have you taken a look at the IUNIVERSAL example?  You don't actually need to create an IUNIVERSAL algorithm, but the two examples that come with it (random number generator and FIR filter) build for both ARM only and ARM+DSP devices.  Those examples can be downloaded here.  It may be helpful to examine the differences in building for ARM only and ARM+DSP devcies.  Specifically, the .cfg files in the "packages\ti\sdo\apps\fir\linux" directory.

Also, have you tried running your application with DEBUG on?  i.e. root@192.168.1.112:/test# CE_DEBUG=2 ./jpegdec frida_720x480.jpg frida.yuv 
That might provide some more insight into your problem.

sorry for the late response, I I do not get emails if something is updated .

Thanks for the Debug trick.  I will try it. We have put the jpeg decoder aside for a BRIEF (I hope) moment to get the basic video demo working on our target DM6446 board. Hopefully I will be back on this thread in a day or two.

I was looking for an example of how to actually setup the argument parmeters for the image jpegdec codec . I am assuming that it is just like the DM355 example, just built with a remote server.