From: can@nemesys.co.uk To: Philipp Hoschka The Multimedia Intranet ======================= There is currently much interest in incorporating streaming video and audio into the WWW. Unfortunately, most of the work to date has neglected the corporate Intranet environment. There has been little or no video/audio application development specifically for the Intranet where ATM is becoming prevalent and bandwidth is plentiful. It is our belief that only an integrated network, hardware and software approach will realise the full potential of the Intranet as the ubiquitious delivery platform for all corporate information applications. A non-integrated approach entails the need for seperate networks for data, telephony and video; for different video/audio capture and display hardware and for different applications. In contrast, the use of a single network architecture, standards based hardware codecs and application software creates the base environment for the next generation of, as yet unforeseen, multimedia applications to flourish. 1. Background ATM offers the high speed, guaranteed levels of network performance needed for data, telephony and streaming multimedia streams to co-exist. The WWW is driving the adoption of ATM in the corporate backbone (Intranet) by enabling an entirely new generation of interactive, multimedia applications. That is, ATM and the WWW meet in the Intranet. Current WWW based protocols and standards are not capable of supporting streaming video and audio at TV and CD/DAT quality. Commercial work to date has concentrated on proprietary codecs aimed at very low bit rate (28.8Kbps) transmission of streaming audio and video The concentration on low bit rate transmission is understandable given that the target market is home-based Internet access. Clearly this fails to address the Intranet environment where bandwidth is plentiful and the use of standards-based solutions is imperative. Our goal is to make high-quality video and audio an integral part of the corporate Intranet. 2. System Architecture Nemesys manufactures a range of ATM based video and audio hardware codecs. These devices are standalone and attach directly to the ATM network and are thus completely decoupled from any particular hardware and operating systems platform. The devices are managed from a remote workstation or PC. Video and audio sourced from the hardware codecs can be displayed on workstations and PCs. All video and audio streams are transmitted using native ATM (AAL5) to provide a high-performance, multicast and QoS-based, transmission. These codecs provide the basic building blocks for a multimedia environment and can be combined in many different ways to satisfy different applications. The intelligence required to orchestrate the basic hardware devices to provide a particular application is provided by the SVA software environment. SVA uses a client/server architecture to provide a distributed model for application development. Servers manage codecs and provide RPC interfaces for management and other software applications. As of today, the same hardware, in conjunction with different SVA client applications is being used for remote teaching, high-quality video conferencing, security/monitoring and network TV applications. 3. Current Products We currently supply a unidirectional video encoder and a separate decoder. The encoder (the AVA-300) supports an extremely wide range of video and audio formats: ranging from uncompressed 8-bit monochrome to M-JPEG compressed, from 8-bit mono audio to DAT quality. Picture resolution, frame rate etc can all be controlled. The AVA-300 is capable of generating a single full-rate, full resolution, interlaced digital video stream using M-JPEG compression. Uncompressed formats can be sourced at as a high a frame rate and resolution as the network connection allows. The decoder, the ATV-300, can receive and display a full rate video stream from an AVA-300, thus giving TV-quality transmission over ATM. It can also display picture-in-picture and ``tiled'' video streams from multiple AVAs simultaneously. An on-screen menu system is used to both configure the local device and interact with SVA management software running elsewhere in the network. This device is intended for use where either a workstation or PC is inappropriate or cannot offer sufficient levels of performance. 4. Current Issues There are a number of issues we believe impede the integration of high-quality video and audio into the current Intranet environment. 4.1 Support for High-Speed Networking Current Intranet protocols do not allow the efficient use of underlying high-speed networks, especially where guaranteed Quality of Service is required. Although multicast support is becoming available for the Internet using Multicast IP it does not yet offer high levels of performance. The Internet Multicast community is undoubtedly leading the way with the RTP and RTCP protocols, similarly IPv6 and RSVP promise to radically improve the ability to efficiently use the underlying network support. Although these protocols are an essential first step they are not of themselves a solution. That is, higher level protocol standards and formats must be developed before multimedia applications become a reality. Fortunately, RTP has been designed with such higher protocols in mind and can be easily to accomodate them as so-called RTP profiles. 4.1 Data Formats As yet there are no commonly accepted or standardised formats for video and audio transmission over the Intranet. Again, pioneering work has been carried out by the Internet Mulitcast community but as yet much of their work has not formally standardised. Of greater concern is the proliferation of different higher level protocols and formats for different video and audio encodings. For example, H261, MPEG1, MPEG2, M-JPEG all have different RTP profiles with new ones being added at a rapid pace. Each of these has its own advantages and disadvantages. The major disadvantage that they all share is that there so many of them! Is there really a need for a *completely* different profile for MPEG1 and M-JPEG, MPEG2 and H261? To date Nemesys has used proprietary data formats and encodings for network transmission of video and audio. Although these formats are published as part of our normal product documentation it is not expected that we will become widely adopted. We are committed to both using and helping to develop standards based formats. 4.3 Client Video Playback Video display on most current workstations and PCs is sub-standard (i.e. below TV quality) for M-JPEG or uncompressed video. MPEG1 also falls below TV quality but generally offers higher frame rate performance than M-JPEG. However it does introduce additional latency (0.25-0.5s) which may be unacceptable for some application, MPEG2 promises to improve on this. High quality audio playback, on the other hand, is possible today on most platforms. 4.4 Graphical User Interface Support The Intranet currently provides poor support for GUI applications. However the advent of Java, JavaScript, Tcl/Tk plugins for Netscape and other approaches highlight that is perhaps the busiest area of current development in the Intranet arena. 4.5 Client Video/Audio Playback As we have discovered over the past three years the display of real-time video and audio is a complex affair! We now have a great deal of experience in presenting video and audio on stock workstation platforms which we would like to transfer into the WWW browser environment. We are aware that work is already going on in this area and would urge the developers to pay particular attention to the low latency requirements for audio and the high memory I/O bandwidth requirements for video. 5. Addressing These Issues The IETF RTP procotol is becoming accepted as the transport protocol of choice for real-time video and audio. It both supports high-speed networking and provides an excellent vehicle for defining video and audio formats as RTP profiles. Our goal is to apply the same basic principles that lead to the development of RTP to the development of video and audio formats. Namely, to identify all the common characteristics of all video formats and place them in a common header. In this way it becomes possible to treat any video stream in a uniform way for certain common operations. For example, all video formats have a width and a height, a colorspace and some notion of fields (whether interlaced or not). Similarly all will share the notion of ``packing'', i.e. how many pixels are transmitted in a single PDU. Error recovery information could also be shared. The same approach can be applied to audio; the number of channels, the sampling rate, the sampling algorithm etc will be common across all audio encodings. Such a seris of ``compatible'' RTP profiles not only simplifies and optimises existing video/audio applications but also enables a new generation of generic video and audio applications. Why should a video file server necessarily be care wether the video it stores is MPEG1 or MPEG2? Similarly when bridging from ATM to Fast Ethernet why should the bridging code need to be concerned with the precise video format being bridged? Note, that such a bridge at least needs to at least know that its bridging video or audio to ensure optimal performance. 6. An Integrated Solution It is our belief that to realise the potential of the Intranet an integrated hardware and software approach is required. Our strategy for realising this is as follows: + simple hardware devices to provide high-performance video/audio encode and decode + use of RTP/RTCP to both provide high-speed networking support and to define standard video/audio formats + a distributed systems approach to application development + use of Intranet servers and browsers to provide a standards based application development environment 6.1 A Distributed Approach The Intranet environment naturally falls into a client/server architecture. By providing server interfaces for all the hardware codecs it is possible to bring the management and control of these devices into the Intranet. The key question is what interfaces to provide? Nemesys currently uses ONC RPC as our RPC transport mechanism and Interface Definition Language. Its principal shortcoming (as far as we are concerned) is that it offers poor support for application development. As such it is unsuitable as a basis for third-party developers and ISVs. However, CORBA has rapidly established itself as the distributed infrastructure of choice. We plan to evolve our current ONC RPC based system to use CORBA and in particular support the CORBA IIOP specification. The inclusion of IIOP support in Intranet browsers makes it possible to develop sophisticated service interfaces which can be accessed over the Intranet. If this access is coupled with better GUI support in the browser then a very powerful application development environment is made possible. 6.2 A Simple Example A simple example of how such an integrated approach pays of is the current SVA support for one-way interaction with the Internet MBONE tools. This allows our AVA coders to be used as video sources for MBONE transmission. This is used by the University of Cambridge Computer Laboratory to relay seminars. Users on the local ATM network can view the seminars either on their workstations or via an ATV. Remote users can view the same seminar, albeit at lower quality, over the Internet-wide MBONE using Vic and Vat. Although basic, this highlights the benefits that can be gained by integrating two initially separate systems. In this instance a much wider audience can access the same information. 7. The Role of ATM Why is ATM important for the Intranet? Our experience has been that ATM offers significant advantages for application developers. We have been delivering TV quality video with sub 20ms audio latency over ATM for over 2 years. We can display this video using stand-alone hardware devices or on stock-workstations (albeit at gernally lower quality). The hardware support for multicast provided by ATM means that we support potentially thousands of users without any degradation in performance or increase in network bandwidth requirements over supporting a single user at any given switch. Combining these features with the ability to run all other existing Intranet protocols safely, without interfering with one other, over the same ATM network infrastructure provides a truly integrated multimedia network. ATM provides the underlying fabric for our vision of an intergrated multimedia Intranet. 6. Summary We have argued that an integrated hardware and software solution is essential to the incorporation of high-quality video and audio into the Intranet. The RTP protocol if coupled with a series of compatible video and audio profiles promises efficient high-speed networking and application interoperability. The incorporation of CORBA IIOP and better support for GUI development provides a very powerful distributed application development environment. Finally, using ATM as the underlying network provides a truly integrated Multimedie Intranet. Cheers, Cos. Cosmos Nicolaou email: can@nemesys.co.uk Nemesys Research Ltd, WWW: http://www.nemesys.co.uk 14 Regent Street, Cambridge CB2 1DB tel: +44 1223 566 300 United Kingdom fax: +44 1223 566 301 ---