Question about YPrPb video, Video decoder (ADV7183B), etc

[FusionITR]

I know I brought this up before (if you guys remember) but I have some questions regarding video decoding YPrPb (component) video.

I will be using the ADV7183B (datasheet attached) to decode component video up to 480p resolution for digital processing (scaling/filtering/etc). The ADV7183B will be the front end for this.

This is the first time I am using a video decoder so bare with me. I am pouring through the datasheet and I don't see anything about the maximum signal bandwidth that the decoder can handle. It just says SDTV video decoder so I'm not sure it can do 480p but I don't see where they clearly defined the bandwidth. SDTV is 480i, I know that, but does that mean 480i is the max resolution it can handle?

Another question, for the digital outputs, how do I calculate the "bandwidth" and "speed" needed to store and process each frame? So I can pick an appropriate processor for the digital processing and I can pick an appropriate speed ADC after the DSP.

Any other corners I need to consider?

The first thing I plan to get working is Decoder (front end) -> DSP -> ADC/Encoder, but have the DSP not do any processing (A = B for all bits) and see if I can get that working.

 

[crutschow]

That's a very complex chip. You've taken on quite a task to use it.

The data sheet states all the standard video formats it can handle, so it may not work with a 480p non-standard signal.

The A/D conversion rate is 54MS/s with a 4X oversample implies a 6.75MHz upper limit on the analog signals it can process.

According to Table7, the digital pixel data output rate is 27MHz.

As to the processor speed you need, that's a difficult question which depends upon how much processing you do on each frame. But it likely will need to be very fast.

 

[FusionITR]

I know it's complex and I am reading to spend a few months (at least) developing this product.

Any definition of what a "non-standard" signal is? For example, I'm sure any video coming out of a DVD player would be a standard signal, but what about video game consoles, computers (running at 640x480), etc? Any signal that will display on a NTSC TV? I'm almost sure any 480i signal would work, my only concern is 480p.

How did you get the upper limit of 6.74MHz from the 54MS/s with 4x oversample?

Say, for example, I wanted to feed in 480i signal. What is the proper way to calculate the require bandwidth in relation to the sampling bandwidth of the front end (the AD7183B)?

Lets forget the processor for now, lets just clearly define the input.

 

[crutschow]

Any definition of what a "non-standard" signal is? For example, I'm sure any video coming out of a DVD player would be a standard signal, but what about video game consoles, computers (running at 640x480), etc? Any signal that will display on a NTSC TV? I'm almost sure any 480i signal would work, my only concern is 480p.

Since 480p is not a standard NTSC signal, it's unknown if or how it would work. You might try contacting Analog Devices about that. Any signal that will display on an NTSC, PAL, or SECAM TV should work.

How did you get the upper limit of 6.74MHz from the 54MS/s with 4x oversample?

I make an error on that. The minimum Nyquist sample rate is 2x. For a 4x oversample rate the maximum input signal would be 54/4 = 13.5MHz.

Say, for example, I wanted to feed in 480i signal. What is the proper way to calculate the require bandwidth in relation to the sampling bandwidth of the front end (the AD7183B)?

For a 640 x 480i picture, the active horizontal scan time is about 50µs to display the 640 vertical pixel lines. Since it takes 2 lines to make one signal cycle, the maximum video data rate is 320/50µs =6.4MHz. Thus you would be oversampling the input video frequency by a factor of 8.

 

[smanches]

NTSC is 720x486 technically because of the pixel aspect ratio of old TVs. Make sure you take that into account.

 

[FusionITR]

Since 480p is not a standard NTSC signal, it's unknown if or how it would work. You might try contacting Analog Devices about that. Any signal that will display on an NTSC, PAL, or SECAM TV should work.

I see. Actually after pouring over the datasheet in detail last night I noticed that it does support "EDTV", or at least it has some registers to detect an EDTV signal from what I can read, so I am assuming it can decode it. EDTV is 480p, so it's safe to assume it can decode this, correct?

I make an error on that. The minimum Nyquist sample rate is 2x. For a 4x oversample rate the maximum input signal would be 54/4 = 13.5MHz.

Cool, thats what I thought. 720x480x60 (480p) seems to have a pixel bandwidth of 20.7MHz if you multiply it out, or am I not doing the math right? Or is pixel bandwidth not what I need to be looking at for the speed of the decoder?

For a 640 x 480i picture, the active horizontal scan time is about 50µs to display the 640 vertical pixel lines. Since it takes 2 lines to make one signal cycle, the maximum video data rate is 320/50µs =6.4MHz. Thus you would be oversampling the input video frequency by a factor of 8.

How did you get 50us to display one lines?

 

[FusionITR]

BTW, another related question, do you have any links on a good tutorial for I2C bus communication protocol? I have never used it but have used other serial protocols so I'm not exactly a beginner but I am unfamiliar with the I2C bus.

 

[crutschow]

720x480x60 (480p) seems to have a pixel bandwidth of 20.7MHz if you multiply it out, or am I not doing the math right? Or is pixel bandwidth not what I need to be looking at for the speed of the decoder?

The maximum pixel rate (not bandwidth) is actually somewhat higher than that if you subtract out the vertical and horizontal blanking intervals during which no signal is sent. The video bandwidth is roughly half the pixel rate since it takes two pixels to make a cycle. I believe the decoder is rated for video bandwidth, not pixel rate.

How did you get 50us to display one lines?

The NTSC horizontal line frequency is 30 * 525 = 15.75KHz for a line period of 63.5µs. The horizontal retrace blanking interval is about 11.5µs leaving 52µs for the scan time which I rounded to 50µs.

 

[smanches]

Nevermind. Just realized you're talking total lines, not just visible.

 

[FusionITR]

Nevermind about the I2C protocal. I just looked at a tutorial on the internet and the protocal is pretty damn simple. Way simplier than other serial protocals ive worked with.

With that said, I have a question about I2C.

Some microcontrollers, from what I can tell, come with I2C protocals built in. What exactly does this mean? I can easily write I2C functions in assembly, but do some microcontrollers have pre-defined I2C relatied instructions or something?

 

[crutschow]

Some microcontrollers, from what I can tell, come with I2C protocals built in. What exactly does this mean? I can easily write I2C functions in assembly, but do some microcontrollers have pre-defined I2C relatied instructions or something?

I believe they have the handshake protocols built in so all you have to do is tell the µC to send data and the handshake is done automatically.

 

[FusionITR]

Sweet I'll look into that, thanks!

I'll be stopping by again for more questions later after I finish going over the datasheet.

 

[FusionITR]

It looks like the cheapest pic that can do I2C is $1.82 vs a PIC10F200 which is $0.58 and I can write the I2C protocol myself very simply. Huge savings for every little benefit. I don't see what the point is. I'll be using the 10F200.

 

[smanches]

What would you be using a PIC10 and I2C for? Just control signals to the other components? I2C won't have anywhere close to the bandwidth for data; I think it's limited to 800Khz or so.

This system is most likely going to need an FPGA to be able to do any sort of real manipulation of the data.

 

[Nigel Goodwin]

What would you be using a PIC10 and I2C for? Just control signals to the other components? I2C won't have anywhere close to the bandwidth for data; I think it's limited to 800Khz or so.

I2C isn't for data, it's for setting the chips up - so no great bandwidth needed.

 

[Sceadwian]

The range for smbus (typical implemenation of I²C) is 10-100khz. I²C itself goes up to 400khz, which is 50kbytes a second. Respectable for data transfer, not great though, and not what it's really designed for.