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

VIDENC1_create hang in the second call (CE 2.23.01)

hao qin37141
Prodigy 50 points

hi!

I am working with dvsdk 2.00.00.22.  I created a codec server on DM6446 with three codecs in it - an H264 encoder, an AAC encoder and an AAC decoder.  what i want is to run aac codec and h264 encoder independently and concurrently. There are 3 threads (Capture+VidEnc+Writer) for H264 task and 2 threads(aacenc+aacdec) for AAC task. I called CERuntime_init prior to the first thread running and CERuntime_exit after the last thread exits.

Test results shows that:

1) starting 2 tasks followed by stopping the 2 tasks can works well.

2) starting 2 tasks followed by restarting AAC task several times, can works well.

2) starting 2 tasks followed by restarting H264 task, VIDENC1_create hang. when CE_DEBUG=1/2/3 option is used, it works well. If I called CERumtime_init for each H264 task, it works well.

similar problem can be found in the post  http://e2e.ti.com/support/embedded/f/356/p/88287/309723.aspx where Vincent mentioned this issue  is likely to be timing related. I have already checked our codes again and again and found nothing.

My question is at what condition VIDENC1_create will hang, how to debug the issue. or any further suggestion

thanks very much and sorry for my english

  • 0
    TI__Expert 7415 points

    You could try and enable trace in Framework Components, which is probably engaged during creation of the codecs. This of course may affect the timing, but we can study the trace to see if there are any warning/error notifications. 

    Please check this link to figure out how to enable trace for your version of FC:-   http://processors.wiki.ti.com/index.php/Trace_in_Framework_Components

  • 0 in reply to Gunjan
    Prodigy 50 points

    hi, Gunjan, sorry for my late reply.  According to your suggestion, I think I have found the bug. Our H.264 video encoder makes use of the VICP to optimize the speed, but DSKT2_freeAlg did not call the IALGFxn::algFree of my video codec, which should be called to free VICP resources. Thus making the second call to VIDENC1_create hangs. Here are my new questions.

    According to SPRUE67D (Codec Engine Application Developer User's Guide), the first call to Engine_open powers on the DSP, and the last call to Engine_close will power off the DSP. Each time the DSP is powered on, the main function of the codec server should be called. In my implementation, VICP is initialized in main function. Surprisingly, the second call to my main function (caused by the second call to VIDENC1_create) fails to initialize the VICP. So, can I tell that the VICP are not managed by the CE? The last call to Engine_close will not power off VICP? If it is true, how can I get notified when the DSP will be power off so that I can reset the VICP?

    The second question: DSKT2_freeAlg will not call algFree function of a codec, what should I do to get notified when VIDENC1_delete is called so that I can free resources occupied by the VICP?

    As indicated in IALG rules, to ensure the interoperability of eXpressDSP-compliant algorithms, it is important that algorithms never directly access any peripheral device. My third question is what is the proper occasion or location to initialize and finalize the VICP?

    thanks very much!!

  • 0 in reply to hao qin37141
    TI__Expert 7415 points

    Regarding the second part of your question. Yes, DSKT2 indeed does not call algFree for the codec. The algFree interface is basically to query the algorithm about it's memory usage, so that it can be freed. Since DSKT2 stores this information internally, it never needs to call this interface. I don't think your codec can rely on algFree as the proper place to initialize/de-initialize it's VICP resources.

    Could you tell me what version of framework components is being used by that version of DVSDK ?

    There is a separate interface that is used to request/manage resources among codecs called IRES interface. It also has support for VICP resources, and would provide maybe a better place for initializing and deinitializing the VICP resources.

    See this:- http://processors.wiki.ti.com/index.php/Framework_Components_RMAN_Users_Guide#IRES_and_RMAN_Modules

    This section provides details on how the HDVICP resource is handled, there is similar resource management for the VICP resource:-

    http://processors.wiki.ti.com/index.php/Framework_Components_RMAN_Users_Guide#HDVICP_Hardware_Accelarator_Concrete_Resource_Interface

  • 0 in reply to Gunjan
    Prodigy 50 points

    The version of FC is 2.23.01. 

    Thanks again for the answers, and I will work on it.