Video overlay

If final output is PAL format video

First check if the outputs of the embedded board can provide

1/ S-video at PAL frequencies or VGA output at PAL frequencies 2/ Outputs are true PAL INTERLACED video format 3/ Active picture resolution 768 x 576 with correct half-lining. 4/ You have access to an interlaced font

Once you have that you can add external hardware to mix the video streams once you have them in sync.

If a channel like Blue is to be used for transparent colour, you are NOT colour keying with a transparent colour but using that colour chnnel as a wipe key.

If the final output is the embedded screen output you need to add a frame grabber, that can stream the video at the correct rate to keep up with the camera. Then you do the OSD in software and possibly with assistance of the embedded graphics controller. this also has to take account of the different frame rates.

Which method depends on what type of monitor you intend to display the picture on.

That depends on which is final output as standard PAL camera is

768 x 576 INTERLACED.

An alpha channel greater than 4 bits for OSD keying is more than required. If you must have true colour for your overlay then it needs at least a 1 bit alpha channel or external detection for the colour(s) to use as transparent colour for chroma keying.

I suggest you do some research on video formats first.

You could of course always hire me to do the job having done many video designs over the years.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

I'm not sure why you think you need to do that. Finding the appropriate hardware is the first thing you need to do.

KISS and start with one of these:

Once you understand what you are doing with that, then move on to a higher level of overlay.

--
John B

The first fundamental problem you need to address is the fact that your two sources have different frame formats and probably different frame rates.

You also need to decide what the output format and frame rate is going to be. If this choice matches one of the sources, then this will dictate on which input you need to do frame format and rate conversion in order to match the other.

I once designed a video telestration system, but in that system, the output format was identical to the live video input format (NTSC, PAL, SECAM, VGA or DVI), and the embedded processor had direct access to a video graphics buffer that had the same frame format as the currently selected video signal. I used a midrange Xilinx FPGA to handle all of the real-time video signal processing, and a pair of external DDR SDRAM chips to hold the video and graphics frame buffers.

If you're just doing a one-off project, there are many FPGA evaluation boards, especially those intended to show of "multimedia" applications, that have all the necessary memory and interface hardware to do what you want, but you'll have to develop most of the FPGA logic from scratch.

-- Dave Tweed

Marco Trapanese ha scritto:

I'm sorry for the long delay, but I was very busy. I read all your answers and I'll investigate on key points you talked about.

I thank you all and I'll write again when the specs will be correctly defined.

Marco