Questions about video dacs/digital modification

[FusionITR]

I don't know if this is even the appropriated place to ask this as this might be too advanced for this board...

Say, for standard rgb video where I wanted to take input video, modify it in the digital domain, then send it back out as rgb, I would think to have a scheme like this:

3 Input Signal -> 3 ADC -> 1 Digital Processor -> 3 DACs -> 3 Opamp Buffer

Now, for the first obvious question, is there a more cost effective/efficient way to do this other than 3 ADCs/3 DACS/3 buffers? That's already a lot of money and I assume most video devices that do video processing don't use this scheme, what is the standard scheme to use?

Next question, for the digital processor, when you do your video processing, say I wanted to add a small 50% transparent box in the center of the screen on top of the video, do I need to modify the video line by line, or would it to be better to store the entire frame, modify it, then send out the entire frame? I would assume line by line (or even pixel by pixel) would be the fastest method.

Next is the speed, based off the resolution I want (720x480), what speeds to I need to be looking for in the ADCs/digital processors/dacs?

Also, what type of digital processors are good/cost efficient for digital video? The only pure digital devices Ive used are PICs and I assume they are not sufficient for digital video.

 

[blueroomelectronics]

What is the source of the RGB signal?

 

[FusionITR]

What is the source of the RGB signal?

Generic rgb input of either 240p/480i/480p.

 

[crutschow]

The do indeed use high speed A/D's and D/A's to convert video. There's no other way if you want to modify the signal in the digital domain.

The conversion rate needs to be at least as fast as the video pixel rate (60 x 720 x 480) = 20.7 MS/s with usually at least 10-bit resolution. A example device that has multiple channels of video A/D and D/A in one chip is ADV7202 | 10-bit Raw Video Rate CODEC featuring Simultaneous Sampling | Video CODECs | Audio/Video Products | Analog Devices.

Obviously for that bit rate you will need a very high speed digital processor to add your overlay box. I would think line-by-line modification would be the easiest.

Depending upon what you want in the overlay box you may be able to do it all in analog, the old fashioned way, which likely would be simpler.

 

[blueroomelectronics]

What's generating the generic RGB signal?

 

[FusionITR]

The do indeed use high speed A/D's and D/A's to convert video. There's no other way if you want to modify the signal in the digital domain.

The conversion rate needs to be at least as fast as the video pixel rate (60 x 720 x 480) = 20.7 MSP with usually at least 10-bit resolution. A example device that has multiple channels of video A/D and D/A in one chip is ADV7202 | 10-bit Raw Video Rate CODEC featuring Simultaneous Sampling | Video CODECs | Audio/Video Products | Analog Devices.

Obviously for that bit rate you will need a very high speed digital processor to add your overlay box. I would think line-by-line modification would be the easiest.

Depending upon what you want in the overlay box you may be able to do it all in analog, the old fashioned way, which likely would be simpler.

Wow thanks for the info. So I would use this IC for both the A/D and D/A with a processor in between? Also, for my other question, what kind of processor is good for video? Other than high speed ones?

I was thinking about keeping everything in the analog domain but this would be a good opportunity to get some experience with DACs, ADCs, and digital processing.

I looked up that IC on digikey and it said out of stock with a minimum ordering quantity of 32 (ouch), do you know if any places that sells them in single quantity?

Also, how would the clocking work? Does the clocking of the ADC/DAC have to be in sync with the clock for the digital processor?

 

[FusionITR]

What's generating the generic RGB signal?

The point of me saying "generic" is that it could be coming from any device that outputs standard 0.7Vpp RGB + csync/hvsync.

 

[crutschow]

Working with 20MSP A/D's and high speed processing will likely give you more experience than you want. Maintaining the signal integrity of such high speed signals requires very careful signal layout and routing using transmission lines with groundplanes and good power decoupling. Not for the faint of heart. And a high speed digital oscilloscope is a must for testing.

Yes the processor and ADC/DAC will need to be synced to the same clock.

Don't know what's available in high speed processors. Likely a "digital signal processor" microprocessor would be the most appropriate.

You might contact Analog Devices about availability, or possibly even a sample device.

 

[blueroomelectronics]

If you're worried about the cost you can't afford it

 

[FusionITR]

Working with 20MSP A/D's and high speed processing will likely give you more experience than you want. Maintaining the signal integrity of such high speed signals requires very careful signal layout and routing using transmission lines with groundplanes and good power decoupling. Not for the faint of heart. And a high speed digital oscilloscope is a must for testing.

Yes the processor and ADC/DAC will need to be synced to the same clock.

Don't know what's available in high speed processors. Likely a "digital signal processor" microprocessor would be the most appropriate.

You might contact Analog Devices about availability, or possibly even a sample device.

I'm actually an electrical engineer (pure analog though) so there is no such thing as "too much experience" ;-)

I know basic layout principles but I wouldn't see why it would be a big deal. I've routed component signals that run at 640x480 no problem on a 2 layer PCB. As for the high speed digital o-scope, I have a pretty crappy one but it will have to do for now.

I think this project is right up my alley though.

 

[crutschow]

I think this project is right up my alley though.

Then by all means, go for it.

But don't say I didn't warn you.

 

[FusionITR]

Then by all means, go for it.

But don't say I didn't warn you.

Would something like this work?

https://www.electro-tech-online.com/custompdfs/2009/09/39564C.pdf

It's a PIC microcontroller, I know it's not a legit microprocessor or PLD but the reason why I want to use a PIC is because I already know PIC asm pretty well and I've already done a few projects using their simulation software.

It would save me a lot of trouble.

 

[blueroomelectronics]

Thats an old 18F452, its 18F4520 replacement is better. The A/D is only about 30kHz in single channel mode.

Each A/D will have to convert at 640x480x60Hz = 18,452,000

 

[FusionITR]

Thats an old 18F452, its 18F4520 replacement is better. The A/D is only about 30kHz in single channel mode.

Each A/D will have to convert at 640x480x60Hz = 18,452,000

I don't need it for A/D, I'm just using it for DSP. Is the newer one sufficient for that?

 

[blueroomelectronics]

Use a dsPIC for DSP. ie: 30F or 33F series.

 

[FusionITR]

Use a dsPIC for DSP. ie: 30F or 33F series.

Cool, so is 40MIPs enough for 720x480x60 video? If I'm clocking in the video scanline by scanline.

 

[blueroomelectronics]

Well do the math, that's ~20 million data points per second at 60Hz the 40MIPs is far to slow to do anything with the data.

What A/D did you find that converts that fast cheap?

 

[crutschow]

I think you may need to do the data manipulation in some external high speed digital circuits (adders, subtracters, etc.) and use the µC to control the circuits and the data input.

 

[FusionITR]

Well do the math, that's ~20 million data points per second at 60Hz the 40MIPs is far to slow to do anything with the data.

What A/D did you find that converts that fast cheap?

Well...

If I do *nothing* with the data, meaning for every bit i do A = B. Thats over double the speed I need.

If I do some preprocessing, then use the final value A=B just to pass the digital data along to the dac, then I'll be fine, right?

Meaning, I take in a scan line, store the scan line in memory, process the data, then send out the data at 20Mbps, why would I need it to function any faster?

Or maybe I'm not think about this correctly.

 

[blueroomelectronics]

That's alot of bits to store even for a 640x480 screen. PICs don't have that kind of internal RAM.