5 ms·

Right. One of the rules is "be nice". OK. This article is flawed and many of the comments are just as flawed. Having been involved in the design and manufac

Right. One of the rules is "be nice". 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.

mjg59 15y ago
"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.
brigade 15y ago
> And no, the signals are rarely converted to YCbCr 4:2:2 internally but for the absolute cheapest and crappiest of processors. Tell that to Sony, Samsung, LG, etc. who all do it by default (outside of game/PC modes) across most (all?) of their lineup nowadays. Or are you implying that my HX909 uses the absolute cheapest and crappiest of processors?
jamesaguilar 15y ago
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?
bowyakka 15y ago
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 ?

mjg59 15y ago

"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.

brigade 15y ago

> And no, the signals are rarely converted to YCbCr 4:2:2 internally but for the absolute cheapest and crappiest of processors. Tell that to Sony, Samsung, LG, etc. who all do it by default (outside of game/PC modes) across most (all?) of their lineup nowadays. Or are you implying that my HX909 uses the absolute cheapest and crappiest of processors?

jamesaguilar 15y ago

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?

bowyakka 15y ago

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 ?