Hacker News Reader

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

> 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?

> 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 ?

So where in your experience is the lag ?

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.

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

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.

> If you need a TV that will play nice with a computer you need to find one that was explicitly designed to do so.

Any suggestions?