HDMI video playback issue on IMX6: VPU blocking

Technical Support
, ,
1

Trying to upgrade our IMX6 modules to the latest official multimedia image, we have run into some issues with video playback on HDMI.

For one thing, movies that ran smoothly with the old image now produce visible artifacts and stutters.

Also, after a few (typically around 30) seconds of playback, we get this:

[ 74.093683] mxc_vpu 2040000.vpu_fsl: VPU blocking: timeout.
[ 74.603746] mxc_vpu 2040000.vpu_fsl: VPU blocking: timeout.
[ 75.113810] mxc_vpu 2040000.vpu_fsl: VPU blocking: timeout.
[ 75.623743] mxc_vpu 2040000.vpu_fsl: VPU blocking: timeout.
[ERR] fatal: VPU is busy in vpu_DecGetOutputInfo
ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: Internal data stream error.
Additional debug info:
…/git/gst/isomp4/qtdemux.c(6605): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0:
streaming stopped, reason error (-5)
Execution ended after 0:00:33.764433337
Setting pipeline to PAUSED …
Setting pipeline to READY …

This happens with H264 1080p movies on Colibri IMX6DL 512MB in the Colibri Evaluation Board using the HDMI Adapter on “TDX Wayland with XWayland 5.4.0+build.11 (dunfell) colibri-imx6-10615144 (Reference Multimedia Image)”, installed through the EasyInstaller.

We use the following gstreamer pipeline for playback:

gst-launch-1.0 filesrc location=movie.mp4 ! qtdemux ! h264parse ! imxvpudec ! progressreport update-freq=1 ! videoconvert ! queue ! imxipuvideosink use-vsync=true

You should be able to reproduce it using the Simpsons Movie 1080p Trailer (120 MB) from H.264 Demo Clips - H264info.com

Would you happen to know a way to make this work?

2

Hello @cockroach ,

Could you please tell us the output of uname -a.

Meanwhile, I also found this discussion thread on the NXP Community which might also be helpful to you.

Best Regards,
Janani

3

Hi @saijanani.tx

uname -a says “Linux colibri-imx6-10615144 5.4.129-5.4.0+git.cb88cc157bfb #1 SMP Wed Sep 29 18:17:21 UTC 2021 armv7l armv7l armv7l GNU/Linux”.

Also, you mention a discussion thread but I can’t seem to find a link anywhere.

Kind regards

4

Hello @cockroach ,

Thank you for the version details. The common reasons for this to happen can be due to using older imx-vpu versions or also due to over-clocked VPU cores. Can you imagine any of the above reasons?

Here is the thread that I forgot to attach before:

BR, Janani

5

Hi @saijanani.tx

Thank you for the link. It does look similar to our problem, except that the lockups happen much more frequently on our board.

I don’t think it’s related to over-clocking – the module was re-flashed with an unmodified version of the Toradex image, I wouldn’t expect that image to over-clock anything. Can I somehow verify that?

As for older imx-vpu versions, what exactly do you mean with that? The gstreamer module?

6

Hello @cockroach ,

Meanwhile, we tried reproducing the issue here and modifying the pipeline improved the performance a lot. The stutters that were present initially did not appear when using the following pipeline:

gst-launch-1.0 filesrc location=simpsons.mp4 ! qtdemux ! h264parse ! imxvpudec ! progressreport update-freq=1 ! videoconvert ! queue ! overlaysink

As for older imx-vpu versions, what exactly do you mean with that? The gstreamer module?

Exactly I used the Gstreamer that came with the image and could run smooth videos now.

Could you try this maybe?

Best regards,
Janani

7

Hello @saijanani.tx

Thank you, that does indeed improve performance and, more importantly, it doesn’t crash anymore.

I do however still get video corruption around 20 seconds into playback:

8

Hello @cockroach ,

That’s great to hear. As I predicted, this was indeed related to the Gstreamer pipeline construction. So, I would suggest that we still try to play around with the pipeline to eliminate the remaining issues. As I am not able to reproduce this stutter at my end, I am gone shoot some suggestions that worked for me in the past/ for some customers.

Some of the commands I would try to include in the pipeline are:

  • sync= false which ignores the timestamps and display the incoming frame as such
  • Another thing to try is to use rtpbin as bin usually does a lot of smart buffering.
  • autovideosink can also be useful here because it decides automatically which video sink to use

Could you maybe try some of the above suggestions / explore with the pipeline and let us know what worked?

BR, Janani