M3 lock after 2 days decoding-display video

Hi All,

  We are using DM816x with EZSDK 5.05.02.00.  Our application is created on GStreamer which uses OMX. It basically plays H264 videos and record H264 videos. Some details:

  -Plays (Decode) H264 videos.
  -Record (Encode) H264 videos.
  -Play and record can be done simultaneously.
  -Resolution is 1080i60.
  -Video quality on final files is good, they are displayed correctly as well.
  -AAC audio.

We are having random problems during endurance testing after around 2 days where we just play videos one after another.

I would like to see if TI or others have had a similar issue and could provide a fix.

If we create an script to call our application in a loop playing the same H264 video like this:

    for m in `seq 1 $maxV`
    do
        echo "Playing $m"
        sleep 20
        app-play /media/mpeg/ParisRoubaix2013-Live.m2t
    done

 The system plays the video 20s and then restarts the pipeline again. This works well, but after 2 days we see the coprocessors lock up. On each app-play a new instance of the H264DEC is created and at the same time the instance currently playing is destroyed. Using valgrind and sys_top, it appears there is no memory leak on the ARM side nor in the M3 side.

Do you have any suggestion about why this could be happening or how to debug the problem?

Questions:
a) Does TI or someone else have any ideas about why this could be happening or how to debug the problem?
b) Has TI or someone else fixed issues like the ones described or have any suggestions?
c) Is there a way to restart OMX in case of a hang? Without rebooting the board or reloading the firmware?


Thanks,

-David