i.MX6Q Image capture wrap around

[craigmahaney]

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.

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[craigmahaney]

I was never able to resolve this issue with the configuration as described. A workaround was found using a capture format of YUYV and performing the CSC as a separate IPU task.

[rogerio_silva]

Hi Craig,

Are you using VIDIOC_STREAMON and VIDIOC_STREAMOFF to continuously sync the video capture, for each captured frame? Or you're using only once to start the capture?

[craigmahaney]

Hi. In the test setup, VIDIOC_STREAMON is used to start capture and the capture is allowed to run for two seconds, then VIDIOC_STREAMOFF is issued to stop the capture, and the sequence is repeated. There is no intent to use them to sync the capture for each captured frame.

[rogerio_silva]

Hi Craig,

I can't think on anything obvious that could be causing this problem.

Is it possible to print the config framebuffer and v4l2 structures every time you turn on and off in order to check if some config is not being properly configured or missing its config?

Is it possible to somehow reproduce this problem using a Fresscale board?

[jamesbone]

We are in the process of reviewing internally your question, as soon as we get an answer we will back to you.