• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 732 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.

dm8168 encoder demo cannot work after it has interrupted with Ctrl + C

llano4
Prodigy 230 points


HI,

The sdk version is 5_04_00_11.

When runs encoder demo, let's say

./encode_a8host_debug.xv5T -i 720p.yuv -o test2-264.264 -f 50 -b 15000000 -w 1280 -h 720 -c h264

everything is find then. But as long as it is interrupted with Ctrl C, then:

root@dm816x-evm:/# ./encode_a8host_debug.xv5T -i 720p.yuv -o test2-264.264 -f 50
 -b 15000000 -w 1280 -h 720 -c h264
output file: test2-264.264
input file: 720p.yuv
bit_rate: 15000000
frame_rate: 50
codec: h264
width: 1280
height: 720
 Encode example
=Assertion at Line no: 419 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none-linux-gnuea
bi/ti-syslink-2_10_03_20-r4j/syslink_2_10_03_20/packages/ti/syslink/utils/hlos/knl/Linux/../
../../../../../ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c: (cargs.args.create.handle != NUL
L) : failed
================Assertion at Line no: 419 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-n
one-linux-gnueabi/ti-syslink-2_10_03_20-r4j/syslink_2_10_03_20/packages/ti/syslink/utils/hlo
s/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c: (cargs.args.creat
e.handle != NULL) : failed
==============
Assertion at Line no: 419 in /swcoe/sdk/cm/netra/arago-tmp/work/dm816x-evm-none-linux-gnueab
i/ti-syslink-2_10_03_20-r4j/syslink_2_10_03_20/packages/ti/syslink/utils/hlos/knl/Linux/../.
./../../../../ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c: (cargs.args.create.handle != NULL
) : failed
Assertion at Line no: 1244 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysl
ink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed
Assertion at Line no: 700 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysli
nk_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSA
GEQ) : failed
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysl
ink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed
Assertion at Line no: 700 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysli
nk_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSA
GEQ) : failed
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysl
ink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed
Assertion at Line no: 700 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysli
nk_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSA
GEQ) : failed
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysl
ink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed
Assertion at Line no: 700 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysli
nk_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSA
GEQ) : failed
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysl
ink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed
Assertion at Line no: 700 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysli
nk_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (queueId != MessageQ_INVALIDMESSA
GEQ) : failed
ServiceMgr_prime: MessageQ_put failed: status = 0xfffffffe
Assertion at Line no: 1244 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysl
ink_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed
Assertion at Line no: 766 in /home/hv/ti-ezsdk_dm816x-evm_5_04_00_11/component-sources/sysli
nk_2_10_03_20/packages/ti/syslink/ipc/hlos/usr/MessageQ.c: (handle != NULL) : failed
Segmentation fault

only reboot the board can make it work again.

 

Llano

  • 0
    TI__Genius 11470 points

    Hello, llano4

    Yes, this is know. You can't use use Ctrl+C to stop the demos, it is not implemented and I don't know why the developers did it this way. You have to either wait the demos to finish or use there exit, cancel, etc. buttons.

    BR

    Vladimir

  • 0 in reply to Vladimir-XID
    Intellectual 745 points

    If I have an application that is terminated via a different process what are the clean up procedures to solve the problem?   The demo could be my application that is killed by the kernel via oop or because I have a a process that will start or shutdown my application.

    Thanks,

    Craig

  • 0 in reply to Craig Matsuura85376
    Expert 1305 points

    Hi Craig,

    I have also found that TI's OMX does not deal well with abnormal process termination.  I am using EZSDK 5.03, so some/all of these driver bugs could be fixed in future releases, I don't know if that is the case or not.  Unfortunately, if my OMX-using process crashes or is terminated with OMX running, then odds are OMX will not be usable without a reset of the SOC.  Here are some options I have come up with for dealing with the problem so far:

    1) Minimize what needs to occur in the OMX-using process.  This makes it easier to eliminate any/all 'accidental' crashes of this process.

    2) install a signal handler to handle signals like TERM, etc.. which may be used to terminate the process via another process.  This signal handler should initiate a 'clean' shutdown of OMX, and then exit.

    3) Avoid sending unhandle-able signals to OMX process (KILL vs KILL -9)

    4) adjust /proc/PID/oom_score_adj to -1000 to make yourself invincible to OOM killer


    Of course these are all work-arounds with significant drawbacks.  But I mention them here in case it helps.  Please let me know if you find a more robust way.

    Thanks,

    Joel

     

  • 0 in reply to Joel Keller
    TI__Genius 11470 points

    Hi Joel,

    Thank you very much for these suggestions.

    BR

    Vladimir

  • 0 in reply to Joel Keller
    Intellectual 745 points

    Hi Joel,

    Thanks for the ideas.  I have consider some of these workarounds.  I would like to consider option #2 but I am not sure what the proper clean up proceed for OMX.  Our UI application is using OMX and we do set the oom higher.

    Thanks,

    Craig

  • 0 in reply to Craig Matsuura85376
    Expert 1305 points

    Hi Craig,

    For my application, I clean up OMX by using OMX_SendCommand (with OMX_CommandStateSet) to transition from the OMX_StateExecuting to OMX_StateIdle and then again to OMX_StateLoaded.  Then I free the OMX handle(s) that I have via OMX_FreeHandle,  deallocate buffers, and then call OMX_Deinit().

    This occurs during "regular shutdown" as well as when a signal is caught.  Specifically, when a signal is caught, the signal handler notifies the application's thread that this shutdown sequence should occur (via a write to a pipe actually). 

    Hope this helps,

    Joel

  • 0 in reply to Joel Keller
    Intellectual 745 points

    Hi Joel,

    Sorry for the delayed reply.  I have wonder if you know if the calles to OMX_FreeHandle, OMX_DeInit() or any of the init or deinit routines on OMX are thread safe?  I have appeared to solve some of my issues by using mutex.  I'm using the gst-openmax plugins and the elements make calls OMX.

    Do you know if it is important to transition state to OMX_StateLoaded before freeing the OMX_FreeHandle?

    Thanks,

    Craig

  • 0 in reply to Craig Matsuura85376
    TI__Guru* 80190 points

    Hello,

    For terminating the application, OMX component state machines are changed to loaded state before deleting the component, so that all buffers are freed up. SendCommand needs to be sequentially done for all components, ie, one component at a time.

    Tear down sequence:

    Change state to Idle->Change state to Loaded->Free the buffers->Delete component->DeInit.

    Best Regards,

    Margarita



  • 0 in reply to Craig Matsuura85376
    Intellectual 745 points

    Hello,

    I have been working with our FAE at TI and have discovered that the init/deinit in openmax is NOT thread safe.  We have been working with the FAE and Gil (found on the forum) to resolve this issue.

    Craig