• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 98 subscribers
  • Views 2858 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.

VPSS (scalar) hangs after creating/destroying omx instance on endurance testing

David Soto - RidgeRun
Genius 3700 points


Hi All,

   During the process of developing a solution based on gstreamer/openMax able to play videos of different resolutions, scale the video to a fixed resolution and then display it, we found an issue with the current software available:

         1. The current gst-openMax plugins are not able to move between the gstreamer states: NULL, READY, PLAY, PAUSE. Normally a pipeline to play videos would look like (just an example):

gst-launch filesrc location= file.mpg ! gstperf ! tsdemux ! queue ! legacympegvideoparse ! omx_mpeg2dec ! queue ! omx_ctrl display-mode=OMX_DC_MODE_1080P ! omx_scaler !  'video/x-raw-yuv,width=1920,height=1080' ! omx_videosink

where <file.mpg> can be any resolution. So since you can't change the state of the omx_scaler to NULL you can't change the input resolution without destroying the scaler instance.

         2. If you develop the application to be creating/destroying the omx_scaler instance we found that the VPSS hangs sometimes after 10hrs, 15hrs, 18hrs, etc. It just hangs without giving any information in the output, even if you enable all the debug, or if you get access to the M3s through CCS. As you can see we were able to reproduce it just using omx without gstreamer, the problem appears more frequently if you increase the amount of instances of omx_scaler in the pipeline.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/311441/1101464.aspx

           After a lot of testing and time invested in the process we were able to see that the process that causes the crash is on the omx_scaler and likely in the OMX_GetHandle function which is called every time that you create a new instance, at some point it doesn't return.

           So we are trying to find the problem but at the same time we were able to create a new gst-openMax plugins on gstreamer 0.10 which are able to change the gstreamer state without problems, we did it for omx_scaler and omx_mpeg2dec , doing this we got rid of the problem that was killing the endurance test, now the system can change resolutions without destroying the instance so the problem doesn't appear anymore. Ridgerun is on the process to clean the patches and we are going to check in the code in:

https://github.com/RidgeRun/gst-openmax-dm81xx

           I hope this information help you as well if you are fighting with an endurance test and openMax,

-David

  • 0
    TI__Guru* 80190 points

    Hello David,

    I am glad that this issue is solved.

    Thank you for information.

    Best Regards,

    Margarita

  • 0 in reply to Margarita Gashova
    Genius 3700 points

    Hi Margarita, 

       Well, the issue is not solved but at least with the new plugins there is a workaround,

    Regards,

    -David

  • 0 in reply to David Soto - RidgeRun
    Expert 1275 points

    Hi David!

    Is it the code already in the repository? I would like to test it! I'm already having a problem with my application based in gstreamer. I'm using a creation/destruction loop to play every video but finally it hangs. I have an thread in this forum at

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/322779.aspx

    Regards

  • 0 in reply to Anonymous Developer
    Genius 3700 points

    Hi Anonymous Developer,

    1) The code is not in github yet but we will make it available during this week on the RidgeRun github repository. We are also creating the deiscaler and h264 decoder

    2) It is important to mention that at this point we have just omx_scaler and omx_mpeg2dec implemented and the base classes, in your case you would require omx_mpeg4dec too.

    3) In your case your test fails after 15 iterations, in our case the pipeline was failing after some hours of switching every 30 seconds. However, we have seen that the problem could appear faster if you are using a slower RAM, i.e, with one board running at 400MHz we can make it fail after something like 15 iterations, boards like the DM8168 running at 800MHz can show the problem after hours, we are in the process of verifying that, I will let you know the results.

    4) In any case, the correct approach is to create the handle just once, so you can workaround the problem described above, our plugins can do this.

    5) I will respond about your issue in your post as well as suggest how to narrow down the issue.

  • 0 in reply to David Soto - RidgeRun
    Expert 1275 points

    Hi David,


    1) The code is not in github yet but we will make it available during this week on the RidgeRun github repository. We are also creating the deiscaler and h264 decoder

    2) It is important to mention that at this point we have just omx_scaler and omx_mpeg2dec implemented and the base classes, in your case you would require omx_mpeg4dec too.

    Ok, I'll be looking forward to see when the changes are available. Maybe with the omx_mpeg2dec diff we can implement the omx_mpeg4dec easily, but I can always reencode my videos in mpeg2 format.

    3) In your case your test fails after 15 iterations, in our case the pipeline was failing after some hours of switching every 30 seconds. However, we have seen that the problem could appear faster if you are using a slower RAM, i.e, with one board running at 400MHz we can make it fail after something like 15 iterations, boards like the DM8168 running at 800MHz can show the problem after hours, we are in the process of verifying that, I will let you know the results.

    I'm using the DM8148 mistral demoboard, I don't know if the RAM is slow or not...

    4) In any case, the correct approach is to create the handle just once, so you can workaround the problem described above, our plugins can do this.

    Yes, that's the way I'm using my video player on x86 and OMAP3 platforms. The only thing I change is the filesrc location property, but I found that couldn't set the NULL state in order to do the change, then I tried with the destroy/creation option.

    5) I will respond about your issue in your post as well as suggest how to narrow down the issue.

    Thanks, I'm waiting the end of the test you recommend me in order to answer you

  • 0 in reply to David Soto - RidgeRun
    Expert 1275 points

    Hi David

    David Soto said:

    1) The code is not in github yet but we will make it available during this week on the RidgeRun github repository. We are also creating the deiscaler and h264 decoder

    I would like to know if you have upload the code to the repository?

    I have another question, maybe little off-topic. Do you know if there is a gstreamer 1.0 version of these components? I would like to the the eglglessink element but only is gstreamer 1.0

    Thanks!

  • 0 in reply to Anonymous Developer
    TI__Guru* 80190 points

    Hello Anonymous Developer,

    GST version (1.0) migration for dm8168/dm8148 platforms will not happen for EZSDK. If you  are looking for latest version of GST on this SW platform, you have to do it on your own.

    Best Regards,

    Margarita

  • 0 in reply to Margarita Gashova
    Expert 1275 points

    Hi Margarita,

    Yes, I know, I've read the post http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/244924.aspx but I thought that the same way they have modified several omx components maybe they have updated them to 1.0, or they a parallel repo where are testing the update.. I've read too that RidgeRun were planning GStreamer 1.0 support for DM368 and this new is from February, 2013, then something about Gstreamer 1.0 they know :)

    http://www.ridgerun.com/www/index.php/blog/88-gstreamer10.html

    Regards

  • 0 in reply to Anonymous Developer
    TI__Guru* 80190 points

    Hello,

    Anonymous Developer said:
    e read too that RidgeRun were planning GStreamer 1.0 support for DM368 and this new is from February, 2013, then something about Gstreamer 1.0 they know

    This is DMAI GStreamer plug-in.

    http://processors.wiki.ti.com/index.php/DMAI_GStreamer_Plug-In_Getting_Started_Guide

    It is not for EZSDK. In EZSDK we are have OMX-gst.

    Best Regards,

    Margarita

  • 0 in reply to Anonymous Developer
    Genius 3700 points

    Hi Anonymous Developer, 

            You can find information about the gstreamer repositories here:

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

            Also, for DM36x we created plugins based on gstreamer 1.0 where we removed the DMAI layer since for us it was not needed, so get access to the codecs just using codec engine:

    https://developer.ridgerun.com/wiki/index.php/DM36x_GStreamer-1.0_pipelines

    https://github.com/RidgeRun/gst-ce-plugin

    -David

  • 0 in reply to David Soto - RidgeRun
    Expert 1275 points

    Thank you David! This is the kind of information I was looking for!

    From your link I understand that in 2) I can get the modified omx_scaler with your patches, and in 1) you still have to do the commit because I have not seen any recent commit...

    Regards

  • 0 in reply to Anonymous Developer
    Genius 3700 points

    Hi,

      Yes, you can get it from 2) we are not going to patch 1) instead we will continue the development on 2).

    -David