Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <804285cff81878a2c188d1b823182114f891ca38.camel@ndufresne.ca>
Subject: Re: [BUG REPORT] media: coda: mpeg4 decode corruption on i.MX6qp
 only
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Sven Van Asbroeck <thesven73@gmail.com>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        Mauro Carvalho Chehab <mchehab@kernel.org>
Cc:     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
Date:   Wed, 10 Feb 2021 11:11:16 -0500
In-Reply-To: <20210203163348.30686-1-TheSven73@gmail.com>
References: <20210203163348.30686-1-TheSven73@gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Sven,

Le mercredi 03 février 2021 à 11:33 -0500, Sven Van Asbroeck a écrit :
> 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).

Are you sure you aren't just running out of CMA ? This is the only things that
comes to mind at the moment, sorry if it's not that useful.

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