C64+ JPEG encoder

Hi Andreas,

JPEG codecs in ELF format are available for C6678 @ http://software-dl.ti.com/dsps/dsps_public_sw/codecs/C6678_Video_Codecs/01_00_001/index_FDS.html. Can you please check if those work for you?

Thanks,

Hongmei

Hi Hongmei,

thanks for the prompt response. I won't be able to test this until next week unfortunately due to some other priorities but I'll keep you posted.

I did download the package and confirmed it was an ELF library so we're off to a good start at least.

Thanks,

Andreas

Hi Andreas, 

     I'm going to start the same task in the DM8168, I have read a lot of posts where some people says that is not possible to port the JPEG encoder, however I will try it. I just wanted to ask you If you got some good result doing this and if that is the case any help about how to do it is really appreciated, maybe some useful links that you could have found or some kind of guide could be pretty useful for me!

Thanks in advance Andreas,

-David

Hi David,

I had to abandon my efforts due to shifting priorities but I'm getting to the point of picking it up again. I never really made any progress with the C66 version as that was the only ELF based at that moment but according to some TI sources, that is our best bet. 

Would love to collaborate and see how close we can get.

-Andreas

Hi Andreas,

    I understand. I started trying to make the codec compile with the EZSDK and currently I'm trying to solve some build issues. I am using this guide as first step: 

http://processors.wiki.ti.com/index.php/MP3_Decoder_Integration_in_EZSDK

   Since some months ago I was able to integrate the mp3 codec, the thing is that in that guide, we are adding the codec to the audioenc component of openMax, so basically what I'm trying to do is to use the vlpb component instead of the aenc since this a generic component which takes an input buffers and copies it to an output buffer in the DSP, this is in the DSP side. About the arm side, I included the codec in the encode demo instead of the adec_snt demo.

 So from my point of view this should be the plan (and let me know if it makes sense):

1. Port the codec and solve any build errors
2. Try to use some functions of the codec from the vlpb component to see if it works, if so...
3. Create an omx component for the JPEG encoder using the vlpb as reference (component-sources/omx_XX_XX_XX_XX/src/ti/omx/comp/vlpb)

4. Finally we would be able to use the openMax API to get access to the component from some application

Comments? Does TI has some recommendation? or maybe you have this already done?

-David

Hi David,

the MP3 decoder is a great starting point. I did the same thing and created a jpegenc component for OMX, except I derived it from the audio encode component.

The problem is the codec library itself as it comes in the wrong format so the linker will fail. I tried it with the C66 version and it gets me further but I still end up with link errors  that are internal to the linker.

My current plan of attack is similar to yours. Port pieces of my software JPEG encoder to run on the DSP using IMGLib. Vlpb is a great reference point. I don't necessarily need to run it as an OMX component as long as it can be used from within OMX.

Any TI comments would be really helpful at this point. The quickest for everyone would be if someone on the inside (with access to the JPEG DSP source code) could just recompile it. I'd be happy to test it.

-Andreas

Hi Andreas, 

Some questions:

Andreas Engberg76462 said:

I did the same thing and created a jpegenc component for OMX

Could you share the component? at least I would save time on that and be focused solving the linker errors.

Andreas Engberg76462 said:

Port pieces of my software JPEG encoder to run on the DSP using IMGLib.

I didn't know about IMGLib, so it is a C library and you are thinking about replacing some functions to perform them in a optimized way in the DSP? That would be like create the codec again right?

I agree with you, can someone from TI could help on this?

Thanks Andreas! I will keep you informed about any progress on this!

-David

David,

I can absolutely share the component with you. Contact me via email (andreas.engberg at arthrex dot com) as I just need to know a few things about you and the company you work for.

IMGLib is a DSP library with a number of image functions. It's capable of doing most of the work that a JPEG encoder needs but I'd rather use a TI defined codec. But you are correct, in essence writing a new codec.

-Andreas

Hi Andreas and David,

Can you please move this discussion to DM814x/816x forum: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/default.aspx?

IVAHD decoder (1.0.4.0) is already part of EZSDK (5.4.0.11), even including OMX component. DM81xx team can provide IVAHD JPEG encoder (it exists) as well, and you may be able to modify JPEG dec OMX component to create JPEG enc OMX component.

Thanks,

Hongmei

hello http://software-dl.ti.com/dsps/dsps_public_sw/codecs/C6678_Video_Codecs/01_00_001/index_FDS.html

This JPEG codec is compatible with DM8148?   I can't find JPEG codec for DM8148。please help me。

Dear Hongmei.

Can you send me DSP Jpeg encode codec in ELF format for DM8127?

C66 Elf library you suggested can be built into DSP application but   it can't be working with DM8127.

because  C66 Elf is not compatible with C674x .  

IAs below , the previous version of  C64+ jpeg encode codec  is recognized as COFF library format with DM8127 in CCS v5 . 

==============

fatal error #16031: object files have incompatible formats ("C:\Users\jhpark\workspace_v5_5\testC64X\lib\jpegenc_ti_plink.o64P" = TI-COFF, "C:\Users\jhpark\workspace_v5_5\testC64X\Debug\configPkg\package\cfg\app_pe64P.oe64P" = ELF).  Please see the 'C6000 EABI Migration' guide at http://processors.wiki.ti.com/index.php/C6000_EABI_Migration

=======

Can you help me ? 

Best Regards. 

Hi,

  Just in case we got the JPEG codec working on IVA:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/218538/983344.aspx#983344

-David