Previous: Conference Multiplexing and Management Centre (CMMC)
Up: Conference Multiplexing and Management Centre (CMMC)
Next: Audio
Previous Page: Conference Multiplexing and Management Centre (CMMC)
Next Page: Audio

Video

A representation of video flows through the CMMC is shown in Figure 5. Broadly speaking, a video flow originates in a remote site codec (either hardware or software). It may then undergo a protocol conversion, before being transmitted over a network (either packet based or ISDN). Depending on the circumstances of the conference, it may or may not then require multiplexing or format conversion. Assuming it requires multiplexing, this can be done in one of three ways:

• Option 1: Decode to analogue video, quad multiplex in hardware, and recode again in hardware.

• Option 2: Decode in software, multiplex digitally, and recode.

• Option 3: Multiplex up to 4 H.261 QCIF video streams into one H.261 CIF video stream in the compressed, coded domain by parsing, modifying and combining the compressed H.261 streams.

Clearly, only option 3 can be done without any loss of quality, although this option places certain restrictions on the remote site codecs.

Some protocol conversion may also be required before transmission to the receiving sites, which may not all be on the same type of network (for example, some may be on ISDN links, some on packet networks), and may not all have the same restrictions (some may be using software codecs, some may have hardware codecs on high speed networks), and so a single incoming video flow may be coded several times for distribution. Transmission to remote sites over packet networks will usually be via multicast, even if there is only one receiving site, as the Mbone [16] should be configured to use the paths best suited to real time traffic, whereas the usual service traffic routes may not be.

The function of the video multiplexor is to combine the video into quadrants. The connection with the UCL Conference Rooms can be direct analogue via the video switch. This can also connect on to the other sites of the University of London over LIVEnet [17], and also to direct broadcast satellite if required.

Which set of the codec/mux/codec paths is chosen for a particular conference through the CMMC will depend on a number of factors. Some examples are:

• Where a number of conference sites require high quality, high data rate video we would normally decode in hardware (option 1). At high data rates, any lag introduced by the decode-mux-code cycle is minimal. Option 3 may also be possible, but it should be noted that the resulting data rate will be the sum of the data rates of the incoming streams, and so they must total less than 2Mbps to stay within the H.261 specification. The maximum rate we can perform 4xQCIF to CIF combination in software is not yet known.

• Where a remote site is connected over ISDN, it will usually be simpler to allocate a hardware ISDN codec than to perform the necessary H.221 protocol conversions in software, though this could be done, if required.

• Where a remote site is connected via a software codec that does not use H.261 video compression, we have no option but to decode the stream in software. The simplest path is then to multiplex resulting digital images in software using option 2. However, if the other conference sites dictate that the hardware decode/mux/code path be used we can use a VGA frame buffer to perform digital-to-analogue conversion before multiplexing, and a fast video frame grabber to perform the reverse path compression.

At present the video information from the US codecs will be in a format incompatible to that of the European video, and so must be passed to a particular codec.