Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.protocols.tcp-ip Subject: Re: summary on transferring motion picture over IP Message-ID: <1991Feb6.210842.5967@Think.COM> Date: 6 Feb 91 21:08:42 GMT References: <1991Feb6.140207.25450@bronze.ucs.indiana.edu> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 44 In article <1991Feb6.140207.25450@bronze.ucs.indiana.edu> Zhen Li writes: >From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston) > >Count up the number of pixels in one frame, multiply by the >number of bits behind each pixel, then compare to the 10 Mbits/sec >serial bit rate of Ethernet. I think you'll find a major >mismatch. Assuming 1k by 1k pixels per frame, 24 bits per pixel, 30 frames per second, that's 720 Mbps, apparently about two orders of magnitude off Ethernet speeds. However, this is not really a fair comparison. I think it is safe to expect that a protocol for real-time digital video transmission would use compression techniques. I'm no expert in data compression, but it seems like it should be possible to get very high compression ratios for motion pictures. First of all, within a frame you can do quite well with techniques based on run-length encoding and/or extrapolation. And the differences between successive frames are generally very small, so I would expect the protocol to only send the changes, rather than entire frames. And if the compression algorithm makes use of good image processing techniques, it could even recognize shifts of the entire background (very common, due to camera panning) and send a short encoding to compensate for it, rather than sending all the pixel-by-pixel differences. Colors can be encoded in fewer bits, using color maps (sending only the changes as they occur) and/or Huffman coding. Of course, all this compression requires lots of compute power. I'm not sure it could currently be done in real time, so I don't think you could put an Ethernet between a video camera and monitor. However, if the goal is to allow downloading from a server, this wouldn't be a problem. The video could be compressed in batch, and this compressed version would be stored in the database and downloaded directly to the monitor. Decompression is generally much easier than compression, so it can probably be done in real time There's a guy claiming to have developed technology to send videos over voice-grade phone lines, which are several orders of magnitude slower than Ethernet. He must be using techniques like these, and more. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar