• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 724 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Howto run CodecEngine examples *with* HDV* firmware running?

Joern
Genius 3055 points

Starting from CodecEngine example universal_copy it's not too difficult to get some first lines of code running on DSP, controlled by code at ARM side. At least (concerning DM8148 and EZSDK 5.03.01.15) if you've found these hints:

BUT now the first of these two points drives me into a conflict: I can't no longer call "/etc/init.d/load-hd-firmware.sh stop" to get my CodecEngine-based application+codec running, because I want to run a OMX-based H.264 encoding at the same time, which needs HDV*...

I hope and assume that this conflict could be solved by some changes concerning concurrent memory map settings? Or maybe some issues concerning syslink use? Is there any concrete hint to be found concerning at least the direction of the solution?

Thanks in advance,
Joern.

  • 0
    Genius 4120 points

    Hi Joern,

    You can connect the DSP as an OMX component.
    Take a look here: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/144078.aspx#520139

    Gabi 

  • 0 in reply to Gabi Gvili
    Genius 3055 points

    Hi Gabi,

    thanks for your hint, I'll work that through - but it seems for me like a deeper change of strategy. What I actually need is to be able to combine

    1. the OMX H.264 encoder component (which afaik at DM8148 not anymore uses the DSP, but only ARM and video accelerator), and
    2. to combine that with an application which makes use of a DSP-side codec, by use of the Codec Engine/Codec Server.

    If such a combination would be not possible without deeper changes to the code either of the Codec Engine mechanism or the OMX component (resp. implementation of the OMX IL) then this would be a big disappointment for me. It would make Codec Engine mechanism worthless for me.

    I use Codec Engine because of the possibility of a future need to combine own DSP-side software with a third-party codec, f.e. that might concern audio. Thatswhy I decided to use the Codec Engine mechanism, thatswhy I started the stony, all but well-prepared way to combine an existing, huge, makefile based C++ project (ARM side) via a C-API to a Codec Engine based interface to an IUNIVERSAL codec, which itself is a skeleton to call functions of an C API of a separately built C++ based, partially already existing library for DSP side... phew.

    I hope, that it will be possible to combine Codec Engine based applications and OMX based applications (as far as not making use of DSP) just by adapting some small details of memory mapping, syslink use, maybe adapting some macros within the implementations of OMX IL and Codec Engine / Codec Server...

    Best regards,
    Joern.

  • 0 in reply to Joern
    Genius 4120 points

    similar to adding A8 component described here

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/155547.aspx#563607

    you can create an OMX thread on A8 in the ilclient that will call codec-engine, you will need to connect it at the OMX chain you are planning and take care of interfacing with other OMX components i.e, take care of emptyThisbuffer/fillThisbuffer.

    Gabi 

  • 0 in reply to Joern
    TI__Genius 17205 points

    Unfortunately, I don't have time to work up the details to get this to work in the EZSDK environment.  But using Codec Engine (over SysLink) to talk to the DSP while also using OMX (over SysLink) is certainly supported.

    If it's not working (failure at runtime?  Or build time?), it's most likely a memory map and/or system config issue.  The memory map for CE example servers can be found in examples/ti/sdo/ce/examples/servers/all_codecs/* - look in serverplatforms.xs for sections specific to your platform (DM8148).

    In addition to the memory map, the system-wide config must match - specifically IPC-related things like "Shared Regions".  I think the EZSDK memory map is described here - http://processors.wiki.ti.com/index.php/EZSDK_Memory_Map - though it's difficult to know which of those memory chunks are "Shared Regions".

    I hope you can make progress from these loose details, and if you have questions about the memory map and/or config, feel free to post again here.

    Chris

  • 0 in reply to Chris Ring
    Genius 3055 points

    Sorry for answering so late, I was too busy for the moment with other stuff to follow your hints.

    First your answer spent a glimmer of hope to me - it is always the main thing to know THAT something is solveable by a roughly outlined way, the way details are somewhat secondary then. And your suggestions fit my own, hopeful assumptions.

    All I saw until now is that without  "/etc/init.d/load-hd-firmware.sh stop" (as last not least demanded here for running codec engine examples, but on the other hand needed to run the OMX based H.264 encoder) my codec engine based application just frozes, and also the debug level of syslink does not deliver more hints. The very next step of course will have to be for me to analyse what load-hd-firmware.sh actually loads or sets, an then follow your hints.

    The reason that above there is no comma after 'first' is, that that my glimmer of hope was somewhat deadened by some other information, which yet I couldn't bring together with your statement. In your statement it sounds so easy that using codec engine over syslink while using OMX components over syslink should be possible. On the other hand I found some information (as I posted here in the meantime) which let me fear that the OMX components which control the H.264 encoding process (by use of HDVICP and/or HDVPSS) might run not on arm, but only on all other processors, and so I became afraid that the encoding would be at least controlled by an OMX component running on DSP, but where I need to have running a codec server instead...

    Now, within the mentioned thread I've got an answer by RV, which makes me being hopefully again, that the H.264 encoding OMX components will not run at the DSP but only at the video and compression CPUs and may be controlled from ARM side.

    So also the glimmer of hope is back which you made for me.

    It would be great if one of the involved TI employees might spend some time to this - as I mean - very typical use case of your platform. Of course, as soon as I have found some solution pieces I'll post them here...

    Best regards,
    Joern.