Zhen Li <lizhen@silver.ucs.indiana.edu> (02/06/91)
Since I posted inquiry about transferring video over IP I
have received more requests for summary than answers to
the question. Following is what I have got so far.
Many thanks to those who provided helpful information. I
appreciate all of your help. Thanks!
Jane
--------------------------------------------------------------------------
From: ckollars@east.sun.com (Chuck Kollars - Sun Technical Marketing - Boston)
I've seen experimental products that can handle about 1
4x5 inch 8-bit color image every 2 seconds. The problem is
not the TCP/IP protocols per se, but the fact that they
"typically" run over network media that are one or two orders
of magnitude too slow for animated/video images.
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.
--------------------------------------------------------------------------
Claudio Topolcic <topolcic@bbn.com>
I don't have exactly the answer for you, but we routinely send
live video across a DARPA-sponsored network in support of video conferencing.
The network is called the Terrestrial Wideband Network, and we have multi-protoc
ol
routers that implement the ST protocol (formerly IEN 119, and now RFC 1190) as
well as IP. This is a connection oriented internet protocol intended to support
real-time applications such as voice and video. We use commercial video codecs
to compress the video down to about 128 Kbps
--------------------------------------------------------------------------
From: I.Wakeman@cs.ucl.ac.uk
in reply to your request about video over IP, a fair amount of work is currently
going on in this area, between UCL, BBN and others, using the ST protocol in
the ARPA Wideband Terrestial Network (SIGCOMM90 paper). Currently ST is running
separately from IP traffic, but real soon now, ST will be running over IP in
the BBN gateways, and in BSD socket code that Craig Partridge is writing. Other
work of interest is at UCB on DIstributed Continuous Media, David Anderson.
There's also been an RFC on time critical constraints on data networks -
something like 91 in the current series.The BSD people are interested in producing
a UDP variant that can carry time critical data using time stamps.
...
anyway, two rfcs of interest are:
1193: client requirements for real-time communications services
1192 Experimental Internet Stream Protocol (ST 2)
THe work at UCB has at least 3 tech reports on Meta-Scheduling,
UCB TR 90/597 Meta-scheduling for Distributed continuous media - Anderson
TR 90/596 Abstractions for Continuous media in a network window system
Anderson, Govindan, Homsy
TR 90/599 Implementation Issues for a Network Continuous Media IO Server
as above.
These three deal with general issues for synchronous data over packet networks,
as do many, many other papers
Specific to IP, I don't know of any specific papers, other than experimental
efforts to put ST inside IP.
--------------------------------------------------------------------------barmar@think.com (Barry Margolin) (02/07/91)
In article <1991Feb6.140207.25450@bronze.ucs.indiana.edu> Zhen Li <lizhen@silver.ucs.indiana.edu> 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