Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!bu-it.bu.edu!kwe
From: kwe@bu-it.bu.edu (Kent England)
Newsgroups: comp.protocols.tcp-ip
Subject: Compressed Video Transport Requirements
Message-ID: <74148@bu.edu.bu.edu>
Date: 7 Feb 91 17:34:48 GMT
References: <1991Feb6.140207.25450@bronze.ucs.indiana.edu> <1991Feb6.210842.5967@Think.COM>
Sender: news@bu.edu.bu.edu
Reply-To: kwe@bu.edu
Organization: Boston University Information Technology
Lines: 40

> 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