Create Account
Search
You are here: TDG Forum  >>  Texas Instruments SOMs and Development Kits  >>  OMAP35x, DM3730, AM3703 Torpedo SOM Development Kit  >>  DSP JPEG Encoding

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 20 Feb 2015 03:58 PM by  Daniel Casner
DSP JPEG Encoding
 12 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Aaron
New Member
New Member
Posts:5


--
23 Jan 2015 09:38 AM

    I'm trying to use the DVSDK to do jpeg conversions.  The output of Ienc1_process(...) is always the same and mostly junk.  There are a couple jpeg flags in the data array (ie. the array starts with 0xFF 0xC4; this is a jpeg marker, but not the one for start of image), but mostly the data are junk (ie. end with a dozen 0x32s).  The resulting data can't be read by any image viewer.

    I'm using a dm3730 rev D torpedo and linux.  I've written my own C++ app that's just a slight re-factoring of the example app found in:
    dvsdk_4_03_00_06/dmai_2_20_00_15/packages/tio/sdo/dmai/apps/image_encode_io1.c

    I also found similar use of the API in:
    gst-ti-plugin-trunk919/gst-ti-plugin-minimal-trunk919/src/gsttiimgenc1.c

     

    My investigation so far:

    - I believe I'm linking all the DSP libraries correctly.  My app compiles and runs without errors.  There's a lot of mysterious black box Makefile steps that I just copied from the above examples, so I'm not 100% sure I'm doing that right.  Most significantly, all the configurations refer to using the omap3530 DSP target even though I'm on a dm3730.  According to both timesys and gstreamer examples, they have identical configurations for both.  So I'm guessing it's OK, but I'm not sure.

    - I know the DSP is doing something!  The first example shows how to time the process and run the DSP jpeg conversion with and without caching.  Time required to run the jpeg conversion always varies a little.  Without caching, it typically takes ~22ms.  With caching, about 11ms.  I'm not sure exactly what this caching is, but I think this at least demonstrates some sort of interaction with the DSP.

    - The uncompressed image used for Ienc1_process() doesn't matter.  I started with images from a camera.  But even with input frames of all 0x00, the output is always the same.

    - I have not yet confirmed that the DSP jpeg conversion even works.  I'll be trying to get a basic test working with gstreamer later today.

    - I thought that perhaps the output was getting truncated somehow.  I read past the end of the stated output length and it's all 0x00.  No end of frame marker in sight.

     

    Does anyone have any idea what's going on?  Am I using the API wrong?  Is the DSP codec compiled wrong?  Am I linking wrong somehow?  Is it buried in some errata somewhere that this actually doesn't work?

    I'm happy to provide the code here (it's not very different from the above examples), or the bizarre output, or my Makefile/.cfg/.bld files, or whatever info anyone wants if they've got any ideas.

     

    Thanks,

    Aaron

     

    PS.  Sorry if this post belongs in the linux BSP discussion section.  I'm having problems with the DSP and that's a bit of a gray area.
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    23 Jan 2015 02:12 PM
    In section 7 of our our Linux user guide (found here: http://support.logicpd.co...talid=0&EntryId=853) , we walk through both the downloading, compiling and installation of the DVSDK.

    Some of them exercise just the DSP, while others capture either still or video images from a camera and display them on the screen.

    In the instructions for setup, you'll need to change some of the u-boot arguments pertaining to memory, along with some other file and package changes. I would also check to see which version of the compiler you are using. For DVDSK files, you should be using the default 2009 compiler.

    Have you had any success with the example programs from our user guide?

    adam
    Aaron
    New Member
    New Member
    Posts:5


    --
    23 Jan 2015 03:40 PM

    I had trouble following your link ("A critical error has occurred.  Please check the Event Viewer for further details."), but if you're referring to DM37x Linux BSP User Guide: BSP Documentation (PN 1020203F) I've got a copy of that already.  I'm not sure if we're looking at the same document.  In mine, chapter 8 is about "Cameras and DSP (DVSDK)" and takes you through the steps of getting the DVSDK running.  To address some of your concerns:

    - I've downloaded and installed the very specific version of the code gen tools specified in the BSP User Guide.

    - I've just double checked that my uboot environment settings are correct.

    - The sample programs work beautifully.  This is news to me.  Turns out I'd been looking in the wrong place for them and expected the file names to be different.  The examples in section 8.3.1 of the User Guide were very helpful.

     

    Update on my app:

    After more investigating, it turns out that only all images after the first fail.  The first image looks recognizable (though very green; not nearly as good looking as the demo app).  After that, the images don't come through.

    Between the successful translations of my first frame and the demo apps as well as a fair bit of googling, I've learned more about JPEG encoding flags.  The "junk" I've been getting is just the "Define Huffman Table" section.  When my app tries to encode multiple frames I get:

    first frame - greenish, but an image

    second frame - Start of Frame Flag, Complete Huffman Table, ... nothing else

    third and later - just the Huffman Table

     

    This confirms:

    1. Clearly, there is nothing wrong with my hardware.

    2. It's possible, but less likely, that my program is linking in the DSP incorrectly.

    3. It's most likely the error is in software and that I'm not configuring or re-configuring my DMAI buffers or codecs engines correctly.  So far I've been using the html documentation in the DVSDK sub-directories.  My next step will be to find "Codec Engine Application Developer User's Guide (sprue67d)" listed under further reading in the DMAI html user guide.
    Aaron
    New Member
    New Member
    Posts:5


    --
    04 Feb 2015 03:32 PM
    I've gotten it all working in a basic sense at this point. Here's some notes I took along the way:

    - My "green-ish" color image was due to a typo in the input color space settings.
    - The BSP User Guide, sample application code, and testing the sample apps on hardware was very helpful.
    - Subsequent images were not junk so long as I re-initialized the encoder each time (buffers and dsp server are fine). I'm still not sure why this is necessary (the gstreamer code doesn't do this), but at least the basics are working now.

    Thanks for your help.
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    05 Feb 2015 06:51 AM
    I am glad it is working out for you.

    adam
    Aaron
    New Member
    New Member
    Posts:5


    --
    06 Feb 2015 03:41 PM
    As a follow-up, I've now gotten the TI gstreamer plugin compiling and running. It actually had the same problem as my test code. I patched my version of the gstreamer plugin to re-init the codec/encoder/"Ienc1_Object"/whatever-the-right-name-is with each new frame. It's strange that the gstreamer plugin needed a source code patch to work. This suggests there may be a little something wrong with my DVSDK build. Clearly, whatever's wrong isn't causing the build or run-time failures. So it couldn't be that bad right?

    Anyway, I'll cross my fingers and carry on like everything is fine. I just wanted to note the gstreamer plugin behavior for completeness.
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    07 Feb 2015 07:20 AM
    Are you using the 2009 compiler or the 2011 compiler? I know there are some issues with the DVSDK and the 2011 compiler.

    adam
    Daniel Casner
    New Member
    New Member
    Posts:7


    --
    19 Feb 2015 11:30 PM
    Aaron, thanks for your post, it sounds like you're hitting exactly the same problem as I am. Would you mind posting more specifically how you patched the codec plugin?

    I am looking at this thread http://e2e.ti.com/support...138400#pi239031349=1 on the problem but since the LogicPD BSP ltib virtual machine doesn't build the codec plugin from source (unless I am missing something) I haven't figured out how to patch my ltib build yet.
    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    20 Feb 2015 07:17 AM
    Daniel,

    The Linux User Guide does show instructions for building the DVSDK, but for licensing reasons, we cannot redistribute it, so you have to download it from TI, install it, then tell LTIB to include it. If you cannot find it, I can try to walk you through it.

    adam
    Aaron
    New Member
    New Member
    Posts:5


    --
    20 Feb 2015 11:06 AM
    Adam, sorry I didn't see your Feb. 07 question until now. I'll try to answer your and Daniel's questions.

    - I'm not actually using the ltib tool. I'm using the timesys factory so I'm in a slightly different situation than most people posting to the forum. I found that the gstreamer stack (I can't recall which plug-in failed) would not compile when using GCC 4.8.3. But it compiles just fine with GCC 4.7.3. I'll be trying out 4.9.0 soon. I'm not sure how the GCC versions match up to your 20xx compiler versions, but I'm seeing a similar chronological pattern.

    - Sorry Daniel, since I'm not in the same ltib situation, I can't really give you any straight forward recommendations for compiling. Based on the "DM37x Linux BSP User Guide" which Adam referred to, I would image you can download and cross-compile the source.

    - Great find Daniel! My patch is copied below, but it deletes and recreates the imgenc1->hIe. The posts you found show how to reset some dynamic parameters without the more significant clean-up and re-build. I will eventually try their implementation instead of my original fix.

    - My patch looks like this:
    --- gst-ti-plugin-minimal-trunk919.prepatch/src/gsttiimgenc1.c 2015-02-06 10:43:15.586295530 -0600
    +++ gst-ti-plugin-minimal-trunk919/src/gsttiimgenc1.c 2015-02-06 10:44:13.090912481 -0600
    @@ -1689,6 +1689,12 @@
    BufferGfx_setDimensions(imgenc1->hInBuf, &dim);
    BufferGfx_setColorSpace(imgenc1->hInBuf,
    imgenc1->dynParams.inputChromaFormat);
    +
    + Ienc1_delete(imgenc1->hIe);
    + imgenc1->hIe = NULL;
    + imgenc1->hIe = Ienc1_create(imgenc1->hEngine, (Char*)imgenc1->codecName,
    + &imgenc1->params, &imgenc1->dynParams);
    +

    /* Invoke the image encoder */
    GST_LOG("invoking the image encoder\n");
    Daniel Casner
    New Member
    New Member
    Posts:7


    --
    20 Feb 2015 02:01 PM
    Adam,

    Thank you for your reply. I have gone through the instructions in PN_1020203F_DM37x_Linux_BSP_UM.pdf and installed the C6000 tools and TICodeGenerationTools and built the DVSDK packages included with the Linux VM and they work except for the widely described jpeg encoder bug above. I can patch the DMAI code but I am new to LTIB and haven't been able to figure out how to patch the TI gstreamer codec plugin since LTIB is either installing it as a binary package unpacking / building the source somewhere other than rpm/BUILD which I am missing.

    Any tips on patching with LTIB would be appreciated as the LTIB documentation is minimal on opaque.

    Thank you,

    Daniel
    Daniel Casner
    New Member
    New Member
    Posts:7


    --
    20 Feb 2015 03:56 PM
    Adam, thanks again for your offer of help but I think I have figured out how to do it.

    For the moment, I am running 
     
     Manually patching the code in rpm/BUILD/ti-gstreamer-ti... per the link above then 
     [CODE]./ltib -p ti-gstreamer -m scbuild
./ltib -p ti-gstreamer -m scdeploy


    I'm sure there's a way to tell LTIB to apply the patch directly but this is enough to start.
    Daniel Casner
    New Member
    New Member
    Posts:7


    --
    20 Feb 2015 03:58 PM
    I'm not sure what wen't wrong with my last post but here it is again sans formatting
    For the moment, I am running

    ./ltib -p ti-gstreamer -m prep

    Manually patching the code in rpm/BUILD/ti-gstreamer-ti... per the link above then

    ./ltib -p ti-gstreamer -m scbuild
    ./ltib -p ti-gstreamer -m scdeploy


    I'm sure there's a way to tell LTIB to apply the patch directly but this is enough to start.
    You are not authorized to post a reply.

    Forums Texas Instruments SOMs and Development Kits OMAP35x, DM3730, AM3703 Torpedo SOM Development Kit