Occasionally I see "blocky" pixilation and digital artifacts and was wondering exactly what the culprit was.

I have a 32" Samsung 720p Flat Screen with Direct TV HR22-100 receiver. I think the problem occurs on all channels, mainly during fast moving sequences and it sort of comes and goes, like the occasional digital stutter.

So the question is, is the cause due to MPEG2 compression of the signal either from the broadcaster to DirecTV, or from DirectTV to the receiver? Or, is this a problem with the pixel refresh rate (6ms in my case) on the TV? Or something else?

In a related question, I notice on scenes with bright lights in clouds, fog, mist, etc. that there is a halo effect with defined concentric areas that surround light sources. Is this a failure of the 720p resolution to resolve the image with enough detail to smooth the halo or is this also an MPEG2 compression artifact?

If the blocks look like the content that should be there, it's a compression artifact. If they're randomly colored, that indicates an error in the stream. Compression artifacts can occur in the feed from the originator to DirecTV, or in the additional MPEG4 compression applied by DirecTV. Seeing compression artifacts all the time usually indicates your TV settings are wrong; excessive brightness, contrast, sharpness, and "picture enhancement" make the block edges more noticeable. Banding is caused by the encodering trying to save bits by preserving less of the picture in flat areas. It's more common in MPEG4 because the codec works harder to shift bits toward areas that need them more.

If the blocks look like the content that should be there, it's a compression artifact. ... Banding is caused by the encodering trying to save bits by preserving less of the picture in flat areas.
Thanks, it's definitely content that should be there. I'm using my HR22-100 to scale all content to 720p, so you are saying the TV settings may enhance these errors which are inherent in the signal, since the TV is doing none of the decoding? The only thing the TV is doing is upscaling the 720p to 768p. Does upres or downres affect these types of artifacts at all?

Also I heard DirecTV converts 1920x1080 to 1440x1080 or even 1220x1080. Myth?

As for banding, I assume you are referring to the segmented boundary halo effect I was describing. So the primary culprit is likely compression as well? Made worse by screen enhancement? That would explain why I rarely see banding from off-air HDTV, which is generally better than anything coming out of the DTV DVR.

Changing of resolution doesn't have much to do with those artifacts. D* did use 1280x1080i HDlite on their MPEG2 channels, but I don't think there's any conclusive evidence either way on the MPEG4 channels. The banding is mostly an artifact of MPEG4, so you won't see it on the MPEG2-compressed broadcast channels.

The banding is mostly an artifact of MPEG4, so you won't see it on the MPEG2-compressed broadcast channels.
I was about to agree with you except last night I tuned into off-air HDTV and noticed the banding occasionally. I'm assuming our local broadcasters in LA are using MPEG 2 over the air. Odd.

Hence "mostly" :). It does happen in MPEG2, especially in more advanced encoders, but MPEG4 leans much more heavily towards the psychovisual enhancements.

I was about to agree with you except last night I tuned into off-air HDTV and noticed the banding occasionally. I'm assuming our local broadcasters in LA are using MPEG 2 over the air. Odd.

ALL Digital OTA is in MPEG2 - period... The only thing that might NOT be in MPEG2 is the new standard for ATSC/MH .

Occasionally I see "blocky" pixilation and digital artifacts and was wondering exactly what the culprit was...I think the problem occurs on all channels, mainly during fast moving sequences and it sort of comes and goes, like the occasional digital stutter.

So the question is, is the cause due to MPEG2 compression of the signal either from the broadcaster to DirecTV, or from DirectTV to the receiver? Or, is this a problem with the pixel refresh rate (6ms in my case) on the TV? Or something else??In a compression scheme like MPEG much of the compression is inter-frame compression. What is transmitted in consecutive frames of video is largely redundant, and MPEG takes advantage of that by sending the delta or difference between consecutive frames rather than sending the redundant info all over again for every frame. That works great (efficiently) until the source video begins to change at a higher rate, such as an NBA fast break shot from floor level, or white-water rafting, or closeups of "Jack and Kate" being chased through the jungle on Lost. Fast changing video taxes the system as the efficiency level drops, and if compressed too much, this causes macroblocking types of artifacts.

It's pretty normal, as arguably the least-compressed video widely-available to consumers (OTA) is typically compressed at a 100:1 ratio, meaning 99% of the original info has been discarded at the encoder and can only be recreated at the local decoder by making educated guesses using the other 1%, or what is left. The problem manifests when high action content makes the task of making those guesses harder, and the result is less accurate guesses leading to visible errors. It is blocky because MPEG is processed at the macroblock level, so individual blocks of 16 x 16 pixels may linger on the screen too long if there is not enough info for the decoder to construct the next macroblock in temporal order. When some blocks update in a timely manner while adjacent ones don't, it can give a mosaic effect as the edges of the blocks, which are typically invisible, reveal themselves.

DTV may be slightly compressed even more, which doesn't help, although I have not seen a noticeable difference between OTA video and the same video converted to MPEG-4 via DirecTV (and believe me, I have looked very closely to see). It doesn't appear that either the MPEG-2 to MPEG-4 conversion they do or possible further compression over the sat path have any significant bearing on PQ, which is a pretty slick achievement, actually. Their conversion to MPEG-4 has effectively given them more bandwidth to work with than in the days of MPEG-2 delivery, when they had to make compromises to PQ in order to deliver lots of channels. Wikipedia, FWIW, seems to think that they abandoned the down-rezzing and bitstarving problems they had under MPEG-2 now that MPEG-4/Ka delivery has given them more bandwith.

If you see this sort of thing other than when there is high action content, that probably indicates a reception issue, but it sounds like you are speaking about the typical macroblocking we all see on action even when the reception is not an issue.

Your TV is not a contributor to the problem. Every 1080p TV only refreshes the screen every 17 ms, so a phosphor that refreshes 3 times quicker certainly can't contribute to blur or other artifact issues.


In a related question, I notice on scenes with bright lights in clouds, fog, mist, etc. that there is a halo effect with defined concentric areas that surround light sources. Is this a failure of the 720p resolution to resolve the image with enough detail to smooth the halo or is this also an MPEG2 compression artifact?Also a compression artifact. It is due to coarse quantization performed in the DCT phase of the MPEG suite of compression techniques, and is technically referred to as quantization noise error. It is most likely due to the compressionists choices at the MPEG-2 level rather than issues converting to the MPEG-4 level.

720p consumes about 7/8ths the bandwidth/data rate of 1080i, so actually yields slightly fewer artifacts for a given data rate. You must be sitting closer than 3 picture heights away to differentiate pixel structure even at 720p, so unless you are closer than 7.8 feet from a 60"-er, for instance (and most sit further away from even smaller screens), that would have no bearing. You will see the same problem with equal visibility regardless of the display format. It is strictly a compression issue.

Also a compression artifact. It is due to coarse quantization performed in the DCT phase of the MPEG suite of compression techniques, and is technically referred to as quantization noise error. It is most likely due to the compressionists choices at the MPEG-2 level rather than issues converting to the MPEG-4 level.

720p consumes about 7/8ths the bandwidth/data rate of 1080i, so actually yields slightly fewer artifacts for a given data rate. You must be sitting closer than 3 picture heights away to differentiate pixel structure even at 720p, so unless you are closer than 7.8 feet from a 60"-er, for instance (and most sit further away from even smaller screens), that would have no bearing. You will see the same problem with equal visibility regardless of the display format. It is strictly a compression issue.

Actually, that type of artifacting is visible before the MPEG-2 is applied. Any video quantized at 8 bits will show this type of contouring in scenes that have gradual changes in brightness.

Actually, that type of artifacting is visible before the MPEG-2 is applied. Any video quantized at 8 bits will show this type of contouring in scenes that have gradual changes in brightness.No, not really, all HD video (consumer flavor) is 8-bit, and contouring is not typically noticeable on raw or even mezzanine-compressed HD video, and probably not at all until SMPTE310 or an equivalent level of compression happens before delivery to the viewer. All consumer HD is also MPEG-compressed, which means it is not only quantized during digitization, but is at a minimum then requantized in the DCT during compression, and this artifact is still not usually visible unless squeezed too much somewhere in the compression process. But then people would be shocked at how good HD actually looks before final compression is applied, such as at 45-55 mbps as it is delivered from the network to the TV station. Unfortunately, it's all downhill from there.

For an example that anyone with a computer can see, 8-bit video in a 4:2:0 color space (which is how consumer HD is formatted) has a similar amount of quantization error (before compression) that 24-bit still video in a 4:4:4 RGB jpeg has, which is to say "not very much" or quantization error that is barely visible. If you run a nature photo as your wallpaper on your PC at "16.7 million colors" which actually refers to a similar number of quantization levels as HD video has, it looks very realistic and contouring is virtually invisible. Reduce that to "256 colors" and you will see obvious contouring that is about what you would see with 4-bit quantization of video during A-to-D.

So I am not saying you are incorrect about quantization during digitization having the capability of causing contouring, it is just not at 8 bits where it becomes visible. You are actually quite correct that quantization before compression can cause contouring, but it has to be actually at bit levels much lower than the 8-bit quantization used for HD before it becomes noticeably visible.

The contouring artifacts we typically see on HD video are not typically caused during original 10 or 8-bit digitization, they are caused during the requantization done in the DCT phase of original compression, or by concatenation of dissimilar algorithms, or by final recompression before delivery by vendors who want to stuff too many channels into a single transponder (or broadcasters limited to minimal bit rates by simulcasting), or sometimes by any number of those things that happen well after digitization chained together.

No, not really, all HD video (consumer flavor) is 8-bit, and contouring is not typically noticeable on raw or even mezzanine-compressed HD video, and probably not at all until SMPTE310 or an equivalent level of compression happens before delivery to the viewer. All consumer HD is also MPEG-compressed, which means it is not only quantized during digitization, but is at a minimum then requantized in the DCT during compression, and this artifact is still not usually visible unless squeezed too much somewhere in the compression process. But then people would be shocked at how good HD actually looks before final compression is applied, such as at 45-55 mbps as it is delivered from the network to the TV station. Unfortunately, it's all downhill from there.

For an example that anyone with a computer can see, 8-bit video in a 4:2:0 color space (which is how consumer HD is formatted) has a similar amount of quantization error (before compression) that 24-bit still video in a 4:4:4 RGB jpeg has, which is to say "not very much" or quantization error that is barely visible. If you run a nature photo as your wallpaper on your PC at "16.7 million colors" which actually refers to a similar number of quantization levels as HD video has, it looks very realistic and contouring is virtually invisible. Reduce that to "256 colors" and you will see obvious contouring that is about what you would see with 4-bit quantization of video during A-to-D.

So I am not saying you are incorrect about quantization during digitization having the capability of causing contouring, it is just not at 8 bits where it becomes visible. You are actually quite correct that quantization before compression can cause contouring, but it has to be actually at bit levels much lower than the 8-bit quantization used for HD before it becomes noticeably visible.

The contouring artifacts we typically see on HD video are not typically caused during original 10 or 8-bit digitization, they are caused during the requantization done in the DCT phase of original compression, or by concatenation of dissimilar algorithms, or by final recompression before delivery by vendors who want to stuff too many channels into a single transponder (or broadcasters limited to minimal bit rates by simulcasting), or sometimes by any number of those things that happen well after digitization chained together.

I have seen contouring in uncompressed, 4:2:2, 8 bit video. If you don't believe it look at an uncompressed, gradual ramp with low levels of chroma. You will see the contouring on 8 bit video but not on 10 bit video.

ALL Digital OTA is in MPEG2 - period... The only thing that might NOT be in MPEG2 is the new standard for ATSC/MH .

All Digital OTA in the US is in MPEG2 (unless anyone is datacasting H264 - but I don't believe they are) - but H264/MPEG4 is in use in a lot of other countries OTA for HD and/or SD.

France, Sweden, Ireland, Norway, New Zealand, Slovenia and quite a few others etc. are all using H264 with DVB-T OTA. The UK is testing H264 HD OTA using DVB-T2 - in preparation for a launch later this year.

Brazil is also using H264 with ISDB-T OTA.

If you are launching a new OTA platform these days - there has to be a VERY good reason to chose MPEG2 over H264. However if you launched your OTA platform a few years ago (pre-2006) then MPEG2 was probably the only option open.

(France went MPEG2 for SD free-to-air broadcasts, but H264 for HD and Pay-TV SD. Sweden went MPEG2 for both FTA and Pay-TV SD, but H264 for HD. In both cases this was so that the SD platform would be compatible with the large number of SD MPEG2 IDTV receivers available at low cost on the market, but there was different logic for Pay TV and HD)

I have seen contouring in uncompressed, 4:2:2, 8 bit video. If you don't believe it look at an uncompressed, gradual ramp with low levels of chroma. You will see the contouring on 8 bit video but not on 10 bit video.
It is particularly noticed on lower-luminance saturated blue graduations, where you have a much lower amount of luminance bit-depth available to you.

Quantel realised this very early on with 8 bit digital video - hence their Dynamic Rounding system (patented and licensed by many) which significantly reduced the visibility of banding during bit depth reduction to 8 bit from higher levels, and during mathematical processes.

All Digital OTA in the US is in MPEG2 (unless anyone is datacasting H264 - but I don't believe they are) - but H264/MPEG4 is in use in a lot of other countries OTA for HD and/or SD.

France, Sweden, Ireland, Norway, New Zealand, Slovenia and quite a few others etc. are all using H264 with DVB-T OTA. The UK is testing H264 HD OTA using DVB-T2 - in preparation for a launch later this year.

Brazil is also using H264 with ISDB-T OTA.

If you are launching a new OTA platform these days - there has to be a VERY good reason to chose MPEG2 over H264. However if you launched your OTA platform a few years ago (pre-2006) then MPEG2 was probably the only option open.

(France went MPEG2 for SD free-to-air broadcasts, but H264 for HD and Pay-TV SD. Sweden went MPEG2 for both FTA and Pay-TV SD, but H264 for HD. In both cases this was so that the SD platform would be compatible with the large number of SD MPEG2 IDTV receivers available at low cost on the market, but there was different logic for Pay TV and HD)

I stand corrected - my focus was on US digital OTA. It's not that the newer standards aren't better, it's just that we are so large that making a change takes a LONG TIME. Maybe in 20-40 years we might look at changing to a more efficient CODEC - maybe sooner.