When live, or other real-time play is required, the client and server need to negotiate the size of the data transferred, and thus the quality of the movie, to cope with variations in available bandwidth on the network. Several ad hoc solutions are implemented in various programs, but standards are beginning to emerge on the Internet, most of them currently as drafts.
RTP [53] defines functionality for use in applications transmitting real-time data, such as audio and video, over multicast or unicast network services. The functionality includes identification of media type, sequence numbering and timestamping. The data transfer may be aided by a control protocol (RTCP), providing data delivery monitoring, and participant identification for on-going sessions. RTP and RTCP are typically run on top of UDP, but other transport protocols, such as TCP, may also be used.
Resource reservation and quality of service are not addressed by RTP, but are left to lower layers. Likewise, RTP does not guarantee delivery or prevent out of order delivery, but the sequence number provided by RTP allows the receiver to reconstruct the sending order.
RTP is considered a framework for new protocols, and is thus not directly usable. A header template is defined, but the format of the data to be transferred, the payload, is undefined. Application developers will have to create profile specifications and payload format specifications extending RTP to cope with the medium in question. A profile specification defines payload type codes, and any extensions or modifications to the original RTP. Profiles for audio and video are defined in [54]. The payload format specification defines how the payload, in our case the video data, is to be carried in RTP. Currently, payload formats for MPEG [55], H.261 [56] and JPEG [57] are defined, while others are being developed.
CU-SeeMe is a software package
featuring it's own, proprietary, and partly
undocumented
, compression scheme. The package may be
used for video telephony and conferencing on Macintoshes and PC's, and
has gained some popularity, since the data transfer rate is suitable
for modern modems, making the program usable for most people with an
Internet connection. The package was originally developed at
Cornell University, but a
commercial version
is also available.
In [58] Tim Dorcey, one of the developers, gives a quick
overview of how CU-SeeMe works: A frame is resampled to 160 
120
pixels, with each pixel quantized to 16 levels of gray. Following
that, the frame is subdivided in blocks of 8 8 pixels. A block is
marked for transmission if it differs sufficiently from the previous
transmitted block at that location. The difference is measured as the
sum of the absolute values of all 64 differences, with an extra
multiplicative penalty for differences in nearby pixels.
Before transmitting a block, it is compressed using a simple, ad hoc reversible compression scheme developed by the program authors. The goal of the scheme is to be able to compress and decompress fast. To cite Tim Dorcey, ``What it lacks in mathematical elegance, it makes up for in quickness''. Compression builds on the assumption that a row inside a block is often similar to the row above it. A 32 bit word is created by combining the pixel values in a row, and the difference with the above 32 bit word is coded using 4, 12, 20 or 36 bits, including 4 bits giving further coding details. The compression scheme is said to reduce the amount of data to transfer by about 40%.
The program uses UDP at port 7648 for transferring image frames between two participants [59].
In it's original form, CU-SeeMe can be used for one-to-one communication only. Using reflectors however, the usability may be extended to real, multi-participant video conferencing. A reflector is a specialized program running on a Unix host, capable of multicasting CU-SeeMe packets.