From: Sven Van Asbroeck <thesven73@gmail.com>
To: Philipp Zabel <p.zabel@pengutronix.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Sven Van Asbroeck <thesven73@gmail.com>,
Adrian Ratiu <adrian.ratiu@collabora.com>,
Lucas Stach <l.stach@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [BUG REPORT] media: coda: mpeg4 decode corruption on i.MX6qp only
Date: Wed, 3 Feb 2021 11:33:48 -0500 [thread overview]
Message-ID: <20210203163348.30686-1-TheSven73@gmail.com> (raw)
From: Sven Van Asbroeck <thesven73@gmail.com>
We have observed that under certain repeatable circumstances, the CODA
mem2mem device consistently generates corrupted frames. This happens only
on an i.MX6qp (Plus) - the classic imx6q is not affected.
This happens when the virtual X screen is wider than 0x900 pixels (1).
Quite strange, because CODA is a mem2mem device, and is presumably not touching
any of the IPU/GPU2D/GPU3D infrastructure used by X. Except if there is a hidden
dependency somehow.
I have captured and visualized generated CODA frames as follows:
gst-launch-1.0 playbin uri=file:///home/default/nycTrain1080p.mp4 flags=0x45
video-sink='multifilesink location=frame%d.yuv'
See (2) for how I converted the raw YUV frame to a PNG image.
For example, the following will break CODA mpeg4 decode (width >= 0x900):
# xrandr --fb 2400x1088
Screen 0: minimum 1 x 1, current 2400 x 1088, maximum 4096 x 4096
HDMI1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1280x800 59.79*+
Resulting frame when dumped with multifilesink (NOT written to the display):
https://gitlab.com/TheSven73/coda-investigation/-/blob/master/stripes.png
And the following will restore CODA mpeg4 decode (width < 0x900):
# xrandr --fb 2300x1088
Screen 0: minimum 1 x 1, current 2300 x 1088, maximum 4096 x 4096
HDMI1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected primary 1280x800+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1280x800 59.79*+
Resulting frame when dumped with multifilesink (NOT written to the display):
https://gitlab.com/TheSven73/coda-investigation/-/blob/master/ok.png
Additional info:
- only the virtual X screen width seems to trigger the issue, it is
independent of the height.
- issue seems independent of the pixel format. Forcing CODA to output NV12
shows the same behaviour.
System description:
- i.MX6 QuadPlus:
[ 0.144518] CPU identified as i.MX6QP, silicon rev 1.1
- mainline Linux v5.9.16 with a small private patchset on top
(patchset does not touch CODA)
- CODA960 silicon contained within i.MX6 QuadPlus:
[ 4798.510033] coda 2040000.vpu: Firmware code revision: 46076
[ 4798.515916] coda 2040000.vpu: Initialized CODA960.
[ 4798.520779] coda 2040000.vpu: Firmware version: 3.1.1
- gstreamer from buildroot:
gst-launch-1.0 version 1.16.2
GStreamer 1.16.2
- X from buildroot, using armada and etnadrm_gpu plugins:
X.Org X Server 1.20.7
X Protocol Version 11, Revision 0
[ 99.527] (II) LoadModule: "armada"
[ 99.527] (II) Loading /usr/lib/xorg/modules/drivers/armada_drv.so
[ 99.538] (II) Module armada: vendor="X.Org Foundation"
[ 99.538] compiled for 1.20.7, module version = 0.0.0
[ 99.538] Module class: X.Org Video Driver
[ 99.538] ABI class: X.Org Video Driver, version 24.1
[ 99.538] (II) armada: Support for Marvell LCD Controller: 88AP510
[ 99.539] (II) armada: Support for Freescale IPU: i.MX6
[ 99.545] (II) armada(0): Added screen for KMS device /dev/dri/card1
[ 99.561] (II) armada(0): hardware: imx-drm
[ 99.563] (**) armada(0): Option "AccelModule" "etnadrm_gpu"
[ 99.563] (II) Loading sub module "etnadrm_gpu"
[ 99.563] (II) LoadModule: "etnadrm_gpu"
[ 99.564] (II) Loading /usr/lib/xorg/modules/drivers/etnadrm_gpu.so
[ 99.576] (II) Module Etnaviv GPU driver (DRM): vendor="X.Org Foundation"
[ 99.576] compiled for 1.20.7, module version = 0.0.0
(1) When using multiple displays, the virtual X screen is typically the bounding
rectangle which includes all screens. That's why it can become wider than
1920 pixels.
(2)
# Convert raw YUYV to PNG
# Python, runs out of the box on a stock Google Colab notebook
import cv2
import numpy as np
import matplotlib.pyplot as plt
import matplotlib
img = np.fromfile('frame1.yuv', dtype=np.uint8)
# YUYV has two 8-bit channels per pixel
img.shape = (1088, 1920, 2)
img2 = cv2.cvtColor(img, cv2.COLOR_YUV2RGB_YUYV)
plt.imshow(img2)
matplotlib.image.imsave('frame1.png', img2)
To: Philipp Zabel <p.zabel@pengutronix.de>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Adrian Ratiu <adrian.ratiu@collabora.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: linux-media@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
next reply other threads:[~2021-02-03 16:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 16:33 Sven Van Asbroeck [this message]
2021-02-10 16:11 ` [BUG REPORT] media: coda: mpeg4 decode corruption on i.MX6qp only Nicolas Dufresne
2021-02-10 18:11 ` Sven Van Asbroeck
2021-02-10 18:29 ` Sven Van Asbroeck
2021-02-11 14:32 ` Philipp Zabel
2021-02-11 15:15 ` Sven Van Asbroeck
2021-02-12 23:52 ` Sven Van Asbroeck
2021-02-15 10:15 ` Lucas Stach
2021-02-15 15:54 ` Sven Van Asbroeck
2021-02-15 16:10 ` Lucas Stach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210203163348.30686-1-TheSven73@gmail.com \
--to=thesven73@gmail.com \
--cc=adrian.ratiu@collabora.com \
--cc=festevam@gmail.com \
--cc=l.stach@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).