View Full Version : blur question


greenjp
04-13-09, 08:19 AM
I was at my uncle's watching the Master's on his new TV, a 46" Samsung LCD, the A550 model I believe. Glossy screen, 60 Hz.

The brightness and sharpness of the picture has a certain appealing quality, but I was really struck by what appeared to be severe blurring/smearing on camera pans & zooms. In any scenes of a player walking the course, or tracking a ball rolling across the greens, the details in the grass seemed to vanish into a blur, only to snap back into "focus" when the camera stopped.

The strangest effect was on zooms, as you'd see when a ball was rolling towards the cup. The center of the zoom would stay sharp but everything around it would blur. The effect was startling. Never experienced anything like that on my 50PX77U plasma.

So is this run-of-the-mill LCD blur being emphasized by worst case scenerio content? I watch 24 from time to time on my neighbor's 52" A550 and never noticed anything this severe.

Please refrain from the following:
telling me to tell my uncle he should have gotten a Kuro
telling me to tell my uncle he should have gotten a 120 Hz A650
telling me that "LCD sux"
calling me a plasma fanboi
:p

jeff

Jeffs386
04-13-09, 01:32 PM
Please refrain from the following:
telling me to tell my uncle he should have gotten a Kuro
telling me to tell my uncle he should have gotten a 120 Hz A650
telling me that "LCD sux"
calling me a plasma fanboi


your answer is above

NuSoardGraphite
04-14-09, 03:26 PM
I'm no expert, but it seems to me that LCD Blur is worse when it is trying to upscale images to its native resolution. Thus if you were watching a 720p broadcast on a 1080p TV, the blur would be worse.

I've noticed this on my tv recently. When I first got my TV home and hooked up the HD cable, the box wasn't set up properly and all channels came in at 1080i. I've recently reset the box and programmed it to accept all resolutions, so now some HD channels are 720p, some are 1080i. The channels that come in at 720p have far worse motion blur than the one's coming in at 1080i. That could be the issue.

I do't get much blur with 480 content (480i on cable, 480p with my DVD player). So far a tiny bit with 1080i cable and significantly more with 720p cable tv.

Anyone else experience this issue?

Gary McCoy
04-14-09, 08:06 PM
The blurring and smearing in a camera pan is not a fault in the HDTV, rather it represents a flaw in the ATSC video standard that is seen worst on 720p broadcasts which have higher data rates than 1080i broadcasts.

720p has a resolution of 1280X720 and broadcasts 60 frames/sec. That is an uncompressed data rate of (1280x720x60) or 55.3Mbit/sec. After compression by the MPEG2 codec, the signal must fit within the 19.39Mbit/sec allowed by the ATSC channel bandwidth.

In a slowly moving image or a static image with smaller moving objects this is not an issue. However with a camera pan, every pixel on the screen changes for every frame - the data compression efficiency drops under these conditions and the result is "macro-blocking" which you see as blur.

In practice the problem is much worsened by stations which choose to steal bits from the main image to run subchannels with advertising, weather reports, or infomercials. The less bandwidth available for the live image, the greater the chance of blurring during camera pans.

The only comforting thing is that you could have spent over twice as much money on a Pioneer Elite Kuro HDTV and it would not have helped the tiniest bit when the blur is present in the source broadcast material.

This is an example of a problem that never would have been visible on an SDTV, but the extra clarity of the HDTV display allowed you to see it.

cajieboy
04-15-09, 01:30 AM
The blurring and smearing in a camera pan is not a fault in the HDTV, rather it represents a flaw in the ATSC video standard that is seen worst on 720p broadcasts which have higher data rates than 1080i broadcasts.

720p has a resolution of 1280X720 and broadcasts 60 frames/sec. That is an uncompressed data rate of (1280x720x60) or 55.3Mbit/sec. After compression by the MPEG2 codec, the signal must fit within the 19.39Mbit/sec allowed by the ATSC channel bandwidth.

In a slowly moving image or a static image with smaller moving objects this is not an issue. However with a camera pan, every pixel on the screen changes for every frame - the data compression efficiency drops under these conditions and the result is "macro-blocking" which you see as blur.

In practice the problem is much worsened by stations which choose to steal bits from the main image to run subchannels with advertising, weather reports, or infomercials. The less bandwidth available for the live image, the greater the chance of blurring during camera pans.

The only comforting thing is that you could have spent over twice as much money on a Pioneer Elite Kuro HDTV and it would not have helped the tiniest bit when the blur is present in the source broadcast material.

This is an example of a problem that never would have been visible on an SDTV, but the extra clarity of the HDTV display allowed you to see it.

Gary, if what you are saying for this particular broascast is true, then shouldn't we all have seen this "motion blur". I really don't think this is source related as I watched the same Masters and never saw this motion blur. Also, numerous other people that I've spoken with did not see any motion blur either, and in fact the reverse comments were made that this year's Masters had the best HD PQ they had ever seen. Some even said it near "blu-ray" quality, which as we know can vary, but I knew what he meant by the description & experience.

greenjp
04-15-09, 08:03 AM
I believe CBS is in 1080i and DirecTV (which we were watching) transmits in MPEG4 - Gary I don't know if either of these factors affect your analysis?

Like cajieboy said, poeple in the thread on the HDTV programming board had good things to say about the PQ of the broadcast, and I don't ever recall seeing this effect on my plasma, also with DirecTV. Nor do I recall seeing anything this drastic watching 24 on my friend's A550.

The only reason I started this thread was due to the startling nature of what I was seeing - everybody talks about LCD blur, and I do prefer my plasma, but this was the first time it really jumped out at me. Just trying to learn.

jeff

glaufman
04-15-09, 09:49 AM
This is an example of a problem that never would have been visible on an SDTV, but the extra clarity of the HDTV display allowed you to see it.

Gary, if what you are saying for this particular broascast is true, then shouldn't we all have seen this "motion blur".

I saw it on my SDTV...

NuSoardGraphite
04-15-09, 10:54 AM
I would also occasionally see motion blur on my SDTV. It was rare, but I did see it from time to time. I'm surprised I don't see a lot more motion blur when watching cable. I only notice it every once in a while and then only when watching certain channels.

Gary McCoy
04-16-09, 05:10 PM
Two clarifications:

1) The ATSC specification pre-dates the MPEG4 codec by over a decade. That is why the system is MPEG2 only. MPEG4 is used on Blu-Ray and HD-DVD and some PC-based video.

2) You can't conclude from generic comments about program quality whether or not any given HDTV experienced blur. If you had the two sets side-by-side or if you played the same recorded scene on both, then you could compare. The problem I mentioned may occur on one network affiliate because they are stealing bits for subchannels, but the next affiliate on the same network might not broadcast the blur because they don't constrain the bandwidth of the HD channel.

Believe me, the effect is real. To give you an idea about how much bandwidth is required to supply a clean 1920X1080 image, the following constraints are imposed by the standards for each type of video:

ATSC as mentioned before, is 19.39Mbit/Sec using MPEG2.

Blu-Ray is 60Mbit/Sec using MPEG4.

HD-DVD is 50 Mbit/Sec using MPEG4.

DCI (the standard for Digital Cinema in commercial theaters) is 250Mbit/sec uncompressed.

Yet the uncompressed bitrate of 720p video is 55.3Mbit/sec and the uncompressed bitrate of 1080i video is 31.1Mbit/Sec. Both video modes depend upon MPEG2 compression to squeeze the video (plus extra bits for audio) into the program streams. Whenever the compression fails, you SEE the flaws.

TomCat
04-22-09, 10:54 PM
...720p has a resolution of 1280X720 and broadcasts 60 frames/sec. That is an uncompressed data rate of (1280x720x60) or 55.3Mbit/sec. After compression by the MPEG2 codec, the signal must fit within the 19.39Mbit/sec allowed by the ATSC channel bandwidth...Pretty close, you are only off by a factor of about times 300, plus you have confused pixel rate with data rate, which are two very different things. The uncompressed data rate of HD is actually much closer to 1.483 Gb/s. As in Gigabit rather than Mega. There are a lot of bits needed to represent each pixel at a bit depth of 8 and a color space format of 4:2:0 (for HD as formatted for public consumption), and there is significant overhead above and beyond the pixels themselves, such as FEC, ancillary info, and packet header info.

Multiplying the number of scan lines times pixels per line only yields the amount of Y or luminance pixels. 4:2:0 color space essentially requires another 25% added to that to represent P'r and another 25% to represent P'b. So multiplying fps times visible pixels per field hardly tells very much of the story, and certainly doesn't tell it at all accurately.

And if it did, that would be just the video. That 19.34 SMPTE310M bandwidth needs to carry a lot more than that in its transport stream, including PSIP, CC, and multiple audio tracks, just for starters, which is why the bit rate for HD rarely if ever approaches 18 mb/s as broadcast. There are typically 30-50 different PIDs in a typical transport stream, each requiring at least some of those bits. This means that if a TV station broadcasts HD at an average rate of 14.8 Mb/s (12-15 is pretty common for OTA, generous for DBS and cable) allowing the other four and a half Mb/s left over to carry everything else, that MPEG compression is performed at over a 100:1 ratio. Less than one percent of the original information is preserved intact and then used to help make extremely-educated guesses about the other 99% during decode. It's kind of amazing that there is anything left recognizable of the video at all, which just goes to show how sophisticated and effective even the "old" compression techniques such as MPEG-2 can be.

But digitization and compression are no longer factors by the time the light engine receives the HD signal. Since the display (the light engine part that converts the signal to something that you can see on the screen) never sees MPEG-compressed video, or even digital video (video that actually exists within the digital domain), although processed using digital techniques, it is pointless to consider that as something that might be an issue handled better by one display and worse by another, although certain display techniques such as DLP or LED pulsing may aggravate the artifacts that remain from digital compression. Bottom line, issues involving compression levels and data rates have nothing whatsoever to do with format pixel rates as far as the display is concerned. They are two different discussions.

The blurring and smearing in a camera pan is not a fault in the HDTV, rather it represents a flaw in the ATSC video standard that is seen worst on 720p broadcasts which have higher data rates than 1080i broadcasts...There is no "flaw" in the ATSC standard. It was designed to allow replication within a 6 MHz bandwith, which places an automatic 20 Mb/s ceiling on data rate. This is more a compromise than a flaw, as the 6 MHz bandwidth is a fixed limitation in the design that forces the compromise. Folks don't normally get the chance, but if you have ever seen HD before final SMPTE310 compression, at a compressed rate of 45-55 Mb/s, you might be shocked at how much better it looks than the HD you get at home. Blu-Ray might have the capability to present HD with data rates that high, but currently, all the content available comes from HD compressed to levels equivalent to broadcast HD content, and so still looks about the same.

The data rate of HD as delivered by OTA, DBS, FIOS, download, or cable is an arbitrary choice totally and completley independent of whether the format is 720p or 1080i, although partially driven by the fact that the actual pixel rate for 720p is actually significantly lower than that for 1080i. Depending on what the engineers choose, the data rate could just as easily be higher for content at 1080i than content at 720p and vice versa (and usually is higher for 1080i). And were your math correct (sorry, but no), it's still apples and oranges, pixel rate vs. data rate, which are two very, very different and only distantly-related things, even disregarding compression altogether. Your calculation only gives the raw streaming pixel rate, and not the uncompressed data rate, which is something entirely different; and actually 55.2 (million pixels per second), rather than 55.3, because the frame rate is actually 59.94, and not 60.

But, the pixel rate of 1080i is higher than that of 720p, at about 62.6, derived from 29.97x1920x1088 (the field rate is 29.97 rather than 30, and the actual amount of lines transmitted is 1088 because scan lines must total an even number of 16x16 macroblocks and the last 8 lines are transmitted with null bits), so the pixel rate of 720p is much less, actually only about 7/8ths that of 1080i.

That, and the difficulties with compressing interlaced content make transmission of 720p able to be done at a lower bit rate and/or higher compression level than 1080i for equivalent artifacting. IOW, 1080i is the more demandingly difficult format up to and including how it is handled by display technology, and not the other way around.

...In a slowly moving image or a static image with smaller moving objects this is not an issue. However with a camera pan, every pixel on the screen changes for every frame - the data compression efficiency drops under these conditions and the result is "macro-blocking" which you see as blur...The less bandwidth available for the live image, the greater the chance of blurring during camera pans... In a 1080p display (and actually in every progressive display, which encompasses all modern flat panels) during a pan every pixel changes for every frame regardless of what the incoming format is. For 720p, the image is rescaled to 1080p. For 1080i, the image is reinterlaced to 1080p. In both cases, the scan rate stays at 60 and the number of lines and pixels per line remain fixed at 1080 and 1920, respectively, as far as the task the display faces is concerned, which is the native display format that does not change (although the native scan rate can also be 120 and could change to 48 or 72 for 24 fps content in certain displays). IOW, after rescaling or reinterlacing, the display has no earthly idea what the original format was, nor does it care. Either process (rescaling or reinterlacing) is simple and not processor intensive, so can be done extremely transparently. Neither 720p nor 1080i places difficult demands on a modern display, but with a higher pixel rate, 1080i is relatively more difficult to handle than 720p. Bottom line, the artifacts and issues of compression efficiency and delivery have nothing to do with the issues facing display technology. Again, two separate unrelated discussions.

"Macro-blocking" is very different from blur, so it would be best if we don't confuse those either. Blur implies a loss of resolution. Loss of resolution when panning is a natural occurrence (maybe a little less so with interlaced content). If you move your eyes or turn your head 30 degrees to look at another point in the viewable world, during the time you are moving your head or eyes, foveal acuity is reduced significantly (everything is blurred) due to persistence of vision, the effect of which is analogous to a camera panning quickly. For that reason, it is not all that foreign to us when sharpness decreases during a camera pan.

In the real world of vision, we normally filter out or tell our brains to ignore the lack of acuity when we are moving our eyes to another point of vision. Its not as natural when our eyes don't move but the landscape does, as in filmed video, and we have to make the abstract leap of accepting that acuity will be diminished in such cases, an adjustment we all seem to make very quickly the first time we ever see a movie or television broadcast. This is not a function strictly of digital or compressed video, it is just as relevant for vision and for analog video, so it can't be pointed to as a flaw in digital compression techniques.

Macroblocking or blocking, however, is a flaw or artifact from digital compression. But it is not the same as and does not manifest as blurring. Macroblocking refers to what manifests on the screen when there are not enough bits to prevent buffer underflow in the decoder. The MPEG algorithm handles this in one of two ways. If the underflow is severe enough or lasts long enough, it mutes the video to black. If the underflow is intermediate, macroblocking can occur.

MPEG video is encoded at the macroblock level, which refers to 16x16 pixel areas each handled as a group of pixels. If the buffer underflow is just severe enough to not provide the decoder with enough information to decode the next macroblock designated for a particular area of the raster, the previous macroblock is repeated (essentially frozen on the screen) until a new macroblock can be decoded, or until the threshold of severity invokes a video mute.

Since it happens independently for each macroblock, there can be some that update adjacent to those that don't, and if motion is involved it appears as a mosaic pattern of breakup on the screen that allows human vision to distinguish the regular boundaries between macroblocks. That is completely different from blurring.

There may be cases when blur is seen in place of macroblocking. That is also not a display issue, it is an encoding issue. Some encoders, such as the Flexicoder, have an option to blur or reduce sharpness dynamically when motion is sensed. The idea is that it will look natural, as motion in human vision is blurred, and this will prevent other types of artifacts and lower the demand on the encoder. In practice it does not work that well.

For instance, if within an NBA game the encoder blurs during a wide slow pan of a fast break, yet the graphic laid over the top blurs as well, that's very annoying to the viewer. Not only that, but the natural way to change one's point of view from one end of the court to the other is not to fix one's eyes straight ahead and slowly turn one's head, but to fixate using nystagmus on numerous points in succession during the pan or "head turn" that represent things that are moving along with the pan (focus on the player or the ball, for instance) which will maximize acuity. That sort of makes the "blur during motion" algorithm a sort of counterproductive, if not a dumb move. Most modern encoding algorithms have abandoned blurring as a technique specifically because of how ineffective it is.

A better approach would be to instead of keying on motion as the blur trigger at a raster level as they do now, to key on buffer underflow at the macroblock level, which is sort of what the deblocking filter in MPEG-4 does. That way the only thing that would be blurred is potential macroblocking itself, and the rest of the scene would remain sharp. That's more of a understated "scalpel" approach to artifacts rather than the bull in the china shop or "broadsword" approach.