Video delay problem.

I am not aware of such code, but please note that you can pass CCDC data directly to preview engine.  The VPFE User Guide should help point you to the necessary hardware register changes to do this; you have the source code for the video drivers that come with the DM6446 EVM, so once you known which registers need to change (VPFE UG), you should be able to modify drivers yourself to go from CCDC to preview engine directly.

Hi Juan, Thanks for your reply. I have completed the driver code which enables the VPI (video port interface).

Now I am facing a new problem. The video windows is scrolling up start from bottom to top continously. That means the whole vidoe window is sliding up and the hidden upper part are coming from bottom.

Do you have any clue?

Do you have any document which explains the VPI (vidoe port interface) other than VPFE user guide (SPRUE38E)?

video display scrolling up and down normally mean there is a video timing issue.  Perhaps the resolution and blanking registers (HSTART, HSPLS, HVALID..) do not match up, perhaps the pixel clock provided does not match display requirements.  The VPBE UG is the more detailed document we have on video back end port for DM6446.

This is not related to VPBE. I have saved the captured frame into BMP file and saw the scrolled part (top line comes into the middle or inside) on the still image. I have a working version which data path is not using video port interface (VPI).

CCDC ----> DDR ----> PREVIEW ---->DDR----> VPBE

This path works fine. But I saw there is 100 mili-seconds delay from capture to display.

So, I planned to use video port interface (VPI) to reduce the delay. Is it really fast processing if preview engine read input from VPI? How much faster compared to DDR input to preview engine?

I think I need a better understand on VPI. Do you any document which explains VPI other than VPFE UG? How the timing generator inside VPI works? Is it related to VD/HD or it is independent clock? Is preview engine drived by VPI timing clock or is it independent?

Sorry for asking lots of question. But it will give me more comfort.

I know the naming of hardware blocks can make things confusing sometimes.  If you look at Figure 1 on our VPFE UG, you should see that no matter if data is coming from video encoder (TVP5146, CMOS sensor, or anywhere else), the first hardware block it must pass thru is CCDC.  The name is a bit misleading, but this is your general video input port interface; I like the name VPI a little better, but would like it even more if it distiguished between input and ouput as this device has dedicated video input and output ports.  Either way, this is just naming and for all practical purposes, CCDC is your VPI. 

As Figure 6-6 in main data-sheet suggests (also emphaszed in VPFE UG) the VPFE clock can come from either SYSCLK3 (aka CLKDIV3, PLLDIV3) which is internally generated by PLLs from main clock or PCLK pin if you need to provide external clock (e.g. to support a certain video standard, or if external components need to be masters and not slaves).  I like this figure because it shows all the internally generated clocks for the system; for example, this figure also shows one clock for entire VPFE block hence all VPFE hardware blocks (CCDC, preview, resizer... ) share this VPFE clock.

The VPI (aka CCDC) is very flexible, it can act as a master or slave when it comes to pixel clock, hsync, vsync, and field_id.  It lets you support industry video standards such as BT.656 or lets you define your own customer resolution via set of registers.  It lets you write data to DDR2 at various points in the video processing pipeline or keep data in the pipeline to save on DDR bandwidth usage.  It let you easily bypass video processing block along the pipeline if you do not need them.  You should be able to get a good picture of all this flexibility from the VPFE UG.

That said, to answer your questions

0) going from CCDC --> PREVIEW and bypassing DDR2 should save you a little time, but the real benefit is DDR2 bandwidth saving, especially when working with large video resolutions.  If you are doing standard video foramts (e.g. NTSC at 30 fps), then you would not notice any difference in speed of one path versus another as the 30 fps (or 1/30 seconds) is plenty of time for the video frame to pass thru the system no matter what path you choose.

1) VPFE UG is your VPI (aka CCDC) UG + more (resizer, previewer..)

2) Pixel clock can come from CLKDIV3 or PCLK, either can be used along a set of registers (see Figure 8 on VPFE UG) to define video timing when DM6446 is master; optionally, video timing can be input from external device when in slave mode.

3) depends, if DM6446 is master, HD / VD are very dependant on pixel clock.  If DM6446 is slave, then all three would come from master device and hopefully there would be some dependency but DM6446 being the slave cannot gurantee that

4) Preview, bieng part of VPFE uses same pixel clock as rest of VPFE including CCDC (aka VPI)