h a l f b a k e r yI never imagined it would be edible.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Digital TV is great isn't it, kids. You get loads of channels and the picture quality is, well, perfect. Except when it isn't. Every now and then, due to a glitch in the hardware, a 'plane flying overhead or a bird nesting in your minidish, the signal weakens for a few seconds causing the sound to disappear
and the picture to break up into a series of large green and red squares.
What the Cable/Satellite company could provide is a feedback system where your receiver tells your TV provider (via ADSL, DSL, Cable or unmetered dialup) which bits of the image were corrupted and you are supplied with the missing bits of the image.
Your receiver buffers the incoming signal so that it has enough time to request, receive and correct missing data and you watch the footie safe in the knowledge that you will never miss that goal again because of next-door's frisbee.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Destination URL.
E.g., https://www.coffee.com/
Description (displayed with the short name and URL.)
|
|
Or they should just have gotten HDTV right in the first place. |
|
|
What we have here is classic communication theory. We have some information that needs to be received reliably at some rate B bits/second. We have a channel which can carry signals with an information rate of C b/s. However the channel also has noise, interference, attenuation, and a host of other effects that cause errors at a rate E b/s. We overcome the error rate by using redundancy in the signal. Instead of sending B b/s, we send B+R b/s (where R>E and B+R<=C). |
|
|
Now, there's nothing to prevent a person from sending that extra R of information through a separate channel such as a phone line or DSL connection (as you suggest). But as long as the channel has a big enough C, it is usually easier and cheaper to send it all in the same channel. |
|
|
Actually, the broadcasters already do this. Your digital TV wouldn't look anywhere near as good as it does if they didn't. The problem is that extra bandwidth (in any form) causes extra expense for the broadcaster. So the real problem is one of economics. How much money are customers willing to pay for what level of performance? Unfortunately for you, the price point for the market as a whole is somewhat lower than for you personally. |
|
|
How about if the broadcasters set aside a special channel (or a set of fractional channels) just for the redundant bits of certain other channels? They could encrypt this redundancy channel and sell decryption keys as a premium service, like they do with pay-per-view already. Don't want to risk missing that exciting moment when your team scores the winning point? Buy some redundancy. Don't mind a few glitches? Buy only the basic channel. |
|
|
To expand on BigBrother (and prove that 2 years working in communications computing weren't all to waste): |
|
|
In error correction, the two main techniques are forwards error correction, where redundant data is encoded in the signal (using block codes like Reed-Solomon, or convolutional codes like Viterbi) and the method st3f is suggesting, where positive or negative acknowledgements are used to request retransmission of corrupted information. |
|
|
To add to BigBrother's annotation, the big problem with this idea is that to detect errors in the transmission it is necessary to include additional information in the channel (some form of parity, checksum or CRC), and then additional bandwidth is required for the extra communication back-link and the supplementary link with the re-transmitted data. The overheads for parity info plus re-transmitted data will in most cases be less efficient than using a forward error correction code. |
|
|
There are however situations where retransmission is more effective: when data is divided up into packets as for IP transmission, the most likely outcomes are receipt without errors, or complete packet loss, and in this case, retransmission is the most efficient method, especially if small blocks of data (only a few packets) are being sent. |
|
|
However, if you're worried about losses lasting a few seconds, your viewing is going to be perpetually delayed a fair amount of time after transmission, allowing for buffering, retransmission requests, and retransmission once the channel is usable again. Maybe this isn't always significant, but sometimes it might be, and as BigBrother says, transmitting extra redundancy alongside the main data will be more effective. (And forward error correction won't tie up your modem's bandwidth either.) |
|
|
How much extra would you pay for a reciever with this functionality? Seems to me that adds a *lot* of complexity to the receiver: how long do you buffer your high-bandwidth signal in anticipation of a low-bandwidth and possibly high-latency correction? What do you buffer it to? More RAM? More cost. A hard drive? More cost. In either case, more software on the box -- more cost -- and more head-end services to support it -- more cost. |
|
|
On the other hand, go far enough down that route and maybe you end up with a smarter TiVO box that not only records programmes but also cleans up the recordings for you... |
|
|
As BigBrother points out, DTV already has a lot of error correction and recovery built into it. Error correction takes place in the demodulator, where 16 bytes of error-correction are applied to each 188-byte packet. Error recovery is inherent in MPEG-2 video: although most frames are predictive (diffs from the last frame) or bi-directional predictive (diffs from the last frame and the next key frame) enough keyframes are transmitted that glitches heal themselves rapidly. |
|
|
I think a TiVo box that could record the same program in 2 or more transmissions and combine the results should be a possibility. Every program in the UK seems to be repeated within the week (if not in 24 hours), either on analog terrestrial or on digital. |
|
| |