Chapter Contents

 

3.0 Desktop Video

 

3.1 Desktop Videoconferencing

3.1.1 Call Management

3.1.2 Shared White Board

3.1.3 Shared Applications

3.1.4 Audio Concerns

3.1.5 Video Concerns

 

3.2  Internet Video Conferencing

3.2.1 CU-SeeMe

3.2.2 Mbone

 

3.3 Available Equipment

3.3.1 Intel ProShare Personal Conferencing

3.3.2 PictureTel

 

3.4 Standards

3.4.1 H.261 [Px64]

3.4.2 H.263

3.4.3 H.320

3.4.4 H.323

3.4.5 H.324

 

3.5 T.120

 

3.6 DVB

 

3.7 Video Players

 

Assignment Questions

 

For Further Research

 

 


3.0   Desktop Video

 

Objectives

The purpose of this brief introduction is to:

   Examine some of the non-technical issues in supporting desktop video

   Determine who is offering what products today

   Examine some of the existing standards such as H.261

 

Several different applications make use of video at the desktop. They include:

   Television viewing

   VCR playback and editing

   Video clip viewing [via internet or CD]

   Video conferencing

Of these, the most complex application is desktop videoconferencing.

There are three primary ways to bring video to the desktop:

   Use of a video overlay

   Increase CPU processing speeds

   Use of data compression

In the overlay approach, the image is displayed in an open window bypassing the PC bus and memory. This doesn’t integrate the video signal into the computer processing environment.

Using compression can reduce the transmission bit rate requirements. If this function is provided by specific hardware, the speed requirements of the CPU, memories, and disk drives can be reduced.

3.1             Desktop Videoconferencing

Chapter 1 Digital Video Basic Principles

Audio, Video, & Document Conferencing

Real Time Video on the Internet

Video Enabled Web Services by DEC

http://www2.ncsu.edu/eos/service/ece/project/succeed_info/larettin/thesis/toc.html

Videoconferencing has been used in the business world for quite some time. Although it can save travel time and expense it may not be for everyone. A typical videoconferencing facility may cost upwards of 50K$ to equip and the high-speed lines cost hundreds of dollars per month.

Because of the increasing power of personal computers, it is now possible to provide some of these features at the desktop. Each user must have a camera, microphone, interface cards [audio, video, network], and applications specific software.

In order for two videoconferencing products to work together, they must achieve consensus on four points:

   Data transport

   Video compression/decompression

   Audio compression/decompression

   Command, control, and data framing

Because of these diverse needs, videoconferencing standards are developed as a family of recommendations bundled together to define the service.

The H.320 standard [Px64], addresses all of the above needs over circuit switched channels. One common implementation provides an aggregate bit rate of 384 Kbps by using an inverse multiplexer to combine three ISDN channels.

The H.324 standard specifies video conferencing over POTS lines. It is possible to design devices based on this standard, which are completely stand-alone. However, it is also possible to design a device that uses a television set as the display device.

There are a number of different ways to address the need for compression and each manufacturer seems interested in promoting their own technique. This does not necessarily create a problem, as long as everyone agrees of a standard method of decompression.

Often times, manufacturers will attempt to develop standards on their own. These proprietary solutions sometimes arise because the company has a greater vision and insight than others. On other occasions, they arise because companies simply want to lock in their customers to their own product line.

SMIL (pronounced smile) stands for Synchronized Multimedia Integration Language. It is a markup language (like HTML) and is designed to be easy to learn and deploy on Web sites. SMIL was created specifically to solve the problems of coordinating the display of a variety of media (multimedia) on Web sites. By using a single time line for all of the media on a page their display can be properly time coordinated and synchronized.

3.1.1    Call Management

Most videoconferences are between two locations or parties. On occasion, it may be desirable to add locations or persons to the call in progress, or to establish an independent simultaneous connection.

When multiple parties are involved, the image quality will generally deteriorate somewhat. One way to prevent this is by prioritizing the video signals. A simple way to do this is give priority to the talker, another is to provide a chair person.

It is also beneficial to provide the audio signal with a higher priority than video. Conferences can continue even if video is not present. However, they cannot continue if the audio quality degrades below some acceptable level.

Adding participants to a circuit switched call requires a MCU. Besides this, certain procedures are needed to implement a three-way conference. Establishing a multi-party call on a packet system is much easier. All that is needed is access to a reflector site, which duplicates the entire incoming audio and video packet, and rebroadcasts them to each participant.

There must be some way to determine what resources will be shared with the new party. Another problem is created if the new party does not have the hardware or software needed.

Multiple concurrent calls can create some concerns. It is sometimes beneficial for one part to be able to consult privately with an advisor who is hidden from the other conference participants. This has to be done in such a way to prevent eavesdropping.

Under certain circumstances, the originating party on a conference call may want to leave the discussion and allow the other participants to continue. This creates billing problems, when long distance charges are associated with the remaining connections.

3.1.2    Shared White Board

This arrangement allows all participants to draw or edit text, with the combined results being visible to all. Unfortunately, there is no standard definition of white board capabilities. Most implementations allow the white board to contain the window of an open application.

There are two fundamental methods of editing a common area. On creates display layers, one for each conference participant. However, this does not allow any participant to even slightly modify the work of someone else.

A second method uses only one layer but allows each participant to select a color to distinguish each other’s contributions. One of the problems with this approach is the serialization of data. The drawing orders must be transmitted to each participant in the same sequence.

Some systems treat the white board image as a series of pels while others treat them as a collection of graphic objects. The former is easier to implement than the latter however, drawing a pel obliterates the original image and there is no way to undo it, this is not necessarily the case with graphic objects.

Another problem, which must be considered, is the pointing device used to highlight items in a shared window. The principle control device is the mouse. A mouse is suitable for freehand drawing, writing comments, or adding a signature.

The standard for whiteboard and document sharing interoperability is T.120.

3.1.3    Shared Applications

One of the best uses for desktop conferencing is to allow participants to share applications such as spreadsheets, databases, and text documents. Allowing others to see an open text window may be less difficult than providing real time video however applications sharing is quite different. Each participant would probably have to be capable of running the same application that created the original document.

Each party should be able to move the cursor on the shared screen in order to point out certain features. It would also be desirable if either party could edit the displayed document. However, it may be that not all participants will have the necessary application or even need to access it. This creates problems for software vendors.

When the call is terminated, it may be desirable to keep the open application active. This suggests a certain flexibility in the applications software.

Ideally, participants should be able to scroll though various parts of the document and change any part of it. If multiple users are simultaneously editing the same place in a document, the serialization problem reemerges.

In low bandwidth connections, it may be advantageous to forgo the video connection and leave only the audio and document sharing active.

3.1.4    Audio Concerns

If a built-in speaker and microphone system is used, the PC can be configured to act as a hands free telephone set. This has a few problems associated with it. In most cases, the received audio signal is muted when you talk into the microphone. This means that it is difficult for others to make comments or break in. The alternative is to use sophisticated echo cancellation circuitry which will allows both transmit and receive paths to remain active, while preventing the feedback which would normally occur.

In either case, the microphone will go active if the background noise is high enough, and broadcast whatever it is picking up to everyone else.

One way to eliminate some of these concerns is to use a headset. Even this has problems since it limits the person’s movement, and the cable can easily interfere with the keyboard or mouse.

3.1.5    Video Concerns

The ideal place to position a camera is where the screen is. The next best choice is to place it above or the side of the screen. The camera needs to be detachable since it may be desirable to highlight some feature other than the speaker.

The quality of the camera, frame rate and video compression algorithms have a significant impact on user acceptability. It is also important that the audio be in sync with the video. This does require some attention because the video requires a significant amount of signal processing and therefore has a greater latency than the audio.


3.2     Internet Video Conferencing

3.2.1        CU-SeeMe

http://www.cuseemeworld.com/

http://designserver.mae.cornell.edu/cuseeme.html

http://www.rocketcharged.com/cu-seeme/

http://

CU-SeeMe is an Internet videoconferencing program developed ar Cornel University and now marketed by http://www.wpine.com/ and operates on either a Macintosh or Windows platform using an IP network connection. With CU-SeeMe each participant can decide to be a sender, a receiver, or both. Connections with 3 to 8 participants require access to a reflector site running on a UNIX machine.

CU-SeeMe uses simple but efficient video frame-differencing and compression algorithms, to provide videoconferencing capability to low cost desktop computers.  The most recent versions of CU-SeeMe for the Macintosh allow for the exchange of text and slides.

CU-SeeMe video is represented on a 16-level gray scale, and supports 2 resolutions: 320 x 240 pixels and 160 x 120 pixels. CU-SeeMe also offers crude white board capabilities in the form of a “slide window” that transmits full-size 8-bit gray scale still images and allows for remote pointer control. A plug-in architecture has also been developed to allow 3rd parties to write binary modules, which extend the capabilities of CU-SeeMe.

Two-party CU-SeeMe conferences can be initiated by one participant connecting directly to the other. Larger conferences require that each participant connect to a “CU-SeeMe reflector.” A UNIX computer running CU-SeeMe reflector software serves to replicate and re-distribute the packet streams.

This article[1] presents a brief overview of two central components of the CU-SeeMe software: Conference Control and Video Encoding.

NASA uses CU-SeeMe to broadcast events.

http://

http://btree.lerc.nasa.gov/NASA_TV/NASA_TV.html

3.2.1.1     Conference Control

Each participant in a CU-SeeMe conference periodically transmits a single packet that advertises his or her interests with respect to all of the other participants. These advertisements are termed “OpenContinue” packets.

OpenContinue packets contain the standard CU-SeeMe header, followed by general information about the originator. Then follows a set of variables requesting video, audio, slides, etc.

Reflectors examine OpenContinue packets to develop source specific distribution lists for the various media involved in a conference and then forward them to all other participants. Because the protocol requires each participant to process dynamic status information for every other conference participant, large conferences are limited to about 30 participants. It does however, provide considerable control, during smaller conferences.

The primary motivation for developing the reflector software was the lack of multicast capabilities on the Macintosh.

3.2.1.2     Video Encoding

The main objective was to devise algorithms that would be fast enough for real-time videoconferencing on Macintosh platforms. The decoding algorithm, in particular, needed to be extremely efficient in order to support multiple incoming video streams.

Video processing consists of three basic steps:

   Decimation

   Change detection

   Spatial compression

The first step in video encoding is to decimate the 640 x 480 pixel video frame down to 160 x 120, with each pixel represented on a 4-bit gray scale. In comparison to full size, 16-bit color, this represents a 64:1 reduction of data.

The user is provided with brightness and contrast controls for a 16-level gray-scale.

Next, the video frame is subdivided into 8x8 pixel squares. A square is transmitted only if it differs sufficiently from the previous square. The index used to measure square similarity is the sum of the absolute value of all 64 pixel differences, with an additional multiplier penalty for pixel differences that occur nearby to one another.

To prevent packet lost permanently altering the image, transmission is triggered if a square has not been transmitted for a given number of frames.

A lossless compression algorithm is applied to all transmitted squares. It manipulates rows of eight 4-bit pixels as 32-bit words. This maximizes performance on a 32-bit processor.

The spatial and temporal compression technique achieves around 40% compression. This is in addition to the 64:1 decimation from the original.

High packet loss reduces frame rate. Since a compressed a frame is often less than 1500 bytes, a lost packet corresponds to a lost frame. If the subject is a talking head, most squares are either changing every frame or not at all.

3.2.1.3     Enhanced CU-SeeMe

Earlier versions of this freeware product were designed for high bandwidth capable networks, using techniques such as “unicast” which sends multiple video streams to each viewer.

Enhanced CU-SeeMe, offers bandwidth compression for low bit rate links. Ongoing development includes emerging standards-based IP protocols such as IP Multicast, RSVP and RTP. These allow Enhanced CU-SeeMe to address network management and usage issues and give ISPs the ability to provide improved service.

Enhanced CU-SeeMe supports full-color video, audio, chat window, and white board communications. It can be launched directly from Web pages with a browser.

SLIP and PPP modem connections are supported; however it is recommended that you use a 28.8k modem connection or better.

CU-SeeMe can be used with most video boards that support Video for Windows. Similarly, CU-SeeMe supports Apple’s QuickTime to display video for Macintosh computers.

3.2.1.4     CUSeeMe Reflector

A reflector is a server-based application, which allows CU-SeeMe clients to have group conferences. It accepts multiple CU-SeeMe connections and reflects the video, audio, and additional data to all participants concurrently. As many as 100 participants can be supported on a single UNIX workstation. Multiple Reflector sites can be linked to create a network for larger group conferences or video broadcasts.

Reflector Features

   Supports eleven UNIX platforms including SUN, HP, IBM, Linux, and DEC,

   Available for Windows NT/95 on Intel, and Windows NT on Digital Alpha and PowerPC

   Administration -- configuration files for setting up system and network

   Conference Management -- configure, conference and control access

   Daisy chain Reflectors for large audience conferencing

   Multicast support access to Mbone

Enhanced CU-SeeMe represents an important killer application that enhances an ISP’s ability to supply a new communications vehicle to the Internet.

Videoconferencing applications use the UDP protocol instead of TCP. This makes the application responsible for error control.

UDP supports multicasting via a reflector. They improve network bandwidth utilization by efficiently managing audio and video broadcasting streams.  UDP supports interactive and live broadcasting over the Internet or corporate Intranets.

CU-SeeMe clients can also use IP multicast standards such as DSP and DSR for multipoint conferencing without a reflector. Users can easily and quickly create or join multicast conferences on multicast-enabled IP networks. This is useful for quick ad hoc conferencing needs similar to a conference phone. The reflector is better suited to having a meeting with larger groups similar to a conference room.

Conferences can be configured to be private with password protection, restricted to bandwidth usage, defined to allow users to connect for a limited time, and more. They can also be configured to report usage so that ISPs can track and bill users for the time spent in a conference, offering a new business model.

Reflectors are also bandwidth managers. When network traffic is heavy and packet loss of individual users is running too high, the Reflector can adjust on-the-fly transmission rates.

This can be done dynamically using a remote Telnet connection from anywhere on the Internet. Network managers can quickly change the configuration of a Reflector using simple Telnet commands to adjust the conference or broadcast if the network loading changes or part of the network goes down.

Users can also set minimum transmission rates that will adjust to the variety of network connections they may be using. If network traffic is too heavy for a reliable conference, transmission will remain at the lowest setting and only move up when the network is less congested.

Other products, with more advanced features, use the Internet’s Multicast Backbone, “Mbone,” for multicasting; however, they require the receiver be setup for Mbone, which is not generally available to many Internet users.

3.2.2    Mbone

http://www.mbone.com/

http://horla.enst.fr:8080/~dax/network/multicast.html

http://

The Mbone is a virtual network layered on top of the Internet to support IP multicast routing. It is composed of IP multicast islands linked by “tunnels”. The tunnel endpoints are typically workstations with operating systems supporting IP multicast.

The IP multicast packets are encapsulated to look like look like normal unicast datagrams before being sent through the tunnels. The originating router adds an IP header, and sets the destination address for the router at the other end of the tunnel. The receiving router strips off the encapsulating IP header, and forwards the packet.

A tunnel mesh links the backbone and regional networks. Then each regional network fans out to all the customer networks.

When a new network wants to connect, it makes a request and participants at “close” nodes answer and cooperate in setting up the tunnels. To keep fanout down, occasionally an existing tunnel will have to be breached to inserting a new node.

3.2.2.1     Audio and Video Bit Rates

Audio is typically coded at 64 Kbps. This would increase to 68 - 78 Kbps on the network because of packet overhead. Therefore, compression techniques are used to reduce the bit rate. Some common examples are 36 Kbps ADPCM, 17 Kbps GSM, and 9 Kbps LPC.

For slow-frame-rate video, the compression is done in software. The data rate is typically 25 - 128 Kbps.

3.2.2.2     Mbone Speeds

The anticipated traffic during IETF multicast is 100 - 300 Kbps but 500 Kbps is used for planning purposes.

The fanout of each node should be no more than 5 - 10 and only 1 or 2 tunnels should flow over a T1 line.

While most Mbone nodes should connect with at least a T1, it is possible to carry some traffic over slower speed lines. Each tunnel has a TTL threshold. By convention, higher bandwidth sources such as video transmit with a smaller TTL so they can be blocked while lower bandwidth sources such as compressed audio are allowed through.

3.2.2.3     Mbone Platforms

The most convenient Mbone platform is a Sun SPARC station it was used for mrouted development.

3.2.2.4     Mbone Multicast Routing

The mrouted program implements the DVMRP routing protocol and implements a multicast forwarding algorithm called TRPB.

MOSPF is the IP multicast extension to the OSPF routing protocol. A network of routers running MOSPF can forward IP multicast packets directly, without tunnels.

3.2.2.5     Mbone Platforms

Most of the applications have been ported to the DEC 5000, DEC Alpha, HP 9000/700, SGI Indy and Indigo, and Sun SPARC station. Some applications are also supported on IBM RS/6000 and on Intel 486 platforms running BSD UNIX. No additional hardware is required to receive audio and video on those systems that have audio built in because the rest is done in software. To send audio requires a microphone; to send video requires a camera and video capture device.

Point to point audio and video applications between two hosts use unicast addresses and routing. Conferencing with multiple hosts, requires that each host run an operating system kernel with IP multicast support. IP multicast uses Ethernet multicast to reach multiple hosts on the same subnet. A multicast router is needed to link multiple local subnets or to connect to the Mbone.

IP multicast is included in the standard IRIX kernels for SGI machines, in Solaris 2.3 and later, and in OSF/1 2.0. For PC machines running DOS or Windows, IP multicast support is included in the current release of the PCTCP package from FTP Software, but the application programs are still in development. No IP multicast support is available yet for NeXT or Macintosh.


3.3     Videoconferencing Equipment

There are numerous videoconferencing equipment vendors. Links to many of them can be found at:

http://www3.ncsu.edu/dox/video/products.html.

http://picturephone.com/acatalog/index_cat.html

http://

Since video conferencing equipment has been evolving quite quickly, it is best to go directly to the manufacturer’s website for the latest information. Some of the more interesting vendors can be found at:

http://www.wearesimply.com/

http://www.intel.com/proshare/conferencing/

http://www.picturetel.com/

http://www.microsoft.com/windows/netmeeting/

http://www.vsin.com/ 

http://www.avistar.com/

http://www.cinecom.com/

http://www.videoconferencing.com/

http://www.rsisystems.com/

http://www.vic-corp.com/

http://www.zydacron.com/

http://www.gs.com.sg/zen/

www.paradise.com

http://www.mmac.com/

http://www.vistacom.fi/

http://www.vivo.com/

http://www.vtel.com/

http://picturephone.com/

http://www.polycom.com/

http://www.videoconference-equip.com/index.htm

http://navitar.com/

http://www.winnov.com/

http://www.att.com/gov/civilian/videoserv.html

http://www.fvc.com/

http://

Many desktop video conferencing systems, such as Microsoft NetMeeting, CU-SeeMee and others, use the Internet to provide the networking infrastructure. Other systems require leasing high-speed links such as T1 or BIDSN. Yet, other systems, such as advocated by Nortel, require ATM networks.

With the widespread deployment of SONET, it is generally felt that it is only a matter of time before all systems, even desktop IP systems, will use ATM for backbone transport.

3.4     Standards

The PCWG is an industry group comprised of hardware and software manufactures as well as telecommunications service providers. Their objective is to produce an open and interoperable PCS based on a PC platform.

Development of this specification will allow PCs connected on a LAN, POTS, or ISDN facilities to share documents, applications, and audio/video communications. Ideally, this should largely be implemented in software, allowing PCs to take advantage of existing graphics and multimedia cards.

PCS will also be expanded to include new network developments such as ATM and 100 Mbps LANs.

The PCS will include other specifications such as H.320 and ISDN.

ITU AV and G Standards for Audio-Video Terminals:

ITU Document

Comments

AV.254

16 Kbps Audio

AV.321

Multipoint

G.711

64 Kbps PCM Audio

G.722

7 KHz audio over 48/56/64 Kbps ADPCM

G.723

6.5 & 5.3 Kbps Dual Rate Speech Encoder

G.728

16 Kbps Speech Encoding

 

ITU H Series Standards for Audio-Visual Terminals

ITU Doc.

Comments

H.221

Frame structure for 64 - 1920 Kbps teleservices

H.223

Multiplexing protocols for low bit rate terminals

H.230

Control and indication signals

H.231

Multipoint control for channels up to 2 Mbps

H.242

Call set-up and disconnect for channels up to 2 Mbps

H.243

Establishing multipoint channels up to 2 Mbps

H.245

Communication control between multimedia terminals

H.261

Video codecs at Px64 Kbps rates

H.263

Low bit rate video coding

H.320

Technical requirements for narrowband

H.321

Video telephone over ATM

H.322

Video telephones on guaranteed QoS LANs

H.323

Video telephones on non-guaranteed QoS LANs

H.324

Video telephones on the GSTN

 

3.4.1    H.261 [Px64]

The H.261 video coding format is more commonly known as Px64. It is designed to operate over communications links that can provide incremental bandwidth in multiples of 64 Kbps. The value P represents the number of 64 Kbps channels used, and can vary from 1 to 30. Although this format is ideally suited to operate over ISDN links, it is not restricted to them.

Px64 uses a discrete cosine transform, motion compensation, and differential pulse code modulation it minimize the bit rate and comes in two formats: CIF and QCIF.

Characteristic

QCIF

CIF

Luminance Pixels

176

352

Luminance Lines

144

288

H.261 Support

Yes

Optional

Bit Rate [Mbps]

@ 10 frames/sec

2.0 [gray]

3.0 [color]

8.1 [gray]

12.2 [color]

Bit Rate [Mbps]

@ 30 frames/sec

6.1 [gray]

9.1 [color]

24.3 [gray]

36.5 [color]

 

The chromance resolution is 1/2 of the luminance resolution. They are called intermediate formats because the video source can be either PAL or NTSC.

The H.261 standards uses four techniques to reduce the bit rate:

   Interframe prediction ‑ only the differences between frames is encoded

   DCT coding ‑ this reduces spatial redundancy

   Motion compensation ‑ movement within a frame is detected

   Frame dropping ‑ frames can be dropped if the channel bit rate is exceeded

If the channel can support bit rates in excess of 1.5 Mbps, the picture quality is comparable to that of a broadcast TV signal. In a 64 Kbps channel the frame rate drops to 15 frames/sec. A small image suitable for desktop video conferencing can be supported.

Each block represents 8 equivalent lines x 8 equivalent pels. Blocks 1 - 4 contain luminance information, block 5 contains the Red chromance signal, and block 6 contains the Blue chromance signal.

The total number of blocks in a CIF frame is 6 x 33 x 12 = 2376, and the total number of pels per frame is 2376 x 8 x 8 = 152064.

This standard is below the quality of a standard NTSC signal, which has a digital equivalence of approximately 480 lines by 500 pixels.

Although the standard appears to have a great deal of flexibility, particularly when it comes to bandwidth and digitizing voice & data channels. There apparently will be no established standards on reprocessing, encoding, or post processing.

Designation

Function

PSC

Picture start code

TR

Temporal reference [time stamp]

T1

Type 1 [identifies: split screen, document camera, freeze picture release, CIF/QIF]

PEI1

Picture extra insertion 1

P

Parity

PEI2

Picture active insertion 2

PS

Picture spare [not used]

GOB Data

3 QCIF or 12 CIF data fields

GBSC

Group of blocks start code

GN

Group number

T2

Type 2 [not used]

Q1

Quantizer information [indicates which quantizer tables to use]

GS

GOB spare [not used]

MB Data

Macroblock data

MBA

Macroblock address number [1 - 33]

T3

Type 3

Q2

Quantizer information

MVD

Motion vector data

CBP

Coded block pattern

Block Data

DCT [discrete cosine transform] coefficients followed by a block delimiter

 

Bandwidth Allocation

P

Kbps

Channels

1

64

B or 56 Kbps

2

128

2B or 112 Kbps

3

192

3B

4

256

4B

5

320

5B

6

384

6B or H0 [1/4 T1]

12

768

2H0 [1/2 T1]

18

1152

3H0 [3/4 T1]

24

1536

4H0 or H11 [T1]

30

1920

5H0 or H12

 

3.4.2    H.263

H.263 supports QCIF, CIF as specified by H.261 as well as three other resolutions:

Characteristic

SQCIF

4CIF

16CIF

Luminance Pixels

128

704

1408

Luminance Lines

96

576

1152

H.263 Support

Yes

Optional

Optional

Bit Rate [Mbps]

@ 10 frames/sec

1.0 [gray]

1.5 [color]

32.4 [gray]

48.7 [color]

129.8 [gray]

194.6 [color]

Bit Rate [Mbps]

@ 30 frames/sec

3.0 [gray]

4.4 [color]

97.3 [gray]

146.0 [color]

389.3 [gray]

583.9 [color]

 

The SQCIF picture format operates at about half the resolution of QCIF while the 4CIF and 16CIF formats have 4 and 16 times the resolution of CIF respectively. The high performance formats compete directly with MPEG.

3.4.3    H.320

H.320 Implementers Agreement – Technical Overview by Versit

This standard supports audio/video conferencing over ISDN and switched 56 facilities. It does not support communications over LANs or POTS lines.

H.320 specifies processing audio and video information, multimedia protocols, and synchronization of audio and video signals. Like the other multimedia teleconferencing standards, it applies to multipoint and point-to-point sessions.

3.4.4        H.323

H.323 by Trillium

H.323 Technology Part 1: An Introduction to Packet Based Videoconferencing by Networking Technologies

H.323 Technology Part 2: The Standard in Greater Detail by Networking Technologies

H.323 Technology Part 3: Real World deployment & Issues by Networking Technologies

The H.323 standard is an extension of H.320 supporting LANs and WANs. This allows it to include corporate intranets and packet-switched networks. Because it is based on RTP/RTCP from the IETF, it also supports video over the Internet.

H.323 applies to both multipoint and point-to-point sessions.

3.4.5        H.324

Draft H.324 by the ITU

H.324 governs simultaneous video, data, and voice over V.34 modems on POTS lines. Videophones, based on H.324 can connect and conduct multimedia sessions. Because it supports POTS, H.324 has greater impact in the marketplace than H.323 and H.320.

The H.324 suite consists of five recommendations: H.324, H.223, H.245, H.263 and G.723.1. H.261 video compression and T.120 data are also specified.

3.5     T.120

T.120 regulates data sharing during a multimedia teleconferencing session. It specifies how files and graphical information are distributed, and provides cross platform interoperability for applications such as shared white board

It also specifies the audio and graphic portion of H.320, H.323, and H.324.

ITU T Series Standards:

ITU Document

Comments

T.120

Data protocols for multimedia conferencing

T.121

Generic applications template

T.122

Multipoint communications service

T.123

Protocol stacks for audiographic and audiovisual teleconference applications

T.124

Generic conference control

T.125

Multipoint communication services protocol

T.126

Multipoint still image and annotation protocol

T.127

Multipoint binary file transfer

T.130

Real time architecture for multimedia conferencing

T.131

Network specific mappings. Outlines how real time audio and video streams should be transported across various networks

T.132

Real time link management

T.133

Audiovisual control services.

T.RES

Reservation services

T.TUD

User reservation

 

Most of the T.120 standards have been ratified and work on the rest continues in the ITU.

3.6     DVB

The DVB Data Broadcasting specification paves the way for high-speed data transfer via satellite, cable and terrestrial television channels. Applications include data-casting, downloading software, providing Internet services over broadcast channels, and interactive TV.

A DVB receiver can be a plug-in PC Card.

Spare satellite transponders and PSTN “Return Channels” can be used to deliver high speed TCP/IP data.

For standard 6, 7, or 8 MHz TV channels, the DVB standard offers a data throughput potential of between 6 and 38 Mbps, depending on whether only a part of the channel or the full channel or transponder is used.

DVB Systems provide a means of delivering MPEG-2 Transport Streams via a variety of transmission media. These transport streams traditionally contain MPEG-2-compressed video and audio.

The DVB Data Broadcasting standard allows a wide variety of interoperable data services to be implemented.

Various European satellite operators including Astra, Eutelsat, and Hispasat have implemented satellite DBNs. There were more than 16 million PCs bought in Europe in 1996, and more than 30 million households having direct access to satellite transmissions.

Data-casting or Internet services would typically use a broadcasters’ extra satellite transponder space to broadcast content into the home via the consumer’s 18-inch satellite dish. The received content is then directed to the consumer’s PC via a coaxial cable interfaced with a DVB compliant plug-in PC card. Once decoded, it may be viewed on a browser, or saved on the PCs hard disk.

Where there is a need to have two-way communications, the user connects via the PSTN to a host computer, ISP.

Satellites offer wide area coverage. Since much of the infrastructure is already in place, very little is needed to take advantage of data broadcasts over satellite.

3.7     Video Players

For information on Apple’s QuickTime, see the following documents:

QuickTime Technology Brief

QuickTime on the Internet

 

 

Assignment Questions

 

Quick Quiz

1.     A video overlay displays an open window by bypassing the PC bus and memory. [True, False]

2.     Px64 [is, is not] designed to work over switched networks.

3.     The H.324 specifies videoconferencing over the PSTN. [True, False]

4.     To prevent deterioration of the video signal on a conference call, it is often necessary to assign priorities to the video streams. [True, False]

5.     It is [sometimes, never] required to dynamically reassign privileges on a videoconference call.

6.     Some shared white boards can include open applications windows. [True, False]

7.     Echo cancellation [allows, does not allow] the audio transmit and receive paths to remain active without feedback.

8.     Audio has a greater latency than video. [True, False]

9.     CU-SeeMe [operates, does not operate] over an IP network connection.

10.   A compressed CU-SeeMe frame is seldom less than 1500 bytes long. [True, False].

11.   Enhanced CU-SeeMe [supports, does not support] color.

12.   Mbone is a virtual network layered on top of the Internet to support IP multicast routing. [True, False].

13.   On Mbone, the video signal is compressed, but not the audio. [True, False].

14.   Px64 [is, is not] limited to ISDN links.

15.   [H.261, T120] is also known as Px64.

16.   The acronym CIF stands for Common Intermediate Frequency. [True, False]

17.   The term intermediate is used to describe Px64 formats because the video source can be either PAL or NTSC. [True, False]

18.   Chromance information in H.261 is encoded as color difference signals. [True, False]

19.   The DCT breaks the picture down into 8 x 8 pixel blocks. [True, False]

20.   DCT coding reduces [spatial, temporal] redundancy.

21.   The quality of 16CIF is as good as MPEG. [True, False]

22.   The H series recommendations include a standard for transporting video via modem. [True, False]

23.   The T series recommendations cover the document-sharing portion of a multimedia teleconference. [True, False]

Composition Questions

To answer these questions, it may be necessary to do some additional research.

1.     What bit reduction techniques are used in the H.261 standard?

2.     What is a video overlay and what are its limitations?

3.     What is the serialization problem that occurs with shared white boards and applications?

4.     What are the basic problems associated with microphones on a videoconferencing call?

5.     What is the purpose of CU-SeeMe reflector site?

6.     Go to the Microsoft NetMeeting website, and obtain details of its current capabilities.

7.     Explain the 4:2:2 video format.

 

 

For Further Research

 

Aldred, Barry; Desktop Conferencing — A complete guide to applications and technology, 1996, McGraw-Hill

 

http://www3.ncsu.edu/dox/video/products_TUV.html

http://zenon.inria.fr:8003/rodeo/

www.prz.tu-berlin.de/docs/html/MMC/

 

Other useful Links

http://inet.uni-c.dk/~deckkh/

www.creaf.com/            Creative Labs

http://www.sun.com/   Sun Microsystems

www.nortel.com/          Nortel, search for videoconferencing

 

On-line Journals

E-volve          http://www.bbn.com/evolve/index.htm?hpf

 

Synchronized Multimedia

http://smw.internet.com/smil/smilhome.html

 



       Multipoint Conferencing Unit

[1]       U-SeeMe Desktop VideoConferencing Software, Tim Dorcey, Connexions, Volume 9, No.3, March 1995

       Resource ReSerVation Protocol

       Real Time Protocol

       Time To Live

       Distance Vector Multicast Routing Protocol

       Truncated Reverse Path Broadcasting

       Personal Conferencing Work Group

       Personal Conferencing Specification

       Personal Computer

       Common Intermediate Format

       Quarter CIF

       Real time TP/TCP