AnsweredAssumed Answered

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

Question asked by Josh Watts on Mar 24, 2015
Latest reply on Apr 7, 2015 by Josh Watts

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?

Attachments

Outcomes