SK-AM62A-LP: CSI2RX width mismatch on cold boot with direct 640x640 preproc path

Part Number: SK-AM62A-LP

Hi team,

I’m seeing an issue with the OD application on AM62A during cold boot.

The OD app is based on apps_python, and on application startup it prints the following dmesg error:

j721e-csi2rx 30102000.ticsi2rx: Width does not match (source 1920, sink 640)

The OD application input pipeline is:

v4l2src device=/dev/video-imx219-cam1 io-mode=5 pixel-aspect-ratio=None ! queue leaky=2 ! capsfilter caps="video/x-bayer, width=(int)1920, height=(int)1080, format=(string)rggb" ! tiovxisp dcc-isp-file=/opt/imaging/imx219/linear/dcc_viss.bin sensor-name=SENSOR_SONY_IMX219_RPI ! capsfilter caps="video/x-raw, format=(string)NV12" ! tiovxmultiscaler name=split_01
split_01. ! queue max-size-buffers=4 leaky=2 ! capsfilter caps="video/x-raw, width=(int)1280, height=(int)720" ! tiovxdlcolorconvert out-pool-size=4 ! capsfilter caps="video/x-raw, format=(string)RGB" ! appsink max-buffers=2 drop=True name=sen_0
split_01. ! queue ! capsfilter caps="video/x-raw, width=(int)640, height=(int)640" ! tiovxdlpreproc out-pool-size=4 data-type=3 tensor-format=1 ! capsfilter caps="application/x-tensor-tiovx" ! appsink max-buffers=2 drop=True name=pre_0


However, the CL application works correctly with the following pipeline: 

v4l2src device=/dev/video-imx219-cam0 io-mode=5 pixel-aspect-ratio=None ! queue leaky=2 ! capsfilter caps="video/x-bayer, width=(int)1920, height=(int)1080, format=(string)rggb;" ! tiovxisp dcc-isp-file=/opt/imaging/imx219/linear/dcc_viss.bin sensor-name=SENSOR_SONY_IMX219_RPI ! capsfilter caps="video/x-raw, format=(string)NV12;" ! tiovxmultiscaler name=split_01
split_01. ! queue max-size-buffers=4 leaky=2 ! capsfilter caps="video/x-raw, width=(int)1280, height=(int)720;" ! tiovxdlcolorconvert out-pool-size=4 ! capsfilter caps="video/x-raw, format=(string)RGB;" ! appsink max-buffers=2 drop=True name=sen_0
split_01. ! queue ! capsfilter caps="video/x-raw, width=(int)1188, height=(int)668;" ! tiovxmultiscaler target=1 ! capsfilter caps="video/x-raw, width=(int)454, height=(int)256;" ! tiovxdlcolorconvert out-pool-size=4 ! capsfilter caps="video/x-raw, format=(string)RGB;" ! videobox qos=True left=115 right=115 top=16 bottom=16 ! tiovxdlpreproc out-pool-size=4 data-type=3 ! capsfilter caps="application/x-tensor-tiovx;" ! appsink max-buffers=2 drop=True name=pre_0

Important observation:

  • The OD application works correctly without the width mismatch error if the CL application is executed once after every boot.

  • But when after running the CL application says: [ERROR] Error pulling tensor from GST Pipeline

This issue is noticed after I created a base image by removing some edgeai recipes.

```

SUMMARY = "base image"
DESCRIPTION = "base image."
LICENSE = "CLOSED"

require recipes-core/images/tisdk-default-image.bb

COMPATIBLE_MACHINE = "am62axx"

EDGEAI_STACK = " \
ti-vision-apps-dev \
ti-edgeai-firmware \
ti-tidl-dev \
edgeai-tiovx-kernels-dev \
edgeai-tiovx-apps-dev \
"

EDGEAI_STACK:append:edgeai = " \
ti-tidl-osrt-dev \
ti-tidl-osrt-staticdev \
edgeai-init \
edgeai-tiovx-modules-dev \
edgeai-gst-plugins-dev \
edgeai-dl-inferer-staticdev \
ti-gpio-cpp-dev \
ti-gpio-py \
"

IMAGE_INSTALL:append = " \
${EDGEAI_STACK} \
init-scripts \
python3-opencv \
python3-numpy \
bc \
net-tools \
procps \
"

IMAGE_INSTALL:remove = " \
packagegroup-arago-tisdk-matrix \
packagegroup-arago-tisdk-matrix-extra \
ti-test \
ltp-ddt \
"

WKS_FILE = "image.wks"
WIC_CREATE_EXTRA_ARGS += " --no-fstab-update"
EXTRA_IMAGECMD:ext4 += " -E lazy_itable_init=0,lazy_journal_init=0"

IMAGE_FSTYPES = "wic.xz tar.xz"

IMAGE_BASENAME = "base-image${ARAGO_IMAGE_SUFFIX}"
export IMAGE_BASENAME


```

Could you please advise and help fix this issue?

Best Regards,
Sajan

  • Hi Sajan,

    A few questions. Have you managed to recreate this issue on the EVM? Or with the default SDK?

    To confirm the application behavior:

    1. Directly running OD results in the width issue
    2. CL -> OD -> CL causes the CL pipeline to fail with the GST Tensor issue.

    Can you please run the pipelines with GST_DEBUG variable set to 4? This should give decently verbose logs and help understand the issue.
    Also, please switch out appsink with fakesink in the pipeline and see if the pipeline still causes the issue with the 720p part of the pipeline removed(with fakesink). This should help remove the dependency on the inference application and isolate it to the GStreamer pipeline.

    Regards,
    Jay