Proprietary standards
Name: IP Multicast
Reference: RFC 1112
Version: August 1992
Sponsoring body: IETF Network Working Group
Status: Internet standard
Brief description: The extensions required to a host implementation of the Internet Protocol (IP) to support multicasting.
Detailed description: IP multicasting is the transmission of an IP datagram to a host group, which is a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of a destination host group. The membership of the host group is dynamic. A host group may be transient or permanent.
Multicasting of this nature is essential to optimise bandwidth usage for multiparty conferencing applications.
Internetwork forwarding of IP multicast datagrams is handled by multicast routers. The special routing requirements of multicast IP can be met in several different ways. There are extensions to the OSPF and BGP routing methods, and there is a new routing method (CBT - Core Based Trees). At the time of writing, it seems that CBT is likely to be adopted as the appropriate method of routing multicast IP.
Products: vat, nv, ivs, NEVOT, sd and other remote conferencing tools use IP multicast. Multicast support is available as kernel patches for SunOS 4.x.x, and is built in to SunOS 5.
Further information: There are mailing lists concerned with IP Multicast backbone operations at the following addresses:
mbone-uk@nosc.ja.net (GB)
mbone-eu@sics.se (Europe)
mbone-oz@internode.com.au (Australia)
mbone@isi.edu (US and World)
Patches to various UNIX system kernels to provide multicast support are available from: gregorio.stanford.edu:/vmtp-ip.
Date of entry: 15 December 1992
Name: MIME
Reference: RFC 1341
Version:
Sponsoring body: Internet Architecture Board
Status: Proposed Internet Standard
Brief description: Multipurpose Internet Mail Extensions
Detailed description: MIME supports not only several pre-defined types of non-textual message contents, such as 8-bit 8000Hz-sampled u-LAW audio, GIF image files, and PostScript programs, but also permits you to define your own types of message parts. A typical MIME mail reader might:
Display GIF, JPEG and PBM encoded images, using eg 'xv' in X windows.
Display PostScript parts (eg something that prints to a PostScript printer, or that invokes GhostScript on an X windows display, or that uses Display PostScript.)
Obtain external parts via Internet FTP or via mail server.
Play audio parts on workstations that support digital audio.
RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. RFC1341 redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, RFC 1341 is largely orthogonal to (rather than a revision of) RFC 822.
MIME is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US-ASCII, to represent formatted multi-font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by co-operating mail agents.
An associated document, RFC1342, extends Internet mail header fields to permit other than US-ASCII text data.
Products: Many mailers which support MIME are now available.
Further information: The specification is available as RFC 1341: "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", N. Borenstein & N. Freed.
Other associated RFCs are:
RFC 1342: "Representation of non-ASCII text in Internet message headers", K. Moore, June 1992
RFC 1343: "User agent configuration mechanism for multimedia mail format information", N. Borenstein, June 1992
Edward Vielmetti (emv@msen.com) is preparing a FAQ on MIME. See also the newsgroup comp.mail.mime.
Date of entry: 21 December 1992
TOP
Name: RTP
Reference:
Version: October 27,1992
Sponsoring body: IETF Audio/Video Transport Working Group
Status: Internet Draft (expires 1st April 1993)
Brief description: A Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications
Detailed description: Services typically required by multimedia conferences are playout synchronisation, demultiplexing, media identification and active-party identification. RTP is not restricted to multimedia conferences, however, and other real-time services such as data acquisition and control may use its services.
RTP uses the services of an end-to-end transport protocol such as UDP, TCP, OSI TPx, ST-2 or the like. The services used are: end-to-end delivery, framing, demutliplexing and multicast. The network is not assumed to be reliable and is expected to lose, corrupt, delay and reorder packets.
RTP is supported by a real-time control protocol (RTCP). Conferences encompassing several media are managed by a reliable conference protocol not discussed in the RTP draft.
The draft summarises some discussions by the AVT (audio/video transport) working group. The draft builds on the operational experience with Van Jacobson's and Steve McCanne's vat audio conferencing tool as well as implementation experience with Henning Schulzrinne's NEVOT network voice terminal.
Other protocols and standards referred to are:
- NVP - Network Voice Protocol RFC741
- G.764 and G.765 - CCITT recommendations for packet voice
The design goals of RTP are:
- media flexibility
- extensible
- independent of lower-layer protocols
- gateway compatible
- bandwidth efficient
- international
- processing efficient
- implementable
Services provided are:
- framing
- demultiplexing by conference/association
- demultiplexing by media source
- demultiplexing by media encoding
- synchronisation between source(s) and destination(s)
- error detection
- encryption
- quality-of-service monitoring
RTP consists primarily of protocol header for real-time data packets. In the typical case, the RTP header is just 8 octets long and composed of the following fields:
- protocol version (2 bits, value 1)
- flow identifier (6 bits)
- option present bit
- synchronisation bit (marks end of synchronisation unit)
- content type index (6 bits)
- packet sequence number (16 bits)
- timestamp, middle 32 bits of NTP-format timestamp
Products: vat, NEVOT
Further information: This draft is available by anonymous FTP from: ftp.ripe.net:/pub/internet-drafts/ in the files:
draft-ietf-avt-rtp-00.txt
draft-ietf-avt-encoding-00.txt
draft-ietf-avt-profile-00.txt
draft-ietf-avt-issues-00.ps, .txt
Date of entry: 15 December 1992
TOP
Name: ST-2
Reference: RFC 1190
Version: 2
Sponsoring body: Internet Network Working Group
Status: Internet Standard
Brief description: This memo defines the Internet Stream Protocol, Version 2 (ST-2), an IP-layer protocol that provides end-to-end guaranteed service across an internet.
Detailed description: This specification obsoletes IEN-119 "ST - A Proposed Internet Stream Protocol". ST-2 is not compatible with Version 1.
ST-2 is an internet protocol at the same layer as IP. It differs from IP in that it requires routers to maintain state information describing the streams of packets flowing through them.
ST incorporates the concept of streams across an internet. Every intervening ST entity maintains state information for each stream that passes through it. The stream state includes fowarding information, including multicast support for efficiency (required for multiparticipant conferencing) and resource information which allows network or link bandwidth and queues to be assigned to a specific stream. This pre-allocation allows data packets to be forwarded with low delay, low overhead and low probability of loss due to congestion. This allows ST-2 to give a real-time application the guaranteed and predictable communication characteristics it requires.
The data stream in an ST-2 connection is essentially one-way, except that there is a reverse-direction channel for control messages.
Transport protocols above ST-2 of interest to multimedia applications include Packet Video Protocol (PVP) and the Network Voice Protocol (NVP), which are end-to-end protocols used directly by applications.
Products: Implementations by SICS (SE) and BBN (US) exist.
Further information: "An Implementation of the Revised Internet Stream Protocol (ST-2)", C. Partridge and S. Pink, Journal of Internetworking: Research and Experience, March 1992.
Date of entry: 15 December 1992
Name: RFC 741
Description: Network Voice Protocol
Name: Xv and mvex
Description: X extensions to incorporate video. Xv is implemented in DEC's XMedia toolkit. See the XMovie entry in the Research section for another alternative.
TOP
Name: Bento
Reference:
Version: 1.0d4
Sponsoring body: Apple Computer
Status: Manufacturer-sponsored specification created with the help of third parties and offered to the industry in general in the hope that it will become a de facto standard.
Brief description: Platform-independent container structure for networks of objects.
Detailed description: Bento is a specification for the format of "object containers" and an associated API. In this context, an "object" such as a word-processor document or a movie clip typically comprises some metadata (data about the object's format) and a value (the content of the object). A "container" is some form of data storage or transmission (eg a file or part of a mail message). Bento containers are defined by a set of rules for storing multiple objects in such a container. Bento does not require individual objects to be "Bento-aware".
Bento can store deltas to an object, and can store objects in compressed or encrypted form, where compression/encryption algorithms may be specified externally. It can store external references to data - for instance to a large movie file (perhaps itself part of a Bento container) stored on a fileserver; and can also store a limited-resolution version for use when the fileserver version is unavailable.
Unlike other similar standards such as ASN.1 and ODA, Bento allows for the storage of multimedia objects in a medium-specific interleaved layout (say, on a CD-ROM) suitable for "just-in-time" real-time display.
The Bento specification also contains an API.
Bento:
- is platform independent.
- is suitable for random-access reading (when a container is in RAM or on disk).
- has an "update-in-place" mechanism supported in the API, but not yet in format specification or implementation.
- has a globally unique naming system for objects and their properties. Names can be allocated locally for casual use or registered for common use.
- objects are extensible - new information may be added to an object without disrupting applications which don't understand the new information.
- supports links between objects.
- provides recursive access to embedded Bento containers.
- can store a single object in several different formats (eg with different byte-ordering).
- is not a general-purpose object database mechanism.
Products: It is understood that portable C source code should soon be available.
Further information: The Bento specification is available from:
ftp://ftp.apple.com/apple/standards/Bento1.0d5
Date of entry: 19 January 1993
TOP
Name: GIF (Graphic Interchange Format)
Reference:
Version: 87a and 89a
Sponsoring body: Compuserve Incorporated, Ohio, USA
Status: De facto industry standard
Brief description: Protocol for interchange of raster graphic data
Detailed description: The Graphics Interchange Format defines a protocol intended for the on-line transmission and interchange of raster graphic data in a way that is independent of the hardware used in their creation or display.
Compuserve Incorporated has granted a limited, non-exclusive, royalty-free license for the use of the Graphics Interchange Format in computer software.
The Graphics Interchange Format is defined in terms of blocks and sub-blocks which contain relevant parameters and data used in the reproduction of a graphic. A GIF Data Stream is a sequence of protocol blocks and sub-blocks representing a collection of graphics. In general, the graphics in a Data Stream are assumed to be related to some degree, and to share some control information.
A Data Stream may originate locally, as when read from a file, or it may originate remotely, as when transmitted over a data communications line. The Format is defined with the assumption that an error-free Transport Level Protocol is used for communications; the Format makes no provisions for error-detection and error-correction.
The GIF format utilises colour tables to render raster-based graphics. The concept of both global and local colour tables are supported to enable the optimisation of data streams. The decoder of an image may use a colour table with as many colours as its hardware is able to support, if an image contains more colours than the hardware can support algorithms not defined in the 'standard' must be employed to render the image. The maximum number of colours supported by the 'standard' is 256.
Products: Many products now support GIF image format files.
Further information: The document describing GIF, and software implementing it, are widely available on the Internet by anonymous FTP.
Date of entry: 21 December 1992
TOP
Name: QuickTime
Reference:
Version: 1.5 Preliminary
Sponsoring body: Apple Computer, Inc
Status: Proprietary
Brief description: File format for the storage and interchange of sequenced data, with cross-platform support.
Detailed description: A QuickTime movie contains time based data which may represent sound, video or other time-sequenced information such as financial data or lab results. A movie is constructed of one or more tracks, each track being a single data stream.
A QuickTime movie file on an Apple Macintosh consists of a "resource fork" containing the movie resources and a "data fork" containing the actual movie data or references to external data sources such as video tape. To facilitate the exchange of data with systems which use single fork files, it is possible to combine these into a file which uses only the data fork .
Movie resources are built up from basic units called atoms, which describe the format, size and content of the movie storage element. It is possible to nest atoms within "container" atoms, which may themselves contain other container atoms.
One type of container atom is the "movie" atom which defines the timescale, duration and display characteristics for the entire movie file. It also contains one or more track atoms for the movie.
A track atom defines a single track of a movie and is independent of any other tracks in the movie, carrying its own temporal and spatial information. Track atoms contain status information relating to the creation or editing of the track, priority in relation to other tracks and display and masking characteristics. They also contain media atoms which define the data for a track.
Media atoms contain information relating to the type of data (sound, animation, text etc) and information relating to the QuickTime system component (ie driver) that is to handle the data. Component-specific information is contained in a media information atom which is used to map media time and media data.
The above is a very simplistic view of a QuickTime movie resource. In fact there are many more atom types which define a wide variety of features and functions, including a TEXT media atom which allows displayed text to change with time, and user-defined data atoms called "derived media types". These allow for the custom handling of data by overriding the media handler with a user-supplied driver.
The actual movie data referred to by the movie resources may reside in the same file as the movie resource (a "self contained" movie), or more commonly it may reside in another file or on an external device.
It is possible that QuickTime could become a computer-industry standard for the interchange of video/audio sequences.
Products: Support for this format is available for Apple Macintosh System 7.1 free of charge.
"QuickTime for MS Windows" (version 1.1 is scheduled for release early 1993) will allow self-contained QuickTime movies to play on Microsoft Windows without conversion. Claims a common API for both Windows and the Macintosh.
"QuickTime Movie Exchange Toolkit" contains utilities for the conversion of graphics from a range of platforms.
Apple have an agreement with Silicon Graphics to provide limited QuickTime support on SCI Iris workstations. This will allow the creation and playing of QuickTime movies on both platforms through support for the QuickTime file format.
Further information: QuickTime Developers Guide, Apple Computer Inc.
Date of entry: 15 December 1992
TOP
Name: RIFF
Reference:
Version:
Sponsoring body: Microsoft and IBM
Status: Proprietary
Brief description: File structure for multimedia resources
Detailed description: RIFF (Resource Interchange File Format) is a family of file structures rather than a single format. RIFF file architecture is suitable for the following multimedia tasks:
- Playing back multimedia data
- Recording multimedia data
- Exchanging multimedia data between applications and across platforms
A RIFF file consists of a number of "chunks" which identify, delimit and contain each resource stored in the file.
Each chunk is defined as follows:
- 4 characters (the chunk type) identifying how the data stored in the chunk is represented.
- A 32 bit unsigned number representing the size of the data stored in the chunk.
- The binary data contained in the store.
There are two special chunks which allow nesting of multiple chunks. These are the "RIFF" chunk which combines multiple chunks into a "form" and "LIST" which is a list or sequence of chunks.
Certain chunk types (including all form and list types) should be globally unique. To guarantee this uniqueness there is a registration scheme run by Microsoft , where new chunk types may be registered and a list of current registrations may be obtained.
The definition of a particular RIFF form typically includes:
- A unique 4 character code identifying the form type.
- A list of mandatory chunks.
- A list of optional chunks.
- A required order for the chunks.
Currently registered "forms" are
PAL Palette File Format (.PAL files)
RDIB RIFF Device Independent Bitmap Format (.DIB files)
RMID RIFF MIDI Format (.MID files)
RMMP RIFF Multimedia Movie File Format
WAVE Waveform Audio Format (.WAV files)
The RIFF "LIST" chunk is identified by a 4 character "list type " code. If an application recognises the list type it should know how to interpret the sequence of chunks, although any application may read through the nested chunks and identify them individually.
RIFX is a counterpart to RIFF, that uses the Motorola integer byte ordering format rather than the Intel format. There are no currently defined RIFX forms or lists.
RIFF files are supported in Windows 3.1 under MS DOS, and by MMPM/2 under OS/2. There is no sign yet of RIFF being adopted on hardware platforms other than the PC.
Products: Windows 3.1 Filewalker is a RIFF file viewing utility in the Microsoft Windows multimedia development kit. Many products support particular formats from the RIFF family.
Further information: The specification is available from:
uunet.uu.net:vendor/microsoft/multimedia.
Date of entry: 14 December 1992
Name: DVI
Description: Intel's Digital Video Interactive video compression technology.
Name: MIDI
Description: Musical Instrument Digital Interface |
