Missing v-sync in Bt.656 capture (rolling video)

[jwatts]

I'm integrating the TW9966 and imx6q, and have gotten things very close to functional, but it seems that I can't get the CSI (IDMAC?) correctly decode/lock on to the v-sync SAV/EAV codes. Video is captured on IPU1 CSI0, 8-bit embedded sync, and I've created a V4L2 slave driver based on adv7180.c. Attached is a single frame captured using the gstreamer pipeline "mfw_v4lsrc ! filesink location=output.raw", converted to mkv using "avconv -f rawvideo -video_size 720:520 -pixel_format yuv420p -framerate 30 -i output.raw output.mkv" and then a single frame exported via avidemux. The snapshot shows what is clearly fields from two separate frames, and also poorly aligned between themselves. In the full video the vertical alignment shifts continuously.

I'm certain that the TW9966 is generating embedded sync signals, and I'm reasonably confident that they are the standard Bt.656 signals expected by the imx6, according to the code in ipu_capture.c which configures CSI_CCIR_CODE_1 and _2. (I've also dumped the memory at CSI_CCIR_CODE_1 and _2 and confirmed they are correctly set). The next stage of debugging I'm trying to avoid is to connect a logic analyzer to all 8-bits of the video bus and manually observe the SAV/EAV sequences to be 100% certain of what the TW9966 is generating.

I've seen a few other threads which had "rolling video" issues with the ADV7180, but each seemed to work-around the problem by resetting the capture stream. Any thoughts on how to debug why the imx is failing to lock on to v-sync?

[jwatts]

I've found a work-around the rolling effect by supplying the active size to sensor_data::pix::height and applying the following patch:

diff --git a/drivers/mxc/ipu3/ipu_capture.c b/drivers/mxc/ipu3/ipu_capture.c
index b1d6fb3..3f4d166 100644
--- a/drivers/mxc/ipu3/ipu_capture.c
+++ b/drivers/mxc/ipu3/ipu_capture.c
@@ -139,7 +139,7 @@ ipu_csi_init_interface(struct ipu_soc *ipu, uint16_t width, uint16_t height,
                ipu_csi_write(ipu, csi, 0x40030, CSI_CCIR_CODE_1);
                ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3);
        } else if (cfg_param.clk_mode == IPU_CSI_CLK_MODE_CCIR656_INTERLACED) {
-               if (width == 720 && height == 625) {
+               if (width == 720 && (height == 625 || height == 576)) {
                        /* PAL case */
                        /*
                         * Field0BlankEnd = 0x6, Field0BlankStart = 0x2,
@@ -154,7 +154,7 @@ ipu_csi_init_interface(struct ipu_soc *ipu, uint16_t width, uint16_t height,

                        ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3);

-               } else if (width == 720 && height == 525) {
+               } else if (width == 720 && (height == 525 || height == 480)) {
                        /* NTSC case */
                        /*
                         * Field0BlankEnd = 0x7, Field0BlankStart = 0x3,

This prevents the rolling effect, but the captured frame still includes the blanking region.

[alejandrolozan1]

Hi,

Have you checked that the vsync frequency is the correct one?

/Alejandro

[jwatts]

Yep, both vsync and hsync frequencies are as expected, though I can only check one at a time: The chip I'm using has a multi-purpose pin that may be any one of vsync, hsync, data-valid and a few other useful signals, but they expect you to get your sync signals from the embedded control patterns.

See attached video for an example of my current work-around. In it you can see the blanking region across the top, and while it's not obvious in the image, the bottom is being cut off by an equal amount. It seems to me that the logical vsync value is inverted: it's starting the frame when vsync should be ending, it then records up to the maximum number of lines (this is my work around), then the next frame begins. Every time I restart capture or the entire system, the amount of blanking region captured is precisely the same.