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:
while [ 1 ]
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
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?