[JackBikes]

I Have a HD DVR, DTV version. I record several shows and lately I am seeing severe pixilation during shows. Doesn't seem normal. What can I do? Do I call DTV?

 

[Jeffro]

I've noticed pixilation too on Universal HD last Saturday night during Smakdown once. Also have noticed on either Cinemax or HBO channel last week as well.

 

[TomCat]

First I think we need to define exactly what you are seeing. If the pixellation occurs regularly and often there is sometimes also stuttering of the video, muting of the audio, possibly even a black or frozen screen, that is most likely a reception problem.

If instead it seems to happen only when there is a lot of motion, when a program is fading from and to black, and audio is not affected and video does not occasionally freeze, that is more likely a compression issue.

A third possibility is a HDD issue. This can be determined or ruled out. If you are seeing pixellation on live TV, go channel up once, then down once, which takes the HDD out of the equation (until you pause or skip back). If the problem goes away, that points to the HDD.

DTV has certain channels that get more bits than others, and historically the pay channels have been the beneficiaries of that unequal treatment, so bearing that in mind it would be unlikely that they are compressing HBO/MAX overly much.

 

[veryoldschool]

DTV has certain channels that get more bits than others, and historically the pay channels have been the beneficiaries of that unequal treatment, so bearing that in mind it would be unlikely that they are compressing HBO/MAX overly much.

It may not be a compression issue exactly but a problem in the muxing, where all the channels at the same time require high MPEG-4 bit-rates and the mux can't for a moment supply enough for each.
If this is the case, they would be momentary, fairly rare, and don't seem related to much else.

 

[TomCat]

It may not be a compression issue exactly but a problem in the muxing, where all the channels at the same time require high MPEG-4 bit-rates and the mux can't for a moment supply enough for each.
If this is the case, they would be momentary, fairly rare, and don't seem related to much else.

My use of the word "compression" was meant to refer to to all of the techniques together that DBS employs to get the signal to the customer within a reduced bandwidth.

Muxing, or multiplexing transport streams refers to combining program streams and other elemental streams, which is one of those techniques. The technique of muxing, which I coincidentally spent most of this week intimately involved with, BTW, requires that the Engineer make sure that the bit rates of the streams that are combined do not exceed the channel rate. There is some variance in the bit rates that also must be accounted for, and headroom is left in for that.

A compressionist will always make sure that the input signals are compressed to the point where when combined will not create a buffer overflow, so muxing will not in and of itself create this sort of problem. DBS employs statmux which reduces the occurrence of otherwise-pixelated video to the point where it is nearly nonexistent, and certainly reduces it to the point where customers would not be motivated to complain about it.

improper muxing technique is highly unlikely to be the cause of this problem. When muxing is done improperly, the result manifests usually much more severely than just a little incidental pixelation.

Incidentally, this is the first time I've tried to use iPad iOS 5.1 speech-to-text dictation and it works really well, but it seems to not be able to learn technical terms like muxing.

 

[veryoldschool]

DBS employs statmux which reduces the occurrence of the sort of problem you are describing to the point where it is nearly nonexistent, and certainly reduces it to the point where customers would not be motivated to complain about it.

This wouldn't be the first time I wasn't using the exact terminology correctly, but the statmux isn't manned by an engineer, and was where some of what I've seen looks to be coming from.

 

[TomCat]

This wouldn't be the first time I wasn't using the exact terminology correctly, but the statmux isn't manned by an engineer, and was where some of what I've seen looks to be coming from.

Well, actually I was mostly agreeing with you.

The problem with statmux is it allows the untrained Engineer to cheat and not leave quite as much headroom as they normally would, assuming statistically that the combined bit rate will never exceed the channel rate. The reality is that statmux does absolutely nothing to reduce the combined instantaneous bit rate. The Engineer improperly reasons that this allows him to use less compression which is not actually the case. It's actually a surprisingly-common misconception that statmux allows the use of less compression.

The proper implementation of statmux is to not be able to use less compression, but to make the same level of compression look better in the rare moments when the encoder is stressed by complex video. It borrows bits otherwise unavailable to make those instances appear better to the viewer. It does this by allocating the bits to whatever program in the stream needs those bits at any particular time, borrowing them temporarily from other programs that are not at that moment being stressed with complex video. But at any single moment in time there is still the same agregate number of bits as there would be without statmux, meaning there really is no opportunity afforded to reduce compression levels. it just makes the video appear to have less compression because extra bits are available when needed.

Lowering compression levels is still just as likely even with statmux to cause a buffer overflow situation as it would be without it. Statmux does not work on the input to the transport stream; it works by actually increasing the amount of variance in the individual programs within the stream as an output function, which means the limitations at the input to the transport stream don't change.

The Engineer may assume that they will get a better result by reducing the compression level and taking the chance that the combined level will rarely exceed the channel rate but this is not really a good idea; you actually end up with a visually better result by leaving the bit rate alone and allowing statmux to improve those moments of high stress in the video automatically. A good Compressionist learns this concept early on. Especially when the bit rate scrapes the ceiling a few times and causes larger problems. The Engineers at DTV are all pros, so there is little chance that they would make such a mistake, meaning that improperly muxing is virtually unheard of.

There actually is no smoking gun evidence That can link visible pixelation to improper muxing. That it "looks to be coming from" that is a false assumption.

 

[veryoldschool]

There actually is no smoking gun evidence That can link visible pixelation to improper muxing. That it "looks to be coming from" that is a false assumption.

Since it was my "assumption", I'm not so quick to call it false, though it could be.
My understanding of the function of the statmux is that it allows for more optimal use of the transponder bandwidth, by allowing unused bandwidth to be used by other channels, which seems to be more important with MPEG-4 than MPEG-2, since the bit-rates vary much more.
Maybe I'm not understanding some of what you've posted, but it suggests the encoders are part of the statmux, which I don't think they are.
I'm sure an engineer will set some parameters, but you make it sound like it's being done in real time, which would be an overwhelming task for all the feeds DirecTV has.
Now with HBO, it's being supplied to DirecTV in MPEG-4, so I don't see DirecTV changing bit-rates.

"The Engineers at DTV are all pros, so there is little chance that they would make such a mistake, meaning that improperly muxing is virtually unheard of."

While I agree that they're pros, I've also seen screen shots posted here showing problems, "AND" personally have a case where that is exactly what was happening.
"Case in point":
If you search the forum for threads about PBS and Ken Burn's National Parks series, you find threads/posts of pixelation problems.
This series didn't transcode well into MPEG-4. I noticed mine would only not have problems when recording in the middle of the night. Primetime recordings were unwatchable. I also noticed my hard drive storage space was twice what it normally is, as I was saving most of the series so I could watch it in order.
Investigating this anomaly, I found the MPEG-4 bit-rate to be 20+ Mb/s during playback.
This explains both the disk usage and the pixelation during primetime, but not when the statmux had more bandwidth available.
"The gun was smoking" in this case.

 

[TomCat]

...My understanding of the function of the statmux is that it allows for more optimal use of the transponder bandwidth, by allowing unused bandwidth to be used by other channels, which seems to be more important with MPEG-4 than MPEG-2, since the bit-rates vary much more.

It does exactly that, but the "more optimal use" does not include raising the bit rate of the individual programs inside that transport stream; it instead allows individual program streams to use more bits, and only when needed, than they were actually allocated when setting the original bit rate. None of the bandwidth is "unused" in either case, but there are fewer null packets required when statmux is used than when it isn't. Statmux therefore uses the bandwidth more efficiently which therefore results in better pictures, but without actually raising or changing the bit rates of any of the program streams within the transport stream.

An MPEG decoder uses as little as 1% of the original information (which is all that it can derive from the compressed bit stream because the other 99% of the information was discarded at encoding) along with a strict yet complex set of rules to make intelligent guesses as to what that other 99% of the video should consist of. When the complexity is low, the errors in that process are virtually below any level of human perception. When the complexity is high, the decoder has fewer accurate clues to do the guesswork about the other 99% and begins to guess more incorrectly more often, and the errors become increasingly noticeable, and when they manifest to a particular level of perception, we see that as an artifact that we call pixellation or macroblocking.

Because one of the primary compression techniques in MPEG is temporal compression, delivery of consumer-level encoded video looks terrific when the video is not complex (when the picture is relatively static), but suffers visible pixelation when the video is complex (lots of pans and zooms, flashes, explosions). One solution, the "broadsword" solution, would be to use a higher bit rate, which is impractical.

In a multiple program transport stream, or MPTS, the peak needs of different programs most often happen at different times, from a statistical point of view. What if there were a way to reapportion those unused bits from programs not currently processing complex video to other programs in the transport stream that could put them to good use at the moments that those programs are processing complex video? Ergo, statistical multiplexing.

Statmux is the "scalpel" solution; it does not allow an increase in bit rate, but allows more bits to be used more intelligently at moments when the complexity would otherwise cause pixelation, and in that way reduces pixelation in a manner that makes the video appear as if it is not quite as compressed. It gives it wiggle room which reduces bit starving in those complex-video moments. It's like a food bank for occasionally bit-starved programs. It's not magic, but about as close to magic as it gets.

It is not more important with MPEG-4, but because the bit rates vary much more it is more efficient, except for the fact that the improvements it makes can be actually more helpful to MPEG-2 (which needs more help in this exact area) than MPEG-4 (which inherently does not need so much help when the encoding gets complex).

Maybe I'm not understanding some of what you've posted, but it suggests the encoders are part of the statmux, which I don't think they are.
I'm sure an engineer will set some parameters, but you make it sound like it's being done in real time, which would be an overwhelming task for all the feeds DirecTV has...

Encoders are technically separate from statmux in that they are different processes handled by different LSI hardware programmed to do different tasks. Encoders just sit there and process whatever is input to them, but they are not a single process. MPEG-2 is a suite of some 30-odd unique bit-reduction tools chained together. MPEG-4 does much the same thing, but has an expanded toolbox capable of more sophisticated techniques.

Statmux is, once again, something that happens technically at a different point in the chain, to reapportion the available bits. But the encoder and statmux are intimately tied together. Statmux processing actually happens between different sections of the MPEG encoding suite. you could say that it happens somewhere in the middle of encoding, yet it is still a separate process different from any part of actual encoding.

The statmux algorithm monitors incoming program streams and must keep track of what bits are apportioned where, and must be able to determine which program streams need to take advantage of bits that might be unused by another program stream at any particular time, so statmux as an active "traffic-cop" process is typically something that happens in the same physical piece of gear as where encoding happens.

Since statmux processes the bit streams after they are partially encoded this explains why it can do nothing to allow higher bit rates at the input to the encoders. Without statmux there are many more null packets used as filler for when a particular program stream varies up and down in bit rate.

Based on video complexity at any given moment, the program rates can rise instantaneously and approach the ceiling or lower instantaneously and not use all of the bits allocated, and the null packets fill out the streams so that the channel rate is steady (most consumer-level decoders are low cost and do not have the sophistication to decode wildly varying channel rates). The ceiling for each program has to be set high enough to keep the bit rate from starvation when it is using most or all of the bits allocated to it, yet it's a waste of bits when the bit rate of a program goes instantaneously lower at particular moments.

Statmux is based on the fact that it is statistically unlikely that each program in the stream might need extra bits at the same time as other programs, which means that rather than wasting the extra bits by filling the stream with null packets, those bits can be reallocated on the fly to whatever program needs them the most at the point in time it needs them the most. Its a form of TDM, or time sharing. This uses the transponder more efficiently because there are fewer null packets that then need to be inserted, and each program performs as if it were actually operating at a higher bit rate than it was originally allocated, most of the time, statistically speaking (which is where it gets its name from).

This makes it appear to the viewer as if a higher bit rate were being used, most of the time. Of course, statistically, there will be that rare moment that all of the programs in the transport stream are calling for extra bits at once. In that situation statmux is no better than if it were not there at all, but this is still better than having this situation all of the time, even if slightly worse than simply using a higher bit rate. But it's a very good compromise.

The parameters are set by Engineers once, and the intelligence of the processing is what reallocates the bits in real time from that point on. It's basically set it and forget it.

"The Engineers at DTV are all pros, so there is little chance that they would make such a mistake, meaning that improperly muxing is virtually unheard of."

While I agree that they're pros, I've also seen screen shots posted here showing problems, "AND" personally have a case where that is exactly what was happening.
"Case in point":
If you search the forum for threads about PBS and Ken Burn's National Parks series, you find threads/posts of pixelation problems.
This series didn't transcode well into MPEG-4. I noticed mine would only not have problems when recording in the middle of the night. Primetime recordings were unwatchable. I also noticed my hard drive storage space was twice what it normally is, as I was saving most of the series so I could watch it in order.
Investigating this anomaly, I found the MPEG-4 bit-rate to be 20+ Mb/s during playback.
This explains both the disk usage and the pixelation during primetime, but not when the statmux had more bandwidth available.
"The gun was smoking" in this case.

Your examples are not easily explained away, I will grant you. Many mistakes are made by many pro Engineers, and are made regularly. We are all human and we all make mistakes. Even me . And it does not surprise me that PBS is involved, as they seem comparatively clueless in this post-analog, post-SD world.

But your examples do not apply to my statement, which was that at DTV improper muxing would be a rare engineering choice. I stand by that statement, as well as the fact that a muxing mistake is not going to manifest as incidental pixelation, which is what the original subject was all about.

 

[veryoldschool]

But your examples do not apply to my statement, which was that at DTV improper muxing would be a rare engineering choice. I stand by that statement, as well as the fact that a muxing mistake is not going to manifest as incidental pixelation, which is what the original subject was all about.

Sorry, but posts this long end up with my eyes crossing, but I did try to get through part of it.
While you may stand by your statement, I must stand by my experience and conclusions too.
Doubt we really need to agree or disagree, so the thread can continue.

 

[TomCat]

Sorry, but posts this long end up with my eyes crossing, but I did try to get through part of it.
While you may stand by your statement, I must stand by my experience and conclusions too.
Doubt we really need to agree or disagree, so the thread can continue.

Actually, the thread can probably close. We (I) have thoroughly hijacked it for a 2-man conversation with you, which I apologize for to everyone else. I'm not sure anyone else really cares about the inside baseball of transport stream multiplexing anyway. And the OP has his answers, which is what is really the important thing. The rest is just so much gas.

But make no mistake; this is not simply an "agree to disagree" situation. Not at all. There are no divergent opinions allowed about how this might work, because there are beaucoup plenty of facts already on the record, and facts always blow unsupported opinions clean out of the water. Every single time. Technology, unlike politics and religion, is based entirely in scientific fact rather than opinion. Everything about this is already thoroughly tested and empirically proven long before it ever can trickle down to the consumer level and be implemented in billion-dollar infrastructures such as DBS or broadcast television.

A person can't claim that they think they are correct simply because they can't be bothered to take the time necessary to learn the facts, especially if they have just been presented with those facts on a silver platter or a flaming pie. That would be as ludicrous as me telling my heart-specialist doctor that I don't agree with him regarding his care instructions because of some inane blurb or factoid that I casually stumbled across surfing WebMD the other day. There's a word (that I can't use here) for people of that ilk.

I actually have the luxury (or curse) of currently working intimately within this medium of transport stream technology, so I know and even understand many of these facts. I am not an expert if you define expert using the "Outliers" definition of 10,000 hours of study (which is the equivalent of applying yourself completely for 50 40-hour weeks for 5 years to this area and nothing else), but I probably have about 100 full workdays of study over the last few years directly in this discipline under my belt, which is probably about 99.99 more days than 99.99% of any other people you could ask these questions of (and so where are those other 30,000 US citizens?). I'm thinking that probably qualifies me to answer questions regarding it intelligently, even if only barely, compared to the real geniuses that actually came up with this stuff.

And I can't just read about it and leisurely move on; If I want a continuing paycheck I have to make things work in the real world under the rules governing this particular protocol. This highly motivates me to understand this and not treat it as merely an academic theoretical exercise. So even if some would not consider my involvement and level of understanding expert, you're also not exactly dealing with a chimp or an armchair quarterback here.

And this is why I have been gracious enough to take a lot of my time to try to explain it to you. Perhaps my sense that you wanted to learn was woefully misdirected. But I am still happy to clear up any follow-up questions in a PM if you so choose. But I also will respond to challenges if they are in public posts, and I welcome any real experts to chime in as well. That only means I can learn that much more.

Otherwise, screw it. We've taken up enough of everyone else's forum with this already.

 

[veryoldschool]

Otherwise, screw it. We've taken up enough of everyone else's forum with this already.

!rolling
Some may find it interesting.

You just seemed to dismiss some things I'm fairly confident about, so while we may not agree, it still doesn't matter in the grand scheme.

Some of this may merely be our perspectives, as yours seems to be from keeping it working correctly, and mine is from seeing problems when things don't and having to sort through the "where" it can be happening.

If every engineer's "plans" always worked, I'd have had much less work to do. :lol: