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

Voip application use gst-openmax appera PVR_K error

Aaron Pope
Intellectual 465 points

Hi,all!

    I have the ics 4.0.3  and omap4430. I want to use gstreamerand gst-openmax. I use the linphone on pc and voip in the android. I have to call the voip more than once,the omx_h264dec can not work  and the system appera PVR_K error.The camera in the voip use the surfaceflinger ,encode use the omx_h264enc and the decode use the omx_h264dec.The PVR_K error.log is message about PVR_K error and error_msg.log is the information about gst-openmax.The error occer after i call the voip app some times ,i gather the logs on the third time. I think the PVR_K is about the memory alloc.Thank you!

BR

Aaron4667.PVR_K error.log

7416.error_msg.log

  • 0
    TI__Intellectual 1410 points

    Aaron,

    From the log it is clear that the system is out of memory when you are attempting second call. Please have a look at log:

    [ 3571.559234] omap_tiler_alloc: failure to allocate address space from tiler

    Tiler memspace is special memory for the HW engines for better efficiency. You need to exit the earlier call cleanly and make sure freeing up all the buffers. The codec buffers are allocated using android_tative_buffer APIs.

    Regards,

    Chintan

  • 0 in reply to Chintan Patel
    TI__Genius 10545 points

    Can you explain the test case values? used resolutions, how many instances running at the same time? are second instance waiting for first one to be unloaded? thanks.

  • 0 in reply to Manuel Contreras
    Intellectual 465 points

    Hi,Manuel!

        The size of the test case is 1280*720, frameRate is 25 and the BitRate is 1M.There is one  instance at the same time,there are camera  decode and encode omx componet in the instance.the omx component are running at the same time and unload at the same time .The second instance will run after the first one be stopped. Thank you !

    BR

    Aaron

  • 0 in reply to Aaron Pope
    TI__Genius 10545 points

    Some more questions.

    1. Have you tried to use a smaller resolution?

    2. What release from omapedia.org are you using? 4AI1.7?

    3. You said that first and second time it runs ok, then third fails?

    4. have you confirmed buffers are being freed?

  • 0 in reply to Manuel Contreras
    TI__Genius 10545 points

    Aaron;

    You have this other post

    http://e2e.ti.com/support/omap/f/849/p/210279/793974.aspx

    is it the same issue as this one?

  • 0 in reply to Manuel Contreras
    Intellectual 465 points

    Hi,Manuel!

        1.I have tried a smaller resolution,it likes this.

        2.Not 4AI1.7

        3.yes

        4.I confirme the buffers now but i check the code by tools and not find the large buffer leak.

       http://e2e.ti.com/support/omap/f/849/p/210279/793974.aspx  is the same as this question.

        I want to find the PVR_K memory information,and how can i get the info about PVR memory?

    BR

    Aaron

  • 0 in reply to Aaron Pope
    TI__Genius 10545 points

    Aaron;

    To check the Tiler information you can find details for it in next post

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

    About PVR_K I don't have information, I know that in latest Android releases the memory allocation tasks were modified to use HW allocation from Graphics side using gralloc function.

    But check next links for more details, from general to some related points.

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

    http://e2e.ti.com/support/omap/f/849/p/145319/525667.aspx#525667

    http://e2e.ti.com/support/omap/f/849/p/208466/738697.aspx#738697

    About the issue, if changing the resolution is not helping and you still see the failure at the same number of repetitions before failure, I suspect that it is a thread issue where releasing the buffers is overlapped or delayed with new allocations, this since you confirmed that buffers are being freed now. Probable some multi-threaded code in application code that is not waiting for the buffers to be deallocated? it matches with what Patel mentioned in the second post.