4 ms·

Since you say you have been involved in the production of such things I have a question for you.... Many of the comments below discuss how people experience HD

Since you say you have been involved in the production of such things I have a question for you.... Many of the comments below discuss how people experience HDTV "lag", I was wondering if you could shed any light on what causes this. Initially I was thinking that, if its a commodity processor then of course there is the potential for lag, but then you mentioned the FPGA's. Now I am no fool, I know that its going to take time to process things even with an FPGA, but you got me thinking, in the HDTV application surely an FPGA will be coupled with a commercial DSP chip, heck for high volume I am sure the manufacturers will go the whole hog and get the FPGA netlist converted out into an ASIC or even full blown foundry chip. Wouldn't the FPGA coupled with a DSP kill most of the lag outright ? So where in your experience is the lag ?

beambot 15y ago
Many DSP algorithms introduce delay (ie. think about simple FIR digital filters, like a running averager). They are literally using a "tapped delay line" to perform the computation. There is a tradeoff between the amount of delay you're willing to accept and the "sharpness" of your filters' frequency response. I'm not an expert in TV systems, but this gives the general gist.
brigade 15y ago
Rephrasing beambot, some of the algorithms employed use knowledge of the next frame (or two or five) to filter the current frame. So for those it doesn't matter whether you use a FPGA, DSP, ASIC, commodity processor, whatever to do the filtering - you have to wait until you have the needed future frames to even start.
- bowyakka 15y ago
  Ah check that makes perfect sense, so until I invent the turing oracle we are stuck :)
algoshift 15y ago
There are multiple sources of processing delay in a TV image processor. The two main sources are the scaling and de-interlacing blocks. Scaling is pretty benign. A cheap scaler will introduce somewhere in the order of four lines of delay. A more advanced scaler might do 16 or 32 lines. These are lines of video. If we are talking about 1080, then 16 lines is 16/1080th of a frame. In other words, not insignificant for TV applications. The de-interlacing block is where most of the delay comes from. Interlaced video (standard definition, 1080i, etc.) only transmits half the lines per field. This means that the processor has to synthesize the missing pixels in order to have full frames to display. A really cheap de-interlacer can be done with just a few lines of delay. You wouldn't want this as it would introduce bad imaging artifacts. Pretty much all consumer TVs use a method called "motion adaptive de-interlacing" (MADI). There are many implementations of MADI. In general terms you use data from frames before and after the one you want to process in order to detect pixels that have moved. Those that did not move can simply be replicated or averaged into the missing slots. Anything that moved requires different treatment. The key here is that you need to store a couple of frames worth of video before you can start with MADI. That's your two frames of delay (or more). There might be other delays introduced by other subsystems such as the receiver.

beambot 15y ago

Many DSP algorithms introduce delay (ie. think about simple FIR digital filters, like a running averager). They are literally using a "tapped delay line" to perform the computation. There is a tradeoff between the amount of delay you're willing to accept and the "sharpness" of your filters' frequency response. I'm not an expert in TV systems, but this gives the general gist.

brigade 15y ago

Rephrasing beambot, some of the algorithms employed use knowledge of the next frame (or two or five) to filter the current frame. So for those it doesn't matter whether you use a FPGA, DSP, ASIC, commodity processor, whatever to do the filtering - you have to wait until you have the needed future frames to even start.

bowyakka 15y ago
Ah check that makes perfect sense, so until I invent the turing oracle we are stuck :)

algoshift 15y ago

There are multiple sources of processing delay in a TV image processor. The two main sources are the scaling and de-interlacing blocks. Scaling is pretty benign. A cheap scaler will introduce somewhere in the order of four lines of delay. A more advanced scaler might do 16 or 32 lines. These are lines of video. If we are talking about 1080, then 16 lines is 16/1080th of a frame. In other words, not insignificant for TV applications. The de-interlacing block is where most of the delay comes from. Interlaced video (standard definition, 1080i, etc.) only transmits half the lines per field. This means that the processor has to synthesize the missing pixels in order to have full frames to display. A really cheap de-interlacer can be done with just a few lines of delay. You wouldn't want this as it would introduce bad imaging artifacts. Pretty much all consumer TVs use a method called "motion adaptive de-interlacing" (MADI). There are many implementations of MADI. In general terms you use data from frames before and after the one you want to process in order to detect pixels that have moved. Those that did not move can simply be replicated or averaged into the missing slots. Anything that moved requires different treatment. The key here is that you need to store a couple of frames worth of video before you can start with MADI. That's your two frames of delay (or more). There might be other delays introduced by other subsystems such as the receiver.