• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 1132 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.

OMAP4 Android Blaze Tablet:: No Response from TI OMX libraries when OMX_EmptyThisBuffer and OMX_FillThisBuffer is called

Pradeep Acharya
Intellectual 930 points

Hi

         I'm developing a video phone on Android blaze tablet which uses omap4430 chip.The s/w version is 4.AI.4 and kernel version is 3.0.21  After the  Decoder component enters into OMX_StateExecuting,

I'm calling OMX_EmptyThisBuffer with valid i/p data. The function succeeds and then i call the OMX_FillThisBuffer. I get the  OMX_EventPortSettingsChanged indication from the open max layer but the EmptyBufferDone and the FillBufferDone call backs are not called. No errors reported from the TI open max layer

Ignoring the empty buffer done and fill buffer done callbacks, if i submit the next frame to the omx layer, the applications hungs after submitting 4 buffers to the decoder component. After tracing through the omx code provided in the 4.04 android source,  came to know that the RPCCallback thread is not receiving any response from the remote core. This remote core could be the DUCATI.

I've verified the i/p given to the decoder using vlc player and the i/p is fine. Even if the i/p frame to decoder is erroneous, the omx component should return error. This does not happen and the application hungs. I don't know the reason for this.

But from my observation. OMX_EventPortSettingsChanged indication is given by the TI omx layer for the o/p port which means that the decoder might have decoded the frame I'm saying this because the OMX_EventPortSettingsChanged indication is NOT received if i DO NOT call the OMX_FILLThisBuffer function i,,e the event is not received if i do not call the fill buffer function. This probably means that the OMX_EventPortSettingsChanged event is sent ONLY after decoding the first frame i,,e I-frame.

How to debug the issue. Do any one have ideas on this. What are the reasons for TI omx layer not responding to the frames submitted. What are the conditions in which the i/p frame is discarded and NOT returning any error ?? Please do not suggest to execute the demo and check it first. i've to debug as per my current situation.

The following are the logs

===== submitting 1st frame which is an I-frame ========

/VideoPhone( 4575):  [1345530431-DEBG :934] Calling DECODER with ptr: 5f000000 length: 1316 at tv.tv_sec: 1345530431 tv.tv_usec: 894893
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:121    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:202    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:471    PROXY_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER: hComponent=0x3a4410, pCompPrv=0x67ec58, nFilledLen=1316, nOffset=0, nFlags=00000000
D/DOMX    ( 4575): TRACE: Buffer Index of Match 0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1251    RPC_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:  pBufferHdr = 411a68 BufHdrRemote 85a211e8
D/DOMX    ( 4575): TRACE: Recd. omx message
D/DOMX    ( 4575): TRACE: Waiting for messages from remote core
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1323    RPC_EmptyThisBuffer()    
D/DOMX    ( 4575): EXIT:
D/DOMX    ( 4575): TRACE: Corresponding RPC function executed successfully
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:547    PROXY_EmptyThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
I/VideoPhone( 4575):
I/VideoPhone( 4575):  [1345530431-DEBG :945] Calling  OMX_FillThisBuffer with ptr: 5f200000 at tv.tv_sec: 1345530431 tv.tv_usec: 894893
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:581    PROXY_FillThisBuffer()    
D/DOMX    ( 4575): ENTER: hComponent = 0x3a4410, pCompPrv = 0x67ec58, nFilledLen = 0, nOffset = 0, nFlags = 00000000
D/DOMX    ( 4575): TRACE: Buffer Index of Match 2
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1357    RPC_FillThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:  pBufferHdr = 514840 BufHdrRemote 85a21d30
D/DOMX    ( 4575): TRACE: Recd. omx message
D/DOMX    ( 4575): TRACE: Waiting for messages from remote core
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1402    RPC_FillThisBuffer()    
D/DOMX    ( 4575): EXIT:
D/DOMX    ( 4575): TRACE: Corresponding RPC function executed successfully
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:602    PROXY_FillThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec.c:708    PROXY_VIDDEC_FillThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): TRACE: Recd. omx message
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_skel.c:212    RPC_SKEL_EventHandler()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:
D/DOMX    ( 4575): **__**Got eventhandler from Remote Core succesffuly - values are : **__**
D/DOMX    ( 4575): TRACE: hComp :0x3a4410,eEvent: 0x3,nData1: 0x1,nData2: 0x0,pEventData: 0x0
D/DOMX    ( 4575): TRACE: Just Before Entering Proxy Event handler call
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec.c:554    PROXY_VIDDEC_EventHandler()    
D/DOMX    ( 4575): ENTER: hComponent=0x3a4410, pCompPrv=0x67ec58, eEvent=0x3, nData1=0x1, nData2=0x0, pEventData=0x0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:233    PROXY_EventHandler()    
D/DOMX    ( 4575): ENTER: hComponent=0x3a4410, pCompPrv=0x67ec58, eEvent=0x3, nData1=0x1, nData2=0x0, pEventData=0x0
I/VideoPhone( 4575):
I/VideoPhone( 4575):  [1345530431-DEBG :498] Entered OmxDecEvtHandler () with Comp_Handle: 3a4410 event: 3 nData1: 1 nData2: 0
I/VideoPhone( 4575):
I/VideoPhone( 4575):  [1345530431-DEBG :533] OmxDecEvtHandler () Rcvd OMX_EventPortSettingsChanged pAppData: 5c65750c nData1: 1 nData2: 0 pEventData: 0
I/VideoPhone( 4575):
I/VideoPhone( 4575):  [1345530431-DEBG :463] SIGNAL_COMMAND_COMPLETION() value of condition: -4  i32CurrVal: 1
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:293    PROXY_EventHandler()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_skel.c:236    RPC_SKEL_EventHandler()    
D/DOMX    ( 4575): EXIT:
D/DOMX    ( 4575): TRACE: Waiting for messages from remote core
I/VideoPhone( 4575):

===== submitting 2nd frame ========


I/VideoPhone( 4575):  [1345530431-DEBG :934] Calling DECODER with ptr: 5f100000 length: 7352 at tv.tv_sec: 1345530431 tv.tv_usec: 907344
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:121    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:202    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:471    PROXY_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER: hComponent=0x3a4410, pCompPrv=0x67ec58, nFilledLen=7352, nOffset=0, nFlags=00000000
D/DOMX    ( 4575): TRACE: Buffer Index of Match 1
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1251    RPC_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:  pBufferHdr = 411ac0 BufHdrRemote 85a21238
D/DOMX    ( 4575): TRACE: Recd. omx message
D/DOMX    ( 4575): TRACE: Waiting for messages from remote core
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1323    RPC_EmptyThisBuffer()    
D/DOMX    ( 4575): EXIT:
D/DOMX    ( 4575): TRACE: Corresponding RPC function executed successfully
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:547    PROXY_EmptyThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
I/VideoPhone( 4575):
I/VideoPhone( 4575):  [1345530431-DEBG :945] Calling  OMX_FillThisBuffer with ptr: 5f380000 at tv.tv_sec: 1345530431 tv.tv_usec: 907344
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:581    PROXY_FillThisBuffer()    
D/DOMX    ( 4575): ENTER: hComponent = 0x3a4410, pCompPrv = 0x67ec58, nFilledLen = 0, nOffset = 0, nFlags = 00000000
D/DOMX    ( 4575): TRACE: Buffer Index of Match 3
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1357    RPC_FillThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:  pBufferHdr = 498348 BufHdrRemote 85a21d80
D/DOMX    ( 4575): TRACE: Recd. omx message
D/DOMX    ( 4575): TRACE: Waiting for messages from remote core
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1402    RPC_FillThisBuffer()    
D/DOMX    ( 4575): EXIT:
D/DOMX    ( 4575): TRACE: Corresponding RPC function executed successfully
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:602    PROXY_FillThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec.c:708    PROXY_VIDDEC_FillThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
I/VideoPhone( 4575):

===== submitting 3rd frame ========


I/VideoPhone( 4575):  [1345530431-DEBG :934] Calling DECODER with ptr: 5f000000 length: 955 at tv.tv_sec: 1345530431 tv.tv_usec: 928828
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:121    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:202    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:471    PROXY_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER: hComponent=0x3a4410, pCompPrv=0x67ec58, nFilledLen=955, nOffset=0, nFlags=00000000
D/DOMX    ( 4575): TRACE: Buffer Index of Match 0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1251    RPC_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:  pBufferHdr = 411a68 BufHdrRemote 85a211e8
D/DOMX    ( 4575): TRACE: Recd. omx message
D/DOMX    ( 4575): TRACE: Waiting for messages from remote core
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1323    RPC_EmptyThisBuffer()    
D/DOMX    ( 4575): EXIT:
D/DOMX    ( 4575): TRACE: Corresponding RPC function executed successfully
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:547    PROXY_EmptyThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
I/VideoPhone( 4575):
I/VideoPhone( 4575):  [1345530431-DEBG :945] Calling  OMX_FillThisBuffer with ptr: 5f500000 at tv.tv_sec: 1345530431 tv.tv_usec: 928828
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:581    PROXY_FillThisBuffer()    
D/DOMX    ( 4575): ENTER: hComponent = 0x3a4410, pCompPrv = 0x67ec58, nFilledLen = 0, nOffset = 0, nFlags = 00000000
D/DOMX    ( 4575): TRACE: Buffer Index of Match 4
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1357    RPC_FillThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:  pBufferHdr = 4ce4b8 BufHdrRemote 85a21dd0
D/DOMX    ( 4575): TRACE: Recd. omx message
D/DOMX    ( 4575): TRACE: Waiting for messages from remote core
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1402    RPC_FillThisBuffer()    
D/DOMX    ( 4575): EXIT:
D/DOMX    ( 4575): TRACE: Corresponding RPC function executed successfully
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:602    PROXY_FillThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec.c:708    PROXY_VIDDEC_FillThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
I/VideoPhone( 4575):
I/VideoPhone( 4575):  [1345530431-DEBG :934] Calling DECODER with ptr: 5f100000 length: 1979 at tv.tv_sec: 1345530431 tv.tv_usec: 950343
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:121    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): hardware/ti/domx/omx_proxy_component/omx_video_dec/src/omx_proxy_videodec_utils.c:202    PrearrageEmptyThisBuffer()    
D/DOMX    ( 4575): EXIT: eError: 0
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:471    PROXY_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER: hComponent=0x3a4410, pCompPrv=0x67ec58, nFilledLen=1979, nOffset=0, nFlags=00000000
D/DOMX    ( 4575): TRACE: Buffer Index of Match 1
D/DOMX    ( 4575): hardware/ti/domx/domx/omx_rpc/src/omx_rpc_stub.c:1251    RPC_EmptyThisBuffer()    
D/DOMX    ( 4575): ENTER:
D/DOMX    ( 4575): TRACE:  pBufferHdr = 411ac0 BufHdrRemote 85a21238

  • 0
    TI__Intellectual 1300 points

    Hi Pradeep,

    Which is the input stream you are using? Is it H264 stream? Have you tried to play this back using the Android Gallery application? The Android gallery app also uses DUCATI OMX decoder. Gallery app also uses Android stagefright framework to decode and display. So if you are able to trace the call flow in the stagefright framework for the same stream, you will be able to get some ideas on how to go about debugging this independent video decode application that you are enabling.

    Regards, Satheesh

  • 0 in reply to Satheeshvarma Janakiraman
    TI__Mastermind 24525 points

    "Ignoring the empty buffer done and fill buffer done callbacks"

    You can not ignore the callbacks. We have a pool of 4 buffers which must be fed back to the queue after they have been consumed by Ducati. This is typically done in the callback. If you ignore the callbacks, the queue will be empty and Ducati will not have any OMX buffers to operate.

  • 0 in reply to Mayank Mangla
    Intellectual 930 points

    Hi Mayank

                 I do not want to ignore the callback functions. I've used the statement to explain that the call back functions are not called by omx layer for the first frame itself. The i/p stream is H264 VGA stream. I receive only the PortSettingsChanged event and  empty_buffer_done or fill_buffer_done callbacks are not called. The omx component is in executing state. OMX component should respond with  errors  but i'm not seeing any errors.

    egards

    pradeep

  • 0 in reply to Pradeep Acharya
    TI__Genius 10545 points

    Are you handling port reconfiguration event to correct output port and cropping values?

  • 0 in reply to Manuel Contreras
    Intellectual 930 points

    Hi Manuel

                     I'm not configuring the output port and cropping values after receiving OMX_EventPortSettingsChanged event. The data pointer sent in the event handler is a void * and i think it is private to OMX decoder component. How do the app know the image detected by decoder ?

    regards

    pradeep

  • 0 in reply to Pradeep Acharya
    TI__Expert 4120 points

    Hi  Pradeep,

    Could you please ensure that the EventPortSettingsChanged callback is handled as per the requirements to avoid any errors. Please refer to the following post for further details on the EventPortSettingsChanged handling.

    http://e2e.ti.com/support/omap/f/849/t/192468.aspx

    Thanks & Best Regards,

    Venkat

  • 0 in reply to Venkat Ramana Peddigari
    Intellectual 930 points

    Hi Manuel/Venkat

     Thanks for the reply. I'll surely look in how to handle event port settings change indication and get back to u if on the progress. I have worked on DM 8148 and i could get the o/p from the decoder even if had not handled the event port settings change event. DM 8148 also works through open max implementation then why are there two different kind of implementations ?

    regards

    pradeep

  • 0 in reply to Pradeep Acharya
    TI__Genius 10545 points

    They are different OpenMax IL implementation for different processors, SW and HW are different like the codecs could accept or reconfigure in a different way, and IPC between processors is different and that affects the way that buffers are allocated and accessed.

    In Ducati the first input buffer is parsed and some values are read and codec needs to be reconfigured according to those values and buffers reallocated, that is the purpose of port reconfiguration event (OMX_PortSettingsChangedEvent). I haven't had the opportunity to read EZSDK's OpenMax IL implementation then I cannot say why it is not required to process this event.

  • 0 in reply to Manuel Contreras
    Intellectual 930 points

    Hi Manuel,

                 As per the guidance provided in above link, upon receiving EventPortSettingsChange Event, i had executing the following instructions

    1.  Sent command to transition to Idle State

    2. Sent command to disable the output port

    3. called omx_free buffers to free the buffers allocated for the o/p port.

    All the three instructions were successful. After that i had called OMX_GetParameter to get new configuration parameters on o/p port. The width, height and the buffer size provided are not matching with the resolution of the image given to the decoder.The i/p to the decode is CIF (352 * 288 ) where as the

    format.video.nFrameWidth and format.video.nFrameHeight values received from the o/p port is 256 and 256 and buff size required by decoder is returned as 98304. The logs of ducati also same the same thing

    [     21.647] [MNU=100] omx_videodec_common/src/omx_video_decoder.c:[994]: 1.Codec Create for ivahd_h264dec
    [     22.451] [ERR=101] omx_videodec_common/src/omx_video_decoder.c:[1872]:width = 176. expected width = 256, height =  144, expected height = 256
    [     22.452] [ERR=102] omx_videodec_common/src/omx_video_decoder.c:[1889]:Dynamic port reconfiguration triggered since small o/p buffer size provided in first frame decode

    The decoder should give the width and height of the image detected and also the buffer size required for the o/p image. why these values are wrong ?

    Then i hard coded the buffer size to (704 * 704 * 3)/2 so that sufficient amount of memory is allocated to decode a CIF image. I called the SetParameter and then I had allocated the buffers, enabled the o/p port and sent command to transition to Executing State.  These instructions were also successful. When i gave a new frame to decode, the Event Port settings change event is received once again. This happens continuously then the same set of commands and instructions gets executed infinitely.

    I received the cropping parameter change event while i was handling the EventPortSettingsChangeEvent. I handled that event by configuring the proper cropping values. There was an error in retrieving the default values

    hardware/ti/domx/domx/omx_proxy_common/src/omx_proxy_common.c:1385   __PROXY_GetConfig()
    D/DOMX    ( 3593): ERROR: failed check:(eError == OMX_ErrorNone) || (eError == OMX_ErrorNoMore) - returning error: 0x80001005 - Error returned from OMX API in ducati
    I/VideoPhone( 3593):
    I/VideoPhone( 3593):  [1345898914-EROR :1238] Failed to get the cropping param Component error val: 80001005

    I've attached the log which contains the messages logged by our Application and ducati traces. our App logs are tagged with VideoPhone

    6354.omap_4430_port_settings_log.txt

    Regards

    pradeep