• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 97 subscribers
  • Views 1491 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.

OMX failing to restart a scalar component on DM814x

Jose Jimenez
Prodigy 245 points
Other Parts Discussed in Thread: SYSBIOS

HI,

We are trying to create a video player that supports various video input resolutions on a DM814x EVM using ezsdk 5.05.02.00 gst-omx plugins. The project works fine but after undergoing our endurance QA testing (which consist basically the creating and destroying the pipeline several times) stops with no error messages.

After applying several debug methods we manage to narrow down that the problem is produced after creating and destroying the scaler component several times. I was able to reproduce it using a omx application, after executing the application it locks down after ~62 iterations.  Using this method I did was able to get a error message while executing the application:

N:VPSS  P:2 #:56819 T:0000005b7ebee377 M:xdc.runtime.Main S:Error occured in VFPC ,Driver Index: 0             FVID2_processFrames with error code -3 

But this does not stop it from working several times (probably because I'm configuring wrong a parameter, still I don't think that this has to do  with the fact that is locking down after stressing the scaler). To create the input file I'm using a videotestsrc, capturing a few seconds of video

gst-launch -e videotestsrc num-buffers=150 ! 'video/x-raw-yuv,format=(fourcc)NV12,width=1920,height=1080,framerate=(fraction)30/1' ! filesink location=sample.yuv

I've Attached the source code (which can be use to replace the decode_scale omx example, and the executable) 4540.scale_display.zip Any suggestions on how we can solve this issue?

Thanks,

  • 0
    Prodigy 245 points

    I removed the display and control components from the application leaving just the scaler  and fixing the bad parameter configuration 5543.scale.zip, on this test, input buffers are passed from a file to the component and the output buffers are discarded.

    The application stops after several random number of iterations with the error message OMX_ErrorUndefined (which leads me to believe that the problem might be related to a failure on the media controller firmware). I got no error messages from the debug information while running  the loggerDump utility or the traces from sysbios on CSS. I have access to the src code from the media controller and will really appreciate any help to solve this problem.

    Thanks again,  

  • 0 in reply to Jose Jimenez
    TI__Guru* 80190 points

    Hello,

    Could you attach the both debug logs (via loggerDump utility)?

    Best Regards,

    Margarita

  • 0 in reply to Margarita Gashova
    Prodigy 245 points

    Hi,

    Thanks for your reply, I've attached the debug log (using the loggerDump utility) for the scaler application (as described on my second post) since  this involves just the component that Is giving me trouble.
     
    7345.scaler_debug_log.txt


    Thanks again

  • 0 in reply to Jose Jimenez
    TI__Guru* 80190 points

    Hello Jose,

    I will check this. I will get back to you when I have something.

    Best Regards,

    Margarita

  • 0
    TI__Guru* 80190 points

    Hello Jose,

    I tried to reproduce the issue with display_decode demo which is presented in EZSDK.

     I am not able to reproduced it after > 80 iterations.

    Jose Jimenez said:
    I was able to reproduce it using a omx application, after executing the application it locks down after ~62 iterations.  

    Which omx application you are pointing here ?

    Am I missing something?

    Best Regards,

    Margarita

  • 0 in reply to Margarita Gashova
    Prodigy 245 points

    Hi Margarita,

    I'm sorry for not explaining myself correctly; I made two applications based on the decode_display example to test the correct functionality of the scaler component, the first one (attached on the first post) has 3 components: a scalar component, a display component and a control component . On my second post I attached a new application on which I just stress the scalar omx  component.  The quote

    Jose Jimenez said:
    I was able to reproduce it using a omx application, after executing the application it locks down after ~62 iterations.  

    refers to my first application , nonetheless I had problems on both cases (just that on the scalar component only application the failure seems to be given at a more random number). The problem with the decode_display example is that as it is,  the application does not create and destroy the component within the same process on each iteration (so I guess you launch decode_display  application ~80 times) that's why I made a few modifications for this to happen on both of the applications I posted (which is more close to my real testing scenario), could you try to do that within the same application? or you can use the ones I posted.
     
    The loggerDump log that I attached previously refers to my second application  (the binary is in : 5543.scale.zip) on which , as I stated previously only the scalar component exists and the create/destroy of the scaler is done within the same process.

    Thanks again,

  • 0 in reply to Jose Jimenez
    TI__Guru* 80190 points

    Hello Jose,

    Jose Jimenez said:

    I'm sorry for not explaining myself correctly; I made two applications based on the decode_display example to test the correct functionality of the scaler component, the first one (attached on the first post) has 3 components: a scalar component, a display component and a control component . On my second post I attached a new application on which I just stress the scalar omx  component.  The quote

    I was able to reproduce it using a omx application, after executing the application it locks down after ~62 iterations.  

    refers to my first application , nonetheless I had problems on both cases (just that on the scalar component only application the failure seems to be given at a more random number). The problem with the decode_display example is that as it is,  the application does not create and destroy the component within the same process on each iteration (so I guess you launch decode_display  application ~80 times) that's why I made a few modifications for this to happen on both of the applications I posted (which is more close to my real testing scenario), could you try to do that within the same application? or you can use the ones I posted.
     
    The loggerDump log that I attached previously refers to my second application  (the binary is in : 5543.scale.zip) on which , as I stated previously only the scalar component exists and the create/destroy of the scaler is done within the same process.

    [/quote]

    I will recheck it with your application then.

    Best Regards,

    Margarita

  • 0 in reply to Jose Jimenez
    TI__Guru* 80190 points

    Hello,

    I observed the hang with your application on 167 iteration.

    Is the issue still exists on your side?

    Are you have the overlay package?

    Best Regards,

    Margarita

  • 0 in reply to Margarita Gashova
    Prodigy 245 points

    Hi,

    Yes this issue still is present on my side, and I have access to the overlay package. Any leads on how to solve this problem will be much appreciate.

    Thanks!

  • 0 in reply to Jose Jimenez
    Prodigy 245 points

    Hi,

    After a lot of time invested in this issue we were unable to to find reliable solution using the approach we decided when we first design our application, since this involved creating and destroying several instances of the scaler omx component. We were able to avoid this problem by using the a new set of gstreamer plugins which don't need to destroy  the handle of the omx component when switching between states.  More information on the following post: 

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/321566.aspx

    Thanks,