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:
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?