Capturing image from live NTSC stream

[tonyfai]

Hi there! This is my first time posting here. A brief introduction of myself: an EE undergraduate struggling hard to learn about electronics and engineering. It would be grateful if all the experts here can give some advices or directions on the problems I have.

Currently I am working on a memory circuit that saves a field or a frame image from a live NTSC stream and displays back onto a monitor. System flowchart is as below:
Live video --> Anti-aliasing filter --> A/D, 8-bits --> Memory --> D/A, 8-bits --> Reconstruction filters --> Video output on monitor

The memories used are four 2Mb 8-bits FIFO field memory which each can save 1 field of NTSC image. The write and read operations of the memories are controlled by a CPLD programmed in VHDL. In order to maximize the number of saved images and simplify the circuit, I decided to directly digitize the composite NTSC signal. Hence, 4 field images or 2 frame images can be saved at most. A/D, D/A, CPLD and the memories use the same clock, which is 4x the colour subcarrier frequency in NTSC.(14.318MHz)

The major problem now is that the colour in images are screwed up completely. Red appears as bright pink or violet, blue appears green etc. I found that the period of reconstructed NTSC signals is always a tiny bit shorter from the NTSC standard. I couldn't understand if this is the reason for the colour distortion because I thought colour is related to the phase between the video signal to the colour burst, not timing. Can someone please suggest the reason for it?

Another problem is that I just couldn't figure out a method in VHDL to control the timing to write to and read from memories so that a NTSC signal with standard period can be recreated. Please show me some ideas or advices on it..

Sorry for such a lengthy post. I have researched and worked on it by myself for a long time but just can't solve it on my own. I guess I am missing some knowledge...... If there is anything unclear, please bring it up and I will clarify asap.

Thank you very much for your patience!!

 

[ronsimpson]

Tonyfai,

I used something like the ADV7180 to convert the video to RGB or YCrCb (8/10 bit digital) then into the FPGA.

On the DAC end I used Analog Devices DAC to take the YCrCb back to analog.
OR
I used a simple DAC to make the video + sync + Color. The timing is harder!

WRONG COLOR VIDEO
The old method: Sync to the color frequency. The (phase of video) and (color frequency) = color.
New method: Do not look at the color frequency. At the back edge of H. sync start counting (start color oscillator). Tie color phase back to H. sync.

If color is wrong phase shift until the color is correct.

 

[tonyfai]

thanks for the reply, Ronsimpson
My global clock is 4x the color frequency, does that mean it is sync to the color frequency? As I am directly reading out from the memory, it doesn't seem to be possible to adjust the phase shift...
so is it fine for the period of the reconstructed signal to be slightly longer or shorter?

 

[Nigel Goodwin]

As suggested, don't mess with the colour signal - decode the NTSC to RGB and digitise that - if you need to output an NTSC signal, use an encoder to convert back from RGB to NTSC. As the colour is governed by the phase of the signal, it means you otherwise have to keep the phase exactly correct.

 

[ronsimpson]

TonyFai

Nigel is right. There are ICs that solve this problem. Output from the FPGA parallel video (RGB) at 4X and the IC gives you good video.

If you have to make color by phase shifting: My memory is not good but I think I updated the DAC 16 x (color burst) and got 16 different colors. This is good for color text but not good for live video. Taking this idea farther; Run the output of the FPGA at (64 x color) or the max clock for you logic. At 100mhz you could phase shift 10nS or 5nS if you shift off both clock edges. Update the DAC at 4X like now but add 10nS phase shift as to when the DAC gets updated.

The first time I did this I used a string of MC14XXX CMOS buffers as a phase shifter. It worked but was not temperature stable.

 

[tonyfai]

thank you, Nigel and Ronsimpson!
The phase shift idea opens my eye, I feel more ignorant in this world of electronics now haha

I shall start at converting the video to YCrCb as RGB will require more memory storage if I understand correctly.

 

[ronsimpson]

TonyFai

Your comment about memory storage makes me asks questions.
How are you storing video now? What sampling rate 14mhz?
How would you store YCrCb? What sampling rate?
How would you store RGB? What sampling rate?

 

[tonyfai]

The sampling clock is 14.318 MHz, 4x the color frequency. I use the positive edge of vertical sync from LM1881 to reset the memory's write address to zero and let the sampling does its work until the next positive edge of vertical sync. However, the amplitude of the colour burst after D/A is almost half of the original. I suspect that it's because the video signal before A/D has become out of phase with the sampling clock, but I don't know to test on that.

For YCrCb, as long as sampling rate is 4x colour frequency and the decoder outputs 8-bits eg 4:2:2, it should require the same amount of memory space as what I am doing now. And for RGB, the memory required should be tripled. Am I correct?

btw, what i trying to build is commonly known as 'video digitizer' or 'frame grabber', but I just found out yesterday. foolish me

 

[Nigel Goodwin]

The sampling clock is 14.318 MHz, 4x the color frequency. I use the positive edge of vertical sync from LM1881 to reset the memory's write address to zero and let the sampling does its work until the next positive edge of vertical sync. However, the amplitude of the colour burst after D/A is almost half of the original. I suspect that it's because the video signal before A/D has become out of phase with the sampling clock, but I don't know to test on that.

For YCrCb, as long as sampling rate is 4x colour frequency and the decoder outputs 8-bits eg 4:2:2, it should require the same amount of memory space as what I am doing now. And for RGB, the memory required should be tripled. Am I correct?

btw, what i trying to build is commonly known as 'video digitizer' or 'frame grabber', but I just found out yesterday. foolish me

As you've perhaps since found out?, such devices are cheap and commonplace, often having a TV tuner included as well - if you check for a few examples you will find that they all seem to use the same specific IC for the digitising - it may be a good idea to check that out?.

However, I presume this is for a university project?, and not a desire for a digitiser?, so you probably need to be doing it using old basic principles?.

 

[ronsimpson]

Are you capturing video 4:2:2 where all the information is stored in 8 bits?

I normally use RGB 24 bit (8:8:8). Or (Y 8 bit, Cb 8, Cr 8) or (Y8,Cb8,Y8,Cr8)
For TV applications we often run 9 or 10 bit.
You will learn much by looking at the TVP5160 data sheet. Look for other video decoders.

See SAA7111 and TVP5160

 

[tonyfai]

Thank again for the input, Nigel and Ronsimpson
Unfortunately, this is a circuit in a real product, so I use the chips available and try to keep it basic like theories since I don't have much experiences. The requirement is to save as much images as possible and image quality can be compromised, but colour should be right at least.

I found a website that is quite close to what I am doing:
http://www.techmind.org/vd/vidmk2.html
In the product bulletin of the TVP5160, it said 'sampling is line locked for correct pixel alignment'. How does 'line lock' work? Is it better than synchronize to VSync for writing to memory?