Is there a JPEG example for DM6446 ?

I also have a similar question,  where is a jpeg decoder demo/example for the dm6446 EVM (MV5) ?

http://e2e.ti.com/forums/t/9929.aspx

Having one available would help tremendously.

Unfortunately, JPEG codecs were not included by default in the DM6446 DVSDK software deliverable and hence made it difficult to include sample application for a codec that was not readily available in the DVSDK.  In the DM355, MJCP hardware supports JPEG by default so it was very easy to include a sample JPEG application.

For DM6446 case, the challenge is getting or building a codec engine server which includes JPEG codec(s) already.  Therefore you have two options

1) There is a motion JPEG app note which includes pre-built codec engine server along with application code available at http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraah9a

2) You can request a free trial of JPEG codec(s), which is likely how Jack got access to the link he posted above.  Once you have the codec libraries, you can incorporated into your own proprietary codec engine server (there is a wiki article that outlines the steps).  This approach is a bit more tedious but gives you more flexibility in you need to include other codec(s) aside from JPEG into a single server.

Juan, I do have the jpegdec codecs and have attempted to build with them. ( I successfully added the mpeg3 codecs to the demo, so I have a rudimentary grasp of how to do it).  But the jpegdec is an image decoder and not audio or video and I have no example of an arm-side jpeg calling program. I halfway expected to see on in the DM357 collateral, but did not.

I did see the jpeg motion example referenced above last week, and also found a CCS-based jpeg test app buried down in the codec path (~/dvsdk_2_00_00_22/dm6446_dvsdk_combos_2_05/packages/ti/sdo/codecs/jpegdec/app/ ), but instead decided to first try an example of what looked closer to what I was needing ...

Last year, we built an entire jpeg application in a day on the DM355, using its example as a starting point. I am looking for something similar as a baseline to make sure we have a good starting point.

Question) Should I be able to take the DM355 example  (~/dvsdk_2_00_00_22/examples/dm355/jpegdec), retarget for the dm6446 platform and the remote dsp jpegdec codec, and expect it to produce correct results?

I can build both this jpegdec demo, the remote jpegdec dsp codec, and the remote decode server without any compiler error. It opens the remote codec, but it does not result with the expected output. 

root@192.168.1.108:/test# ./jpegdec frida_720x480.jpg frida.yuv                     
@0x00025f8c:[T:0x4001df50] jpegdec - main> jpegdec
open engine:     decode
@0x00115f05:[T:0x4001df50] jpegdec - Processing buffer 222546 bytes...
@0x00116122:[T:0x4001df50] jpegdec - image decoded: 0 x 0   <------------------------------------------------
@0x0011c3e9:[T:0x4001df50] jpegdec - app done.
root@192.168.1.108:/test#

root@192.168.1.108:/test#  ./jpegdec frida_720x480.jpg /dev/fb/3                 (tried outputting to the framebuffer for grins. No difference)
@0x0007b93c:[T:0x4001df50] jpegdec - main> jpegdec
open engine:     decode
@0x000f26a2:[T:0x4001df50] jpegdec - Processing buffer 222546 bytes...
@0x000f28af:[T:0x4001df50] jpegdec - image decoded: 0 x 0     <------------------------------------------------
@0x000f88b6:[T:0x4001df50] jpegdec - app done.
root@192.168.1.108:/test#

The dm355 example seems pretty straight forward. I have compared the DM355 jpegdec and DM6446 remote codec arguments and the appear the same to me. Either they are not, or I have built the remote codec incorrect.

Questions: 

1. Should this work?
2. Has anyone in this community retargetted this DM355 example to the DM6446 successfully?
3. I have three variables: (the ARM app, the 355-vs-6446 jpegdec interface, or the dsp codec/server)  What would be the first step to debug?

Thanks, Gary

Hi Gary,

I believe there are two primary image interfaces IMGDEC1 and IMGDEC; between our platforms, IMGDEC1 interfaces should be compatible with other IMGDEC1 interfaces, compatible meaning they will likely build.  The codecs underneath may also indeed be 100% compatible from an interface perspective, but to tell for sure you should refer to the corresponding JPEG Decoder User Guide and data-sheets; these docs whould be included with the codecs (whether you requested them separately or got them as part of DVSDK).  These docs are the authority when it comes to codec capability and are specific to a particular codec version, hence it helps avoid overgeneralizations.

To answers your questions

1) Should this work? Most likely, but refer to the codec data-sheet to make sure codec supports the feature set you are trying to use.  Underneath the interfaces, codecs will be very different since one is built for 64x+ DSP core and the other for dedicated MJCP hardware on DM355, so they may support slightly different sets of features.

2) Not to my knowledge. 

3) You have a known working DM6446 JPEG codec server in Motion JPEG App Note, I would try using it with DM355 jpeg demo at first (eliminate the unkown dsp/server variable).  I have not familiar enough with DMAI yet, but they may have an app for easily prototyping image related apps on DM6446 (option to using DM355 app).