On Thursday 22 February 2007 07:36:23 sinkam wrote: > > From: Peter TB Brett <[EMAIL PROTECTED]> > > Your idea is a nice one, but entirely impractical, I'm afraid. > > Dear Peter, > you should not afraid. They already sell HD-DVDs and provide > digital TV. Try to explain them that is 'entirely impractical > idea', I think they will wonder :-) > > My idea is to re-combine popular _exisiting_ technologies. Moreover, > a few years later monitors/TVs with connector for digital TV will > appear (all analog TVs contain TV recievers, why digital TVs not ?), > i.e. offered solution will unevitably implement by someone.
Analogue TVs use relatively simple analogue circuitry to demodulate the signal, and the signal is sent uncompressed and unencrypted. Digital TV is typically highly compressed, transmitted using a orthogonal frequency division multiplex, with temporal interleaving in order to make error correction work better. Not only that, but it is often encrypted in order to make sure that only subscribed users are able to receive the signal. There are a wide variety of different methods used, so each network tends to distribute its own hardware to subscribers designed to work with their transmissions. Ergo, integrating digital TV receiver hardware into actual TV sets would inflate prices horrifically. Of course, digital/satellite TV networks might decide to standardize their systems, but that would reduce customer lock-in, which they consider to be a *bad* thing. > > Sorry, these numbers are entirely bogus. > > What numbers ? > > > The correct ones are: > > 2048x2048 is resolution of display supported by OGC. > > 24 bits per pixel of colour data > > 60 frames per second > > = 6.04 Gb/s = 755 MB/s (or approx. 8 gigabit ethernet links) > > You are absolutely right, but wrong place. I wrote about > bandwidth HD-DVD loader generates, your numbers describe > bandwidth on LCD matrix connector inside monitor. > Any DVD player contains convertor, that unpacks signal > from loader into signal for matrix. <snip> My numbers describe the data that must be sent over the video connector (DVI/HDMI/SVGA etc). The screen does most certainly not contain the logic for decompressing and motion-compensating the MPEG stream. All of that must be done before the data is sent over the video connector. You said, "You should implement in OGP card common Ethernet and nothing more." So you want the card to render 3D scenes at 2048x2048, highly compress them in REAL TIME, send them over an (relatively noisy) ethernet cable, then uncompress them, then feed them into a DAC for sending over DVI? Snell & Wilcox make a device that can do real-time HD composition and h.264 compression. It has a very reasonable specification: 8 large FPGAs, 64 GB of RAM and 200 W of power. The *biggest* problem in MPEG compression -- the part that takes the most time & processing power -- is identifying which bits of the image have stayed the same and can be reused. Once again, your idea is impractical. Peter -- Fisher Society committee http://tinyurl.com/o39w2 CUSBC novices, match and league secretary http://tinyurl.com/mwrc9 CU Spaceflight http://tinyurl.com/ognu2 v3sw6YChw7$ln3pr6$ck3ma8u7+Lw3+2m0l7Ci6e4+8t4Gb8en6g6Pa2Xs5Mr4p4 hackerkey.com peter-b.co.uk
pgpeygirg4pCF.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
