• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 293 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.

DM355 + multi instance mpeg4 encoder

Gerardo Artola Pola
Prodigy 60 points

Hi all:

I'm trying two implement an application with two instances of a mpeg4 encoder. I can't find any examples or documentation about this. For example, I would like to have a configuration example (.cfg file), etc.

Can someone give me some advice on this?

Thanks

Best Regards.

Gerardo

  • 0
    TI__Mastermind 37340 points

    I do not believe cfg file would change at all for s single instance vs multiple instance case.  What would change is you application which calls on VISA APIs to create the instance of the codecs (e.g. VIDENC_create function).  Our DVSDK provides demos (encode, decode, encodedecode) which use these APIs to crate codec instances; each XXXX_create call (where XXXX is part of VISA APIs) creates one instance.

  • 0 in reply to Juan Gonzales
    Prodigy 60 points

    thanks for your reply.

    I'm not only asking about cfg file. I mean, my interest is in the the whole configuration of the system. I understand that multiple codec instances affect the CMEM configuration, and maybe more components, and the examples you mentioned don't cover this case.

    Sorry if I'm asking trivial things but I'm now in an early development phase. Of course it would be great if I get some examples, but when not posible, some info would be enough. If you said that it's enough to work with VISA APIs I will follow that advice.

  • 0 in reply to Gerardo Artola Pola
    TI__Mastermind 37340 points

    Well, you are correct that you need to take into account system resources.  For example, if you run out of memory, you may not be able to allocate one more instance of the codec.  On our DM355 EVM, 116M is assigned to Linux OS (via bootrags), 12M to CMEM (for passing contigous buffers between ARM and MJCP) and the other 128MB to MJCP.  In a similar fashion, DMA channels are partition between the ARM and MJCP. 

    On the Linux OS side, you need to have enough memory to accomodate all the video buffers you will need; you decide if you need single buffered video, or double buffered, or tripple buffered.  You also decide how many windows you have enabled at any one time (DM355 has 2 video windows and 2 OSD windows).  You also decide how many buffers you need to keep on the Linux OS side vs how many you need to pass via CMEM space to MJCP fro compression/decompression. 

    On the MJCP side, the nice thing is that the software architecture does allow sharing of DMA and memory resources among codecs in the same scratch group.  Hence, each new codec instance of the same type should only take a little more memory; therefore you will unlikely run out of memory here, though it is a possibility.

    In conclusion, every customer's system will be a bit different based on the choices each makes, but hopefully this brief overview will give you  a top level overview and the ability to ask more detailed questions as you move forward. 

  • 0 in reply to Juan Gonzales
    Prodigy 60 points

    Thanks for your reply. I can run at the moment two instances of the same codec.

    I experimented some problems integrating the two, but apparently it wasn't  the general configuration. I realized the problem was while generating mpeg4 headers with the corresponding call provided by the codec. Now I'm "manually" adding this headers in the stream and the application runs smooth :)