The psychology of conspiracy theorists

[cjameshuff]

Right, and this is why channel-changing is so annoyingly slow on most digital TV systems (cable, broadcast and satellite). The RF tuners, demodulators and error correctors usually change very quickly, but the MPEG decoder has to wait for those I frames before it can start producing decoded video. They're big, so getting a good compression ratio may limit them to once every few seconds.

It's also an issue with anything supposed to resemble real-time video. You have to have data from frames following the one you're currently decoding, so display must lag reception of a frame by several frame times. And to encode that frame in the first place, you have to wait for subsequent frames to be captured. There's an unavoidable delay there that can't be avoided by just adding processing power. Low-latency video requires doing things like encoding a stream entirely with I frames, which is basically equivalent to a stream of JPEG images...which means much poorer compression ratios.

Yes, but this usually produces very dramatic and obvious artifacts, and I assumed that's not what Tedward was seeing. It sounds like he was seeing the ordinary compression artifacts.

Leaving a chunk of scaffold image in place of part of a guy's head seems fairly dramatic and obvious. Something like a mangled double exposure between a stale still picture and whatever the current video is...

[Tedward]

t
Yes, but this usually produces very dramatic and obvious artifacts, and I assumed that's not what Tedward was seeing. It sounds like he was seeing the ordinary compression artifacts.

It was a camera pan across a football crowd and must have been the down link to boot. There was a bit of scaffold attached to a support column and with the fans heads all around as part of the shot, all around cheering a booing as they do. During this pan one head picked up the scaffold. It was a good few years ago and that encoder is keeping dust off a shelf somewhere now, we also had CRT monitors.

Edit. Actually I think it was a camera adjustment not a full pan? That is the operator settling on a different framing so there was movement? It was a good few years ago now but the effect still lingers in my mind.

[ka9q]

It was a camera pan across a football crowd and must have been the down link to boot.

Camera (and subject) motion is so common that MPEG makes special provisions for it. Each block (typically 8x8 pixels) is encoded by telling the decoder to start with the block of pixels from the last decoded frame at a certain x,y position offset. If the camera is panning right at 10 pixels/frame, typically the encoder will tell the decoder to start with an offset 10 pixels to the right. If it's zooming, the offset will vary with the location of the block in the image, being smallest in the center.

The encoder uses a brute force search, trying a range of offsets in both directions and looking for the one that provides the most compact encoded representation. This is the chief reason encoding is slower than decoding, and it's such a CPU hog that one of Intel's earliest vector instructions was one specifically designed to help speed it up: sum of absolute byte differences. (The smallest such sum represents the best match.)

MPEG actually gets its bit savings much the same way as JPEG, by converting each block into the frequency domain and quantizing the individual bins. Many bins contain small values that are quantized to zero especially at the more aggressive compression levels, and when this happens in a difference frame the effect is that the previous image, though it may be shifted on the screen to track camera motion, isn't actually updated to reflect the (small) changes that have occurred in those pixels between frames. That's one way to get combinations of old and new pixels, possibly including your example of a scaffold through somebody's head.

It's also possible that there was simply a transmission error, or more likely the encoder was forced to drop some data to stay under its bit rate cap. This often happens in sporting events when there's lots of rapidly changing detail. It also shows up a lot in choppy water surfaces for the same reason.

[JayUtah]

Right, and this is why channel-changing is so annoyingly slow on most digital TV systems (cable, broadcast and satellite).

Yes, I tried writing a new channel-changer for our in-house TiVo satellite version, and I really couldn't improve it.

The RF tuners, demodulators and error correctors usually change very quickly...

Meh, sorta.  In satellite systems you often not only have to change the RF tuner to a new frequency, you also have to change the feedhorn to a different polarity:  horizontal, vertical, circular-left, or circular-right.  And with multiple feedhorn systems sometimes you need to connect a different feedhorn to the backhaul in order to access a different spacecraft.  So polarity changes, frequency changes, feedhorn changes, PLL sync, do take a significant amount of time in the worst case.

...but the MPEG decoder has to wait for those I frames before it can start producing decoded video.

Indeed and that's still typically quite a bit longer than the electronics resychronization time.  In addition most systems want to buffer the stream a bit too in RAM.

They're big, so getting a good compression ratio may limit them to once every few seconds.

Frame type mixing is a black art for satellite systems.  One technique, for example, mixes content such as CSPAN on the same transport stream as other streams such as ESPN.  Sports programs typically have dynamic content and require a higher key-to-intermediate ratio than Talking Head programs that typically just aim the camera and some droning blowhard.  Those programs don't require many I-frames, and so they're typically sent only as often as customer tolerance allows for the decoder and buffer latency.  Not every program takes the same fraction of the available bandwidth in a transport stream, so over time they can be load-balanced.

...for the first couple seconds after you change the channel you are sent your own unicast (private) version of the new channel structured such that the decoder can almost immediately start producing video. If you stay on the channel, the set-top box joins the appropriate multicast group and switches seamlessly to it.

Since some consumer satellite systems also incorporate internet-by-satellite, this might be an option.  But when I was involved with this in the mid-1990s it really wasn't.  Nor could the systems at the time listen effectively on more than one transport stream in the hopes of buffering other content; the feedhorn can physically receive only one polarity at a time.

You can often tell by looking how often I frames are sent.

We had low-level decoders and software to measure that.  But yes, your method works informally.  The encoders are adaptive.  They know how "dirty" the decoded stream is likely to be and decide when to send I-frames based on that, in connection with the available bandwidth in the stream into which they are injecting, and according to the QoS "floor" set by the content provider.  Ground stations are highly sophisticated, with health monitoring in real time from the spacecraft, QoS monitoring on the downlink, consensus-based load-balancing between stream injectors, and enterprise-wide load-balancing among spacecraft and transponders.  Plus there is a dedicated team of knob-tweakers who manage the subjective portion of the QoS.

[cjameshuff]

Indeed and that's still typically quite a bit longer than the electronics resychronization time.  In addition most systems want to buffer the stream a bit too in RAM.

Right. Some frames take more work to decode than others. It takes more processing power to consistently decode of 1 frame per frame time than to decode 10 frames per 10 frame times...the buffer gives the decoder some slack to handle occasional more difficult frames, catching up on the easier ones. By using more RAM and higher latency you can use a cheaper, slower, lower-power CPU. But this adds another considerable chunk of latency...it's not something you want in the loop when working with an interactive user interface, remotely operated equipment, etc.

[JayUtah]

Right. Some frames take more work to decode than others. It takes more processing power to consistently decode of 1 frame per frame time than to decode 10 frames per 10 frame times...the buffer gives the decoder some slack to handle occasional more difficult frames, catching up on the easier ones. By using more RAM and higher latency you can use a cheaper, slower, lower-power CPU. But this adds another considerable chunk of latency...it's not something you want in the loop when working with an interactive user interface, remotely operated equipment, etc.

And as the economics of the system were explained to me, they'd rather spend $200 million on a spacecraft and $50 million on a ground station so that they can shave $10 off the cost of the set-top boxes they provide for "free."  It's the economy of scale.  Beefing up the MPEG decoders and CPUs on the set-top boxes costs [some number] multiplied by the millions of units they'll need to order.  Hence the brains are in the spacecraft and in the ground stations, so that they can talk to millions of extremely stupid set-top boxes and throwaway dishes.

[ka9q]

Hence the brains are in the spacecraft and in the ground stations, so that they can talk to millions of extremely stupid set-top boxes and throwaway dishes.

Yes. And this is a nice match to formats like MPEG, where you can nail down the meaning of the bits on the channel and what the decoder is supposed to do with them, and then tinker with the encoding algorithms to tinker and improve encoder speed, channel bit rate, delay, subjective quality, etc.

[ka9q]

Yes, I tried writing a new channel-changer for our in-house TiVo satellite version, and I really couldn't improve it.

The only way I can think of doing it in a one-way broadcast system is to have multiple tuners and decoders and guess which channel you're most likely to tune to next. Doesn't seem worth it.

Meh, sorta.  In satellite systems you often not only have to change the RF tuner to a new frequency, you also have to change the feedhorn to a different polarity:  horizontal, vertical, circular-left, or circular-right.  And with multiple feedhorn systems sometimes you need to connect a different feedhorn to the backhaul in order to access a different spacecraft.  So polarity changes, frequency changes, feedhorn changes, PLL sync, do take a significant amount of time in the worst case.

Those are all fast operations. Polarity switches are electronic; you send a signaling voltage up the coax and it changes.  Multi-feed dishes are common for DirecTV and similar systems, so again the switching is instant. Retuning is almost as fast. The demodulator and decoder take a little more time, but their lockup times are in terms of channel bit times. The data rate is very high, so again in real terms they're very fast.

As far as I've ever been able to tell, the delay is all in the MPEG decoder and its requirement to buffer up I frames so it can decode between frames using pictures from the "future".

Indeed and that's still typically quite a bit longer than the electronics resychronization time.  In addition most systems want to buffer the stream a bit too in RAM.

Buffering is the only way to smooth out the random fluctuations in bit rate to avoid hitting the bit rate caps too often. The greater the delay, the better the subjective quality (with diminishing returns).

Frame type mixing is a black art for satellite systems.  One technique, for example, mixes content such as CSPAN on the same transport stream as other streams such as ESPN.  Sports programs typically have dynamic content and require a higher key-to-intermediate ratio than Talking Head programs that typically just aim the camera and some droning blowhard.  Those programs don't require many I-frames, and so they're typically sent only as often as customer tolerance allows for the decoder and buffer latency.  Not every program takes the same fraction of the available bandwidth in a transport stream, so over time they can be load-balanced.

I've wondered about that. It's a classic statistical queueing problem. As I said, the longer the queue the more you'll smooth out all those statistical fluctuations and the better you'll do at the expense of greater latency.

I used to watch CNN via DirectTV during shuttle landings at Edwards while also listening on UHF (easily heard down here in San Diego while at high altitude). There was an amusingly long delay between hearing them direct on UHF and hearing them on TV. I could only begin to count all the likely delay sources: multiple satellite hops, multiple MPEG codings, etc.

Since some consumer satellite systems also incorporate internet-by-satellite, this might be an option.

Even if you had the capacity to unicast data to each customer during a channel change, you've also got the extra speed-of-light delay. I don't think it would work. It's a good match to a terrestrial IP-based system like U-verse, though. I'm surprised they don't push it more in their advertising.

[smartcooky]

I came across this expression at JREF the other day. I thought it applies very well to a number of HB's I have encountered;

"Definition: Fractal Wrongness

The state of being so wrong at every conceivable scale of resolution, that from any distance, their world view is incorrect. Even if you zoom in on any small part of that person's world view, that part is just as wrong as the whole world view.

Debating with a person who is fractally wrong leads to infinite regress, as every refutation you make of that person's opinions will lead to a rejoinder full of half-truths, leaps of logic, and outright lies, that requires just as much refutation to debunk as the first one. It is as impossible to convince a fractally wrong person of anything as it is to walk around the edge of the Mandelbrot set in finite time."

IMO, it applies beautifully to both Jarrah White and Heiwa. Any others?

[ka9q]

Hunchbacked. Definitely.

[frenat]

I came across this expression at JREF the other day. I thought it applies very well to a number of HB's I have encountered;

"Definition: Fractal Wrongness

The state of being so wrong at every conceivable scale of resolution, that from any distance, their world view is incorrect. Even if you zoom in on any small part of that person's world view, that part is just as wrong as the whole world view.

Debating with a person who is fractally wrong leads to infinite regress, as every refutation you make of that person's opinions will lead to a rejoinder full of half-truths, leaps of logic, and outright lies, that requires just as much refutation to debunk as the first one. It is as impossible to convince a fractally wrong person of anything as it is to walk around the edge of the Mandelbrot set in finite time."

IMO, it applies beautifully to both Jarrah White and Heiwa. Any others?

Anything at the Clues forum

[Echnaton]

That has a passing resemblance to one of my in-laws.

[twik]

I notice a couple of strange commonalities among some of the more persistent posters on the pro-hoax side:

1. An inability to stay on topic. I can't believe that they have all learned intentionally to use the Gish Gallup as a diversionary tactic - I think many are led to their HB position because they go "oh, SHINY!" at every "anomaly" and don't try to come up with a coherent position.

2. An inability to keep their computers running. Far be it from me to speculate on what websites these people have been visiting, but several of them claimed that they could not respond with evidence because "you guys hacked me," and left them with only the ability to post non-relevant materials.

3. The inability to follow a line of thinking to its conclusion without saying, "wait, this doesn't make sense." So, we have people who start out claiming only that "a few people" would have been necessary to pull off a self-contained hoax, and ending up with a position that the Cold War, and most of the events of the 20th century, were a massive illusion created by the Illuminati.

[Nowhere Man]

I came across this expression at JREF the other day. I thought it applies very well to a number of HB's I have encountered;

"Definition: Fractal Wrongness

The state of being so wrong at every conceivable scale of resolution, that from any distance, their world view is incorrect. Even if you zoom in on any small part of that person's world view, that part is just as wrong as the whole world view.

Debating with a person who is fractally wrong leads to infinite regress, as every refutation you make of that person's opinions will lead to a rejoinder full of half-truths, leaps of logic, and outright lies, that requires just as much refutation to debunk as the first one. It is as impossible to convince a fractally wrong person of anything as it is to walk around the edge of the Mandelbrot set in finite time."

IMO, it applies beautifully to both Jarrah White and Heiwa. Any others?

That quote came straight from RationalWiki.  Add Patrick "Dr. Socks" Tekeli to the list.

Fred