Video overlay questions

[JVR]

Hi Gents,

I'm working on a project where I need to overlay some info on a VGA video stream. And I'm struggling to get my head around the speed and memory constraints needed to do this. The design will have to cope with a 1080p video stream. According to this link, the pixels are coming in at ~200Mhz.

Now this is where it all goes a bit pear shaped in my analysis paralysis brain, I have two idea's:

1:
FPGA: Hang a 2Mx32Bit memory off the FPGA, whilst sampling the incoming stream via a Analog Devices ADV7604 ADC at 8bits. The problem is, the fastest SRAM I can find is 250Mhz (I can run up to a Spatan 6 with my license, so I don think DDR will be easily done) So getting the frame into RAM is easy enough, getting it out to the DAC's again seems impossible, as I dont think there is processing time left to get the image out of RAM again after modifying it.

2:
FPGA: No external RAM, take the samples in via the ADV7604, and keep internal count of what pixel we are at, then modify in real time as they are sampled and send out to the DAC again.

3:
FPGA: No external RAM, Hang the FPGA in parallel with the VGA signals, figure out the position of the pixel clock from the Hsync and Vsync pulses, and modify the pixels we want to modify live by messing with the voltages. Its dirty, but its easy.


I'm thinking 3 would be the easiest to get up an running, and with the least hardware needed, but I'm not well enough versed in FPGA limitations to know if the FPGA will be able to sample, modify and then write the pixels at 200Mhz+ and not drop pixels. I also doubt this would be possible with a uC, as the clock speeds are too high.

Am I missing anything that I should be thinking about? Is there another method to do this? Please discuss and help a brother, as my uC background is somewhat useless here.

Thanks!
JVR

[rob77]

i would vote for #3 - it's the most simple and therefore the right way to do it
another option would be to look after some existing overlay processors.

[emusan]

3:
FPGA: No external RAM, Hang the FPGA in parallel with the VGA signals, figure out the position of the pixel clock from the Hsync and Vsync pulses, and modify the pixels we want to modify live by messing with the voltages. Its dirty, but its easy.

You may be interested in taking a look at Bunnies NeTV project. His used a similar method to inject an overlay into an hdmi video stream I believe (though for him it was necessary to use this method due to the copy protection embedded in many hdmi appliances, which you wouldn't have to deal with).

[marshallh]

Just sample the pixels along with the sync information and run them through a long register delay line.
Mux this with your actual font/OSD generator.
Then run the same signal to the DAC.
This will work as long as your source and sink are not forced to sync to a common source.

Here is an example of a font OSD i did. It is only 5-6 cycles long in the pipeline. If you can set it up to "work ahead" of the inpt sync you can ditch the delay altogether.

[JVR]

Hmmm, I think I'll start with the #3 dirty approach and see what I can get working while I wait for the video DAC's to arrive.

Marshall, do you have any project info or a link to what you did there? Any info I can mine through will be helpfull at the moment.

[JVR]

It needs to be an overlay, with the option of opacity at some stage.

The hardest part is synchronizing your clock to the video signal.

Would one have to do this? And if so, will it need a seperate PLL to lock onto? Also, do you lock on Hsync i presume?

[mamalala]

It needs to be an overlay, with the option of opacity at some stage.

The hardest part is synchronizing your clock to the video signal.

Would one have to do this? And if so, will it need a seperate PLL to lock onto? Also, do you lock on Hsync i presume?

It depends. If you can live with a tiny amount of skew in the overlaid graphics/text, then you don't need a PLL. If you want to be pixel-exact, however, then you need one. This is assuming a purely analogue signal, of course.

Greetings,

Chris

[JVR]

Thanks Chris.

I'd like to get this pixel correct, but alas time and money will decide the en of that.  Would it suffice to detect the Hsync pulses and "restart" the counters in the FPGA everytime it is seen? Or will this still introduce skew due to the small difference between the FPGA internal clock and the clock of the video source?

[mamalala]

Thanks Chris.

I'd like to get this pixel correct, but alas time and money will decide the en of that.  Would it suffice to detect the Hsync pulses and "restart" the counters in the FPGA everytime it is seen? Or will this still introduce skew due to the small difference between the FPGA internal clock and the clock of the video source?

It will be jagged, unless the two clocks are in sync (clock for the VGA signal and the internal clock of the FPGA). Of course, the faster the FPGA clock, compared to the VGA clock, the lesser the effect will be. But it won't be perfect. Attached is an image of a crosshair-overlay that i did to aid me with drilling PCB's. You can see that the vertical line appears jagged (it is, on overall, straight vertical. The tilt it seems to have comes from the camera angle). This was done using a rather slow running PIC micro, so the effect is rather pronounced.

Greetings,

Chris

[Alex Eisenhut]

Just sample the pixels along with the sync information and run them through a long register delay line.
Mux this with your actual font/OSD generator.
Then run the same signal to the DAC.
This will work as long as your source and sink are not forced to sync to a common source.

Here is an example of a font OSD i did. It is only 5-6 cycles long in the pipeline. If you can set it up to "work ahead" of the inpt sync you can ditch the delay altogether.

Impressive. Several years ago I built a scan doubler for old-school CGA-style RGBI and the AL250 chip had a OSD function built-in.
I got a up-scanned display to work but the pixel clock was too noisy (ie wavering pixels) and I never got the stupid LUT for color mapping to work (always purple and green colors), so I never got to the OSD. I still have the board though, might have to power it up again.

Is your OSD part of an upscaler?

[Alex Eisenhut]

Impressive. Several years ago I built a scan doubler for old-school CGA-style RGBI and the AL250 chip had a OSD function built-in.
I got a up-scanned display to work but the pixel clock was too noisy (ie wavering pixels) and I never got the stupid LUT for color mapping to work (always purple and green colors), so I never got to the OSD. I still have the board though, might have to power it up again.

Is your OSD part of an upscaler?

Hmm, I guess it's this
http://retroactive.be/tech_n64_hdmi.php
?