kwe@bu-it.bu.edu (Kent England) (02/08/91)
> From: barmar@think.com (Barry Margolin) > Newsgroups: comp.protocols.tcp-ip > Subject: Re: summary on transferring motion picture over IP > Date: 6 Feb 91 21:08:42 GMT > > I think > it is safe to expect that a protocol for real-time digital video > transmission would use compression techniques. ... 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. > I was impressed by Van Jacobson's 40-to-1 compression of TCP, using detailed information about the structure of TCP. I'm sure that something similar is possible for video sequences, using detailed information about the structure of video. The fascinating thing to me about compressed video is that real-time compressed video transfer dynamics will probably be nothing like uncompressed video or voice data streams. What is the maximum instantaneous bandwidth required to support these efficient real-time compression techniques? Do efficiently compressed video datastreams require reliable transport or minimum latency variation? What maximum latency and delay variance can they accept and still work acceptably in real time? What effect does lossage or error have on the final image? I would be interested in leads to research on what expected real-time compressed video technology will minimally demand of the underlying network. Does efficiently compressed video still require ST, for instance? --Kent
dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) (02/18/91)
I think that there are two problems with *REAL TIME* video: variation of delay and synchronization. If the delay between packets varries too much, the picture would jump (like the strobe lights at your old disco parties) like crazy, causing Excedrin headache #423. if you have synchronization problems (voice and video arriving out of sync), it looks like a badly dubbed movie (remember the Hercules skitt on Saturday Night Live?). Either way you irritate the users. Note that ethernet doesn't look good for problem #1. Maybe nothing is (FDDI II? Now how much would you pay ...). I think these problems are not so severe if you're not going real-time. I don't have references about video, but I do have some performance modeling results of FDDI synchronous token stuff. Send me your U.S. Postal address if you want 'em (I only have hard copy). - Ted ----------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Rd./Suite 250 | fax: +1 301 381-3320 Columbia, MD 21046 USA | voice mail: (800) 233-1485 x4436 ----------------------------------------------------------------------------- "These opinions are my own, and not necessarially those of Network Systems Corporation."
gsb1@forth.stirling.ac.uk (Mr Gordon S Byron) (02/23/91)
Could you summarise your responses please as I am very interested in where this technology is going, what we can reasonably expect from it within the next five years and how soon implementation would be advisable. we have fibre optic cabling put in and hope to use Compressed Video Transport as soon as it is finacially and technically feasible. Thanks for any responses ******************************************************************************* Snailmail: Gordon Byron, Arts Computing Advisor,Pathfoot Building, University of Stirling,FK9 4LA Stirling, Scotland, UK. Voice: 0786 73171: Ext 7266 Fax: +78651335 *******************************************************************************