Clocked Video Input overflows

[Altera_Forum]

It is time to tie my Clocked_Video_Input with my Clocked_Video_Output and just pass an image in and out but, lo and behold, I get an overflow on the CVInput. 

 I have a conceptual block here. I am going from a clocked domain to a flow-controlled domain, and then back again. My CVI is gripin' that it cannot accept data at a rate fast enough, bit I'm hardly overdriving this with a single, composite signal incoming from the Bitec Quad Video card.  Would megafunctions further down the chain cause the CVI to overflow? I would think it would be agnostic to the megafunctions downstream.  Overflow implies to me "too fast a rate" but could it also mean "too many pixels in a frame"? Maybe I have a height and width mismatch?

[Altera_Forum]

Yes the backpressure from downstream functions can cause an overflow. You need to make sure that the combination of video IP clock rate, input data rate, input pixel buffer size, output data rate, and output pixel buffer size are such that an overflow does not occur. 

 Most video standards have a vertical blanking period. If your clocked output is say a few lines ahead of your input data stream, you may be in a situation where the input data stream is pushing data in but the output stream is not using any of it which results in an overflow.  You could try throwing a frame buffer between them.  Jake

[Altera_Forum]

Thanks for the input. I am going from an clocked (NTSC) system to another clocked (NTSC) system, so will almost certainly need a frame buffer. 

 My understanding is that such a system as I am building will need (1) perfectly synchronized clocks on the input and output, something unlikely to happen with this flow-controlled VIP system, or (2) I will need a frame buffer to assist with frame-rate conversion. Correct me if I am wrong.  Question: Must I enable frame dropping and/or frame repeating in the Frame Buffer Megafunction in order to get this benefit? My common sense says, "yes."

[Altera_Forum]

You can certainly use the recovered clock from your video input to clock your output if you have it available. The flow control will not affect the frame rate as long as you don't overflow. In this case your output is synchronous to your input. If this is what you want to do then by all means do it. 

 If you are going to handle asynchronous video, then yes I would recommend enabling both frame dropping and repeating (as you don't know if the input is faster or slower than the output).