AGOCG logo
Graphics Multimedia VR Visualization Contents
Training Reports Workshops Briefings Index
This report is also available as an Acrobat file.
Next Back [Top]

Desktop Video AGOCG Report

ATM


Asynchronous Transfer Mode can be used like a phone line by attaching a conventional CODEC that assumes a fixed bandwidth with a point-to-point link. A video server can be implemented in the same way, with a separate circuit for each user.

One of the major incentives for developing ATM technology was the need for a variable-bit rate network. The work on high capacity fixed-bit rate was more or less abandoned five years ago.

In the current ATM/B-ISDN set of standards, it may appear possible to request, as a special case, a fixed bandwidth channel. However, the transmission network knows nothing about this; the transmitter supplies a continuous stream of data cells, rather than a `bursty' one, and it is the receiver's business to even out small variations in transfer delay, to provide a perfectly steady bit rate to the application.

If the transmitter is supplying a varying rate of data cells, the utilised channel capacity may vary, say, from one cell per several days or more, up to more than 500 Mbps (with a B-ISDN 622 Mbps raw capacity interface) if other users do not need it.

In order not to risk lost data cells at saturation conditions, it is possible at call set-up time to request a certain rate of "protected" capacity; the network should then do whatever is possible get those cells through without loss. More than the protected data may be transmitted, but if the net is loaded to full capacity some may be lost. Far less than the protected amount (or nothing at all) may be transmitted and other users can therefore utilise the `spare' capacity but must stop and wait when protected traffic arrives. A plain PCM phone channel will request 64 Kbps protected capacity, will make use of exactly that much never more, never less. However, that is a peculiarity of phones and other devices developed for fixed bit rate networks. It does not imply that every underlying network is fixed bit rate.

For video applications, ATM has clear advantages. When a scene changes rapidly, a very low resolution new image can be immediately transmitted as a series of `megapixels'. Immediately thereafter the megapixels start cracking into smaller pixels, adding more detail, in multiple steps. At the same time, the colour rendition improves gradually as the channel capacity permits the palette to be updated. If the change affects the entire picture and it contains a lot of detail, the picture is not perfectly stable until after half a second or more. If a new large change occurs before the update is complete, the remaining details are skipped and a new (initially) coarse image, or partial image, is started.

For video, therefore, an ATM channel can be opened with sufficiently high guaranteed bandwidth to ensure a "satisfactory" picture quality. This of course depends a lot on application for videophone, 64 Kbps is the minimum even under high network load. If network capacity allows, there is a great benefit in going temporarily to, say, 200 Kbps this will reduce the delay before all details are in place from somewhere below a second to a few milliseconds, but is not essential. For broadcast quality, 384 Kbps would be a suitable minimum (384 Kbps was the only bit rate in the first edition of H.261), for HDTV perhaps 2 Mbps. Furthermore, the loss characteristics of an ATM channel are quite favourable for video compression. The transmitter may choose which data to protect (up to the guaranteed capacity), for example those cells carrying coarse image data, while unprotecting detail information.


Next Back [Top]

Graphics     Multimedia      Virtual Environments      Visualisation      Contents