OK. This article is flawed and many of the comments are just as flawed. Having been involved in the design and manufacturing of LCD displays (down to writing all FPGA image processing code, scaling, deinterlacing, etc.) I think I can say that none of this is accurate if the intent is to apply it generally.
Caveat: If you buy a TV don't expect it to be a computer monitor. Most TV designs are just that: TV sets. They are made to do one thing reasonably well: Take a crappy satellite/cable/whatever signal and give you a reasonable image back.
EDID can be programmed with any resolution you want. Do you need 921 x 333 at 12 frames per second? No problem. There is no such thing as a resolution not being available in EDID. Standards are one thing, but the EDID mechanism isn't inherently limited by standards.
BTW, there are commercially available EDID modifier gadgets that allow you to modify the EDID readout from the monitor. So, the monitor says one thing and your computer (or whatever device) receives your programmed values.
If you need a TV that will play nice with a computer you need to find one that was explicitly designed to do so.
Most consumer TVs use one of a very few commercially available processor chips to do their image processing. With a few exceptions they all do the same kinds of things. And no, the signals are rarely converted to YCbCr 4:2:2 internally but for the absolute cheapest and crappiest of processors. All the good ones convert the input to a common internal integer RGB format. The nice ones might standardize at 12 bits per channel (36 bits total) internally. When I did custom FPGA video processing we went as far as 24 bits per channel in order to avoid truncation of calculated values until the very last moment. This can make a huge difference depending on the application.
In general terms "monitor mode", if you will, should be a mode that bypasses as much of the internal processing as possible. You can force this bypass by using and EDID modifier gadget programmed for the actual resolution and timings of the panel. In other words, open the back of the TV, get the panel model number, get the data-sheet and program the EDID modifier to output these values to your computer. The processor should push this straight to the panel and you get very little, if any, processing. Again, this does not work on all TVs. As I said before, they are designed to be TVs, not monitors.
That said, I've connected many computers to off-the-shelf, un-modified, consumer TVs via DVI and HDMI. I have yet to run into any real issues.
"EDID can be programmed with any resolution you want"
Indeed, as I said. I then went on to say that lots of 1366x768 devices don't provide a detailed timing block, so they're limited to what you can express in the standard timings - which limits you to horizontal resolutions that are multiples of 8, and so can't express 1366x768.
That's the only thing you appear to disagree with about the article, so "This article is flawed" doesn't seem entirely fair. I'll admit to not being a video expert - I write a lot of code that interfaces with firmware at all levels, including displays, and I work closely with people who are video experts, but I've never built a TV. I don't think I've misrepresented any facts or presented any gross inaccuracies, but where I have made mistakes I'd love to be corrected.
You and the article seem to be talking about two different things. The article is talking about how things are bad by default. You seem to be saying (e.g. with talk about the EDID gadget) that things can be made to work if enough effort is applied. That is scant comfort to someone who writes drivers to interface with televisions, as the author of the blog post seems to.
> I have yet to run into any real issues.
Possibly because of hacks like the one this guy pointed to in Linux?
> Caveat: If you buy a TV don't expect it to be a computer monitor. Most TV designs are just that: TV sets. They are made to do one thing reasonably well: Take a crappy satellite/cable/whatever signal and give you a reasonable image back.
...
> In general terms "monitor mode", if you will, should be a mode that bypasses as much of the internal processing as possible
...
> As I said before, they are designed to be TVs, not monitors.
I think this is 100% the problem. TVs these days essentially are big monitors, and they should be designed as such.
I believe that if a TV is taking content from a digital source (ie, HDMI, DVI, DisplayPort etc.), it should perform the bare minimum image processing possible. Things like scaling and gamma correction are necessary of course, but other operations like sharpening filters just destroy images and are unnecessary for digital inputs, and things like motion interpolation (ie. MotionFlow) are ridiculous (seriously, the only thing it improves is text like rolling credits, but it introduces serious motion artefacts to actual video and does strange things to noise in images, making the image look what I can only describe as 'slushy')...
This is just my opinion from being both an engineer but also having done a lot of film-making and photography work. It just appals me to see the default settings on these TVs degrading the images so much, and it takes a lot of searching through menus to set it to something sensible, which the vast majority of the population won't do...
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 ?
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.
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.
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.
OK. This article is flawed and many of the comments are just as flawed. Having been involved in the design and manufacturing of LCD displays (down to writing all FPGA image processing code, scaling, deinterlacing, etc.) I think I can say that none of this is accurate if the intent is to apply it generally.
Caveat: If you buy a TV don't expect it to be a computer monitor. Most TV designs are just that: TV sets. They are made to do one thing reasonably well: Take a crappy satellite/cable/whatever signal and give you a reasonable image back.
EDID can be programmed with any resolution you want. Do you need 921 x 333 at 12 frames per second? No problem. There is no such thing as a resolution not being available in EDID. Standards are one thing, but the EDID mechanism isn't inherently limited by standards.
BTW, there are commercially available EDID modifier gadgets that allow you to modify the EDID readout from the monitor. So, the monitor says one thing and your computer (or whatever device) receives your programmed values.
If you need a TV that will play nice with a computer you need to find one that was explicitly designed to do so.
Most consumer TVs use one of a very few commercially available processor chips to do their image processing. With a few exceptions they all do the same kinds of things. And no, the signals are rarely converted to YCbCr 4:2:2 internally but for the absolute cheapest and crappiest of processors. All the good ones convert the input to a common internal integer RGB format. The nice ones might standardize at 12 bits per channel (36 bits total) internally. When I did custom FPGA video processing we went as far as 24 bits per channel in order to avoid truncation of calculated values until the very last moment. This can make a huge difference depending on the application.
In general terms "monitor mode", if you will, should be a mode that bypasses as much of the internal processing as possible. You can force this bypass by using and EDID modifier gadget programmed for the actual resolution and timings of the panel. In other words, open the back of the TV, get the panel model number, get the data-sheet and program the EDID modifier to output these values to your computer. The processor should push this straight to the panel and you get very little, if any, processing. Again, this does not work on all TVs. As I said before, they are designed to be TVs, not monitors.
That said, I've connected many computers to off-the-shelf, un-modified, consumer TVs via DVI and HDMI. I have yet to run into any real issues.