I am working with a custom i.MX6Q board that is having an issue with image capture.
The issue is that after several VIDIOC_STREAMON / VIDIOC_STREAMOFF cycles we eventually get an image wrap-around where it appears as if the image capture is starting toward the right edge of the image. The amount of the image that appears wrapped varies, but so far appears to only have two states. The images below illustrate the issue:
This image shows proper alignment.
This image shows the "first step" of the wrap around.
Which will progress to the "second step" of the wrap around.
While in the "second step" phase I pointed the camera at a white field, then post processed the captured image to increase the contrast so the wrap is obvious. The vertical black bar is part of the image from the camera and should end at the right edge of the display window.
The image capture setup is:
NTSC Camera --> Decoder (BT656 8-bit parallel w/ external sync signal) --> IPU1:CSI1 --> IC (PRP_ENC w/ YUV-to-RGB CSC) --> MEM
To be clear, the setup uses the second CSI on the second IPU, and the image pipeline uses the IC PRP ENC task w/ colorspace conversion from YUV to RGB, then IDMA to memory. Though the stream is BT656 and the source is interlaced, there is no deinterlace processing. The capture is 720x240 at 60 fps and the display window size is 720x480.
In normal operation the sync status from the decoder is used by system software to enable and disable video streaming. The issue occurs faster in this setup if the video source is repeatedly disconnected and reconnected. In order to make sure that the issue is not being caused by the hardware disconnect/reconnect, the software was altered to repeatedly VIDIOC_STREAMON and VIDIOC_STREAMOFF while the video source was continuously connected, and the issue still occurs. While not the cause of the issue, the activity of the external sync signal during stream on/off seems to be a contributing factor.
The video wrap around persists once it has occurred. Using another image capture program (e.g. direct to a file rather than for real-time display) yields the same result. The only thing that resolves the issue is a reset of the i.MX6Q.
The IPU parts of the kernel being used are up to date with the latest imx_3.0.35_4.1.0 branch for the most part.
It is interesting to note that the custom board also does image capture from a 16-bit parallel source using a different path that does not suffer from the image wrap around:
RGB 16-bit parallel w/ external sync -> IPU0:CSI0 --> MEM
The capture is 640x480, at 60fps with a display window of 640x480. The IC is not used in this path.