AnsweredAssumed Answered

Rolling video on i.mx6

Question asked by Andrew Murray on Feb 20, 2017
Latest reply on Feb 23, 2017 by igorpadykov

I'm experiencing an issue with the i.MX6 where an 'interruption' to a video source results in the display/capture of 'rolling video'. This is where each frame of the captured video contains a portion of one frame and a portion of the next frame. The split between the two frames gradually changes, such that it can take several seconds for the split to reach the bottom of the screen. In the worse case the video will roll to the bottom of the screen twice before going back to normal.


The interruption can come from the analogue (parallel bt.656 embedded syncs) signal being removed and restored. It can come from the TVP video encoder settings being changed (e.g. changing video source, or turning on its power save feature) - it can also occur by enabling and disabling the IPU/CSI test generator (IPUx_CSI0_TEST_CTRL bit 24, e.g. devmem2 0x02630010 w 0x1000000 && devmem 0x02630010 w 0x0).


Changing the value of active_top (video crop) in mxv_v4l2_capture.c can change how fast the rolling occurs - set at a specific value, (e.g. 4) - will make it not roll, but upon interruption of video source the video will contain a portion of one frame and the next - this portion will be fixed (i.e. the video never recovers). It's not clear to me what is going on here.


The only way I've been able to overcome this is to detect loss of signal in the TVP and then restart part of the video system (e.g. call enc_disable_csi and enc_disable and then the reverse)- i.e. equivalent to VIDIOC_STREAMOFF and VIDIOC_STREAMON. This isn't ideal, and sometimes despite this workaround, the video will still roll. (It's as if the TVP doesn't detect all instances of loss of signal, or the reset doesn't have the desired effect in each instance).


My understanding is that whilst the CSI module can detect partial frames arriving from the encoder and use the embedded syncs to re-sync - the other parts of the video system in the i.MX6 are not aware of this and don't resync - leaving partial buffers floating around in the IDMAC resulting in the rolling video. Is this correct?


I'm aware that there is a 'start of frame before end of last' event - however this doesn't always fire when the system is out of sync, and when it does the timing of it seems a little too late.


Is there any way to detect when this rolling occurs - other than relying on the TVP? (I.e. to identify when the CSI module gets a partial frame or similar?).


Is there any way to prevent the IDMAC from losing sync?


What is the right sequence of events that should be used to reset the IDMAC state once it's out of sync?


Are there any other solutions?