Video playback failure

[billgerba]

Hi All,

We have been testing the i.MX6 by way of the SABRE Lite board from Boundary Devices for use as a digital signage platform, and have seen some strange behavior that might point to a a VPU/IPU bug that comes up after initializing/deinitializing the decoder and/or the video sink a reasonably large number of times (perhaps around 10,000-12,000 times).

Regardless of whether we use our FireCast Linux image (based on the Yocto kernel and native X with accelerated drivers from Vivante), or the stock LTIB for the SABRE Lite board (downloaded here: http://boundarydevices.com/ltib-4-0-0-images/), which uses XVfb and the framebuffer (so, no Vivante drivers at all), the result is consistent. Specifically, once these kernel error messages start appearing in the log:

imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_5 = 0x88800000

imx-ipuv3 imx-ipuv3.0: IPU Warning - IPU_INT_STAT_10 = 0x00100000

mxc_sdc_fb mxc_sdc_fb.0: timeout when waiting for flip irq

videos fail to play back. On the accelerated X system, other windows and applications continue to run normally, but the video area remains white (which I think is just the color of the last frame of the last successfully played video). On the framebuffer based system, it appears to affect the entire framebuffer, and the screen goes blank.

We have tested with a number of different videos, all encoded as 720p h.264 Main Profile streams in mpeg-4 containers. Some have had audio, some haven't (it doesn't seem to make a difference). Since it was our belief that the number of playbacks was one of the criterial properties of the bug, all have been short, 30 seconds or less.

To play the files, we used a very simple shell script and a very simple gst pipeline:

#!/bin/bash

while [ 1 ]

do

        gst-launch filesrc location=/root/10sec1_1080p.mp4 typefind=true ! aiurdemux ! vpudec ! mfw_isink disp-width=1280 disp-height=720

        gst-launch filesrc location=/root/10sec2_1080p.mp4 typefind=true ! aiurdemux ! vpudec ! mfw_isink disp-width=1280 disp-height=720

        gst-launch filesrc location=/root/10sec3_1080p.mp4 typefind=true ! aiurdemux ! vpudec ! mfw_isink disp-width=1280 disp-height=720

done

We have seen similar results using the v4lsink, which leads us to believe that there may be a problem either in some code shared between some of the output sinks, or something in the vpu decoder (even though the kernel messages point to the IPU). We have also tried to mitigate hardware as a factor by using multiple boards, all with actively cooled SoCs that never run hotter than about 60C.

Has anyone else seen this behavior? For that matter, has anyone else attempted to play videos nonstop for many days?

Thanks,

Bill

[EricNelson]

Hi Bill,

A nominal test with a 3-second, video-only Iron Man trailer (1080P) on a 1080P display works on both a Timesys image (w/1.1.1 kernel and gst-fsl-plugin-3.0.5) works without clearing /dev/shm.

Same for LTIB-4-no-X image taken from this post:

     http://boundarydevices.com/ltib-4-0-0-images/

I'll set up the LTIB image to boot into the loop and set it up in the lab so I can check in on it occasionally.

Am I understanding you correctly, that this take 10k iterations on average, and that you're playing 10-second clips?

If so, testing on a single device isn't going to help much, unless we get lucky.

Please advise,

Eric

[billgerba]

Hi Eric,

The 10K playbacks is an estimation since our bash script didn't have a counter and wasn't logging to a file. However, playing successive 10 sec clips it took less than 2 days, so about 10K playbacks seems plausible.

We have tested with dozens of different clips, but the last test was with 3 samples downloaded from Youtube. You can get them from:

http://rei.wirespring.net/downloads/Freescale/10sec1_1080p.mp4

http://rei.wirespring.net/downloads/Freescale/10sec2_1080p.mp4

http://rei.wirespring.net/downloads/Freescale/10sec3_1080p.mp4

As for testing on a single board, the only thing I can say is that we have seen this issue on at least 5 different boards, however they've all been rev 1.0 silicon.

[EricNelson]

Hi Bill,

I just took a look at the test rig here, and it's still running my 10-second Iron Man clip (a little less than 48 hours).

I'm running 1.2 silicon on a Nitrogen6x board with LTIB-4.0.0.

I'll load up these videos and run through the weekend.

[billgerba]

Hi Eric,

Do you happen to have any rev 1.0 SABRE Lite boards around? It would be great to isolate this to a specific hardware version.

[EricNelson]

Hi Bill,

I'm trying to reproduce things here, but my first attempt is kinda stymied. I'm using Yocto (the image I had handiest) and things stall immediately on the second iteration and need to clear out /dev/shm/ as described in

      https://bugzilla.yoctoproject.org/show_bug.cgi?id=3781#c14

I'll grab the LTIB userspace next.

Meanwhile, do you have the set of test videos on-line somewhere, so I can use the same setup for testing?

Please advise,

Eric