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?
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.TomCat said: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.
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.veryoldschool said: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.
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 said: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.
Well, actually I was mostly agreeing with you.veryoldschool said: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.
Since it was my "assumption", I'm not so quick to call it false, though it could be.TomCat said: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.
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.veryoldschool said:...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.
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.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...
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."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.
Sorry, but posts this long end up with my eyes crossing, but I did try to get through part of it.TomCat said: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.
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.veryoldschool said: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.
!rollingTomCat said:Otherwise, screw it. We've taken up enough of everyone else's forum with this already.