Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Tom Metro wrote: > Mark J. Dulcey wrote: >> Addressable taps don't work with digital cable. In the digital feed >> there is not a set frequency for a given channel; many channels are >> multiplexed together. If you blocked a frequency range, it would take >> out some channels that the subscriber is supposed to get along with >> the ones that he is not. > > I'm aware of that, and you're right. A traditional programmable tap > would be a blunt instrument and require the cable company to coarsely > partition the spectrum. > > But that's not to say the equivalent couldn't be developed for digital > channels. It would just be more challenging and costly initially. The equivalent of a programmable digital tap would probably cost nearly as much to manufacture as a cable box, as it would have to have just about all of the intelligence. (Plus it would have to be weatherproofed, so it might cost MORE to make.) It would be a duplicated cost from the point of view of the cable company, as the cable box would still have to have all the same stuff in it. Sorry; I just don't see it happening. I think we're just going to have to deal with the fact that ClearQAM isn't going to happen and figure out how to get the industry to play nicer with cable boxes. We also need to push for the removal of digital output restrictions so that our personal recorders can work without decoding and re-encoding; that will require legislative intervention, as the cable companies and the content companies won't go along willingly. Personally, I think the whole HDMI/HDCP thing is silly anyway; it's a prime example of factoring the problem incorrectly. People are busy trying to figure out how to make very high bandwidth wireless links to work so that they can move around uncompressed high-definition video. But since nearly all of the program sources for HD are compressed to begin with (the exception: output from computers and game consoles), why are we trying to do that? The HD decoding should be inside the MONITORS and television sets, not the PVRs and DVD and Blu-Ray players; if you do that, existing links like 801.11n would work just fine, let alone future things like UWB. (801.11g would work for 1080i content but be marginal for 1080p.) [plaintext with (the exception: output from computers and game consoles), why]
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |