I N TERN ATI ON AL ISOIIEC

STAN DARD 1 4478-3

Fi rst edition

1 998-1 2-1 5

I n form ati on tech n ol og y - Com pu ter

g raph i cs an d i m ag e processi n g -
Presen tati on En vi ron m en t for Mu l ti m ed i a
Obj ects (PREMO) -

Part 3:
M u l ti m ed i a System s Servi ces

Technologies de /‘information - lnfographie et traitement d’images -

Environnement de pr&entation d’objets multimedia (PREMO) -
Pattie 3: Services pour /es syst&mes multim4dia

Reference nu m ber

I SOAE C 1 4478-3:1 998(E)

ISO/IEC 1447&3:1998(E)

Contents
Foreword ........................................................ V

Introduction .................................................... vi
1 Scope ........................................................... 1
2 Normative references .............................................. 2
3 Definitions ....................................................... 2

3.1 PREMO Part I definitions .................................... .2

3.2 PREMO Part 2 definitions .................................... .2

3.3 Additional definitions. ....................................... .2

4 Symbols and abbreviations ......................................... 3

5 Conformance .................................................... 3

6 Overview of the Multimedia Systems Services ........................ .3

6. 1 Introduction ................................................ .

6. 2 Obj ect framework. .......................................... .4

6. 3 S ubtyping diagram .......................................... .6

6. 4 MS S obj ect life cycle ........................................ .7

7 Configuration objects ............................................. 7

.
7. 1 Introduction ................................................

@ I SO/I EC 1 998

Al l ri g h t s r es er ved . Un l es s o t h er wi s e s p ec i f i ed , no p ar i of th i s p u b l i c at i o n m ay be r ep r o d u c ed or u t i l i zed

in any form or by any means, electronic or mechanical, including photocopying and microfilm, without

permission in writing from the publisher.

lS O/IEC Copyright Office l Case postale 56 l CH- 1 21 I Geneve 20 l S witzerland

Pr i n t ed in Swi t zer l an d

ii
0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

7.2 Format objects. ........................ . . 8

7.3 Transport and Media Stream Protocol objects . . 9

7.4 Quality of Service Descriptor objects. ........................... 9

8 Stream Controls ................................................ 10

8. 1 Stre a m Co n tro l o bj ects. ...................................... .I1

8. 2 Syn c Stre a m Co n tro l objects ................................... 13

9 Devices, Resources .............................................. 13

9.1 Virtual Resources .......................................... 13

9. I. 1 Configuration objects on virtual resources. .......................... 14

9. I .2 Stream control. ................................................ 14

9. I .3 Resource management ....... ........ . . . I4

9.1 .4 Quality of Service Management ........ . . . I5

9.2 Virtual Devices ............. ....... . . . . . . . 16

9.2. I Processing element. ......... ........ . . . . . I . 17

9.2.2 Ports ..................... ........ . . . . . , . I7

9.2.3 Streams ................... ........ . . . . . . *. I7

9.2.4 Port configurations .......... ........ ,..> I8

9.3 Virtual Connections. ......... ....... . . . . . . . . 19

9.3. I Examples for connection agreement. ..... I9

9.3.2 Connection establishment. ............. . . 20

9. 3. 2. 1 Un i c as t an d m u l t i c as t ................ .21

9.4 Groups ............................ . . . . . 21

9.4. I Resource acquisition and end-to-end QoS . . 22

9.4.2 Stream control. ...................... 23

9.5 Logical Devices ............................................ 23

10 Functional specification .......................................... 24

1 0.1 Introduction ............................................... 24

1 0.2 Non-object data types. ................ . . 24

1 0.3 Exceptions. ......................... . . 25

1 0.4 Structures ........................... . . 26

1 0.4. I Port information structure. ....................................... 26

1 0.5 Configuration object. ....................................... 26

1 0.5.1 Format objects ............................

1 0. 5. I. I Fr ~r m u t o b j ec t ............................. . .

1 0.5.2 Transport and Multimedia Stream Protocol objects . ..~..

1 05. 2. I Mu lfir~ e dio Stre rrrn Pro to c

oob jl
ec t s . ............

1 0. 5. 2. 2 f n f r u No d eTr cm . ~/~o r t o b j ec t s ..................

1 0. S. 2. 3 InterNodeTrrmslJorr o b j ec t s ..................

1 0.5.3 Quality of Service objects. ...................

1 0.6 Stream Controls. ......................... . . . . . . . 29

1 0. 6. I Stre a m Co n tro l object ....................... 29

1 0.6.2 Syn c Stre a m Co n tro l object. ................... 30

1 0.7 Devices, resources. .................. . 31

1 0. 7. 1 Virtu a lR e s o u rc e object ................ 31

1 0.7.2 Virtu a lD e vic e object .................. 33

III
 0 IS O/IEC
ISO/IEC 1 4478-3: 1 998(E)

1 0. 7 . 3 Virtual connections ............................................. 36

1 0. 7. 3. I V;rfuu/Connec~rion obj ect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

1 0. 7. 3. 2 Vi rru n l C o n n er~ ri o n M u l ti cast obj ect ................................... 38

............................................... .39
1 0. 7 . 4 Groupobj ect. ,

1 0. 7. 5 Lo g ic a lD e vic e obj ect. .......................................... . 40

11 Component specification .......................................... 41

A Overview of PREMO MS S obj ects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

B A typical example scenario for MSS usage ........................... 44

C Basic Devices .................... . .............................. 46

C. I Format obj ects ............................................ . 47

C. l. 1 Videoformats. . .............................................. . 47

C. l. 2 Audio formats ................................................ . 48

C. l. 3 CATV format. ................................................ . 49

C. l. 4 MIDI format ................................................. . 49

C. 2 Digital stream controls ...................................... . 49

C. 3 Video and audio processing .................................. . 49

C. 3 . I Video processing. ............................................. . 49

C. 3 . 2 Audio processing. .............................................. 50

C. 4 S pecific devices ........................................... .50

C. 4. 1 Defining a device .............................................. 50

C. 4. 2 Video. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 I

C. 4. 3 Audio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 I

C. 4. 4 Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2

C. 4. 5 CDplayer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2

C. 4. 6 CATVtuner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2

C. 4. 7 MlDldevice. . .............................................. ..5 3

C. 4. 8 External resources. ............................................ .53

C. 5 Functional S pecification. .................................... .54

C. 5 . I Area of interest for video obj ects .................................. 54

C. 5 . 2 Format obj ects. ............................................... .54

C. 5 . 3 Digital S tream Control ......................................... . 62

C. 5 . 4 Video and audio processing ..................................... . 63

C. 5 . 5 S pecific devices. ............................................... 65

D Examples of virtual connection settings ............................. 72

D. I Hardware connection example. ............................... . 72

D. 2 Direct connection example. .................................. . 72

D. 3 Local connection example ................................... . 72

D. 4 Network connection example. ................................ . 74

0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardi-
zation. National bodies that are members of IS0 or IEC participate in the development
of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
government and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical
committee ISO/IEC JTC 1. Draft International Standards adopted by the joint technical
committees are circulated to the national bodies for voting. Publication as an Interna-
tional Standard requires approval by at least 75% of the national bodies casting a vote.
ISO/IEC 14478-3 was prepared by Joint Technical Committee ISO/IEC JTC 1, In fo r-

mation technology, Subcommittee SC24, Computer graphics and image processing.

This International Standard currently consists of the following four parts under the
general title Information technology - Computer graphics and image processing -

Presentation environments fo r multimedia objects (PREMO):

- Part I: Fundamentals of PREMO

- Part 2: Foundation Component

- Part 3: Multimedia Systems Services

- Part 4: Modelling, Rendering, and interaction Component

Annex A forms an integral part of this part of ISO/IEC 14478. Annexes B to D are for
information only.
 ISO/IEC 1 4478-3 : 1 998(E) 0 ISO/IEC

I ntr o ductio n

The Multimedia Systems Services (MS S ) component of PJUZMO provides a standard

set of services that can be used by multimedia application developers in a variety of

computing environments. Enabling multimedia applications in a heterogeneous, dis-

tributed computing environment is the design motivation for the MS S . This is an in-

creasingly prevalent computing model, and a solution that meets the needs of this

environment can more easily be scaIed to stand-alone systems than vice versa.

The principal reasons for defining the MS S are:

a) provide abstractions and mechanisms that make it possible for applications to

deal with the problems of distributed multimedia computing successfully;

b) facilitate the implementation of compIex applications, such as video confer-

encing;

c) provide abstractions that make it possible for applications to deal with media

devices without regard to specific characteristics of the platform, attached

devices, or the network(s) connecting the platforms and devices;

d) to provide a standard methodology, especially for handling “live” data;

e) insure scalability to large organizations;

f-l insure adequate performance in adverse conditions;

g) facilitate Quality of Service commitments; and

h) consider the time critical nature of the data.

The primary goal of the MS S is to provide an infrastructure for building multimedia

computing platforms that support interactive multimedia applications dealing with

synchronized, time-based media in a heterogeneous distributed environment. Opera-

tion in a distributed environment is important because of significant trends in the com-

puter industry towards client/server and collaborative computing. Another significant

trend is towards multimedia enabled computing. The inevitable result will be an inter-

section of these trends to produce a distributed multimedia environment with a topol-

ogy similar to Figure I.

The MS S is intended to address a broad range of application needs. It extends the mul-

timedia capabilities of stand-alone computers to capabilities that are usable both local-

ly and remotely. The Multimedia Systems Services gives applications the ability to

handle:

Vi
0 IS O/IEC ISO/-IEC 1 4478-3: 1 998(E)

i) live data remotely;

j) stored data remotely;

k) both live and stored data simultaneously;

I) multiple kinds of data simultaneously; and

m) new kinds of devices and media types.

A p p lica t io n
< 1

Figure 1 - Distributed multimedia environment

vii
 ISO/IEC 1 4478-3: 1 998(E) 0 ISO/IEC

To provide support for remote media device control and remote media access that de-

rive from the above application scenarios, the Multimedia System Services uses two

distinct mechanisms. To support interaction with remote obj ects, the Multimedia Sys-

tems Services depends upon an underlying obj ect model and infrastructure, as de-

scribed in ISO/IEC 1 4478-I (PREMO). To support the media independent streaming

of time critical data, the Multimedia Systems Services defines a Media Stream Con-

trol.

The MS S does not address:

n) encryption and security;

o) intellectual property rights and accounting;

p) scripting;

q) user interfaces; or

f) sharing of data between applications.

VI I I
INTERNATIONAL STANDARD 0 ISOLIEC ISO/IEC 1447&3:1998(E)

I nfor mation tec hnolo gy - Comp uter gr ap hics and image

p r ocessing - P r esentatio n E nvir onment for M ultimedia O b j ects

(P R EM O ) -

P ar t 3 : M ultimedia S ystems S er vices

1 Scope
This part of ISO/IEC 1 4478 defines a standard set of multimedia system services that can be used by multimedia application de-

velopers in a variety of computing environments. The focus is on enabling multimedia applications in a heterogeneous, distrib-

uted computing environment. Throughout this part of ISO/IEC 1 4478, this component will also be referred to as “Multimedia

Systems Services”, and abbreviated as MS S .

The Multimedia Systems Services constitutes a framework of “middleware” - system software components lying in the region

between the generic operating system and specific applications. As middleware, the Multimedia Systems Services marshals low-

er-level system resources to the task of supporting multimedia processing, providing a set of common services which can be used

by multimedia application developers.

The Multimedia Systems Services encompasses the following characteristics:

a) provision of an abstract type for a media processing node, extensible through subtyping to support abstractions of real

media processing hardware or software;

b) provision of an abstract type for the data tlow path or the connection between media processing nodes, encapsulating

low-level connection and transport semantics;

c) grouping of multiple processing nodes and connections into a single unit for purposes of resource reservation and stream

control;

d) provision of a media dataflow abstraction, with support for a variety of position, time and/or synchronization capabili-

ties:

e) separation of the media format abstractions from the dataflow abstraction;

f) synchronous exceptions and asynchronous events;

g) application visible characterization of obj ect capabilities;

h) registration of obj ects in a distributed environment by location and capabilities;

i) retrieval of obj ects in a distributed environment by location and constraints;

j) definition of a Media Stream Protocol to support media independent transport and synchronization.

The Multimedia Systems Services rely on the obj ect model of ISO/IEC 1 4478-I (Fundamentals of PREMO) and the obj ect types

and non-obj ect data types defined in ISO/IEC 1 4478-2 (PREMO Foundation Component).
0 IS O/IEC ISO/IEC 1 4478-3: 1 998(E)

DigitalVideoFormaf <iIv~;Format

Format

DigifalAudioFormal DynamicDigifalAudioFormat

CA TVForma t

’ MID/Formal

Figure 16 - Format subtypes

a) In the region of the diagram descending from VirtualResource, the descendants of VirtualDevice are often multiple sub-

types of other types (Audio, Video, etc. ) which specify operations required by real devices.

b) The diagram shows increasingly media and device specific types from left to right. These types are meant to illustrate

sample types that can be supported by the Multimedia Systems S ervices and are not meant to be the final word in media-spe-

cific interface abstraction.

c) Note the varieties of Format and Stream interfaces. These are discussed in subsequent clauses.

c. 1 F o r ma t obj ects

This Annex defines a hierarchy of Format types that can be used to describe a variety of media formats. Each Format type un-

derstands the details of a particular kind of media format and, through the property mechanism, has methods to set and get details

about its encoding.

Figure 1 6 gives the hierarchy of the various format obj ects defined in this Annex. The Format obj ects proper acts as a common

supertypes for all format obj ects; it defines only two general properties: byte order for the bitstream, and name of the format. All

the specific features are left to the various subtypes.

The following sub-clauses give only a short overview of the various format obj ects defined in this Annex.

C.l.l Video formats

This Annex defines several video Format types. These types are used to encapsulate the video formats which can flow between

video virtual devices.

C.l.l.l Digital video format

The DigitalVideoFormat type is the simplest video format. The type defines a property to describe the raster size, common colour

space, and frame rate. There are properties for the video components to characterize the ordering and sub-sampling of the com-

ponents.

The PseudoColourVideoFormat type provides information to specify the colour table for video devices with an indexed colour

space. The colour table translates the index colour space into a true colour space.

47
ISO/IEC 1 4478-3: 1 998(E) 0 ISO/IEC

The JPEGVide o Fo rm a t type defines the segment keys which this compression technique requires. These segment keys represent

in-band control messages. For example, the key JPEGVide o Fo rm a t: : D qtK defines the quantization table. This video format il-

lustrates how the format obj ect can encapsulate dynamic formats which encode commands into the data stream.

The MPEGVide o Fo rm a t interface defines properties for this compression technique. The list of keys is extensive. The allocation

of these details to the format type, however, consolidates the conventions to one interface.

C.1 .1 .2 External video format

This Annex defines some additional external video format properties. These format keys anticipate the integration of device con-

trol into the framework. Assume someone provides a virtual device obj ect which provides the type to control a VCR device. The

virtual device would describe the video stream which it can export in terms of a video format obj ect. Assume the framework also

provides a video capture device. Since both virtual devices describe video formats, the client (or the connection obj ect) can verify

the formats are compatible. For example, the key “ En c o din g I? for the Vide o Co n n e c to rFo rm a t obj ect may have the value of “NT-

SC’ , “ PA L” , “ SECA M” , “ R GB ” , ” YUV’ , “ A UTO ” to describe the various available formats for digital and analogue video.

c.1 .2 Audio formats

This Annex offers three audio specific format types. These types are used to abstract the format of audio data that can flow across

connections and be produced or consumed by audio-capable virtual devices.

C.1 .2.1 Digital Audio Format

The D ig ita lA u dio Fo rm a t type is intended to abstract the set of audio formats. Its characteristics are those that are necessary to

fully specify a digital audio bitstream, and they include such things as encoding, sample rate, and bits per sample.

The special properties of the D ig ita lA u dio Fo rm a t are such that they cannot be changed once either of the following two condi-

tions occur:

a) The port with which it is associated is connected to another virtual device (see clause 9) via the co n n e ct operation; or

b) The Virtu a lD e vic e , Virtu a lCo n n e c tio n , or Gro u p with which it is associated has its resources acquired via the a c qu ire R e -

s o u rc e operation.

The reason for the first condition is that the data format abstracted by D ig ita lA u dio Fo rm a t does not define any in-band signalling

of changes in its characteristics, such as sample rate. The Virtu a lCo n n e c tio n establishes an agreement between the source and

destination format obj ects; changing the value of a characteristic of one of the format obj ects on the fly violates this agreement

and could cause data flowing through the connection to be misinterpreted.

The reason for the second condition is that the resources required to process or transport the audio data are dependent on the set-

tings of the D ig ita lA u dio Fo rm a t characteristics. Once the Virtu a lR e s o u rc e . a c qu ire R e s o u rc e operation is invoked, a quality of

service contract is established; changing the constraint on the properties of a format obj ect may cause this contract to be violated.

C.1 .2.1 .1 Dynamic Digital Audio Format

The D yr~ a m ic D ig ita lA u dio Fo rm a t type is a subtype of the D ig ita lA u dio Fo rm a t type, It defines no new methods or properties, but

it is intended to abstract audio data formats that provide the in-band signalling necessary to change values of its characteristics,

such as sample rate, on the fly.

B ecause of the in-band signalling capability, the conditions that prevented the characteristic settings of a D ig ita lA u dio Fo rm u t

obj ect from being changed do not prevent fhe characteristic settings of a D yn a m ic D ig ita lA u dio Fo rm a t obj ect from being

changed. However, the client should be careful to constrain the range of characteristic settings to those it expects to use in order

to improve the chances of a successful connection and to prevent over-allocation of resources.

48
0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

C.1 .2.2 Audio Connector Format

The AudioCormector interface abstracts audio formats that are made external to a computer system, such as line, headphones,

and microphone level analogue signals. The properties of this format are used to determine the compatibility of data types in the

same way as for internal digital audio data types. For example, it is possible to determine that a port that uses a line level cannot

be connected to a port that uses a headphones level.

The AudioConnectorFormat is an example of a Format type that is associated with VirtualDevice ports that model physical con-

nections to a device. Exposing the physical connectors of a device as ports and describing the data that can flow across them as

Formats permits external devices to be modelled in exactly the same way as internal devices.

c.1 .3 CATV format

CATV is the acronym for Cable TV. The CATVFormat obj ect gives a standardized way to describe access to CATV network

information.

c.1 .4 MIDI format

MIDI is the acronym for Musical Instrument Digital Interface, used to interface synthesizers, sequencers, rhythm machines, etc.

All MIDI communication is achieved through multi-byte messages which are defined in separate specifications. The MIDIFor-

/~nr obj ect gives a standardized way to interface such devices.

c. 2 D ig it al st r e am co nt r o ls

All devices, described in this Annex, use digital stream control. This means that the generic SyncStream and SyncStreamControl

obj ects, as defined in clause 8, are actualized so that their progression space is defined to be Z,, and all virtual device obj ects in

this Annex used these obj ects instead of the general ones.

c. 3 Vi d e o and au d io p r o c e ssin g

c.3.1 Video processing

The basic video specific processing interface is defined by the Video type. This is an abstract base type that is “mixed in” with

the VirtualDevice type through multiple subtyping to create the VideoDevice interface.

The Video type was made a distinct type itself. rather than defining its methods directly in the VideoDevice type defined later, in

order to allow adding video processing operations to other types of devices (such as an audio/video device) without encountering

ambiguous multiple subtyping. This approach ensures that there is exactly one path from a VirtualDe\, ice subtype to Its base

types.

The interface of the type allows the client to manipulate standard video controls. Since devices often provide additional controls,

the interface casts the controls as a property list. With this syntax it is straightforward to define additional KeyValue pairs, and

still inherit the operations found in the video type. Note that since the operations includes the stream position, the client can en-

queue methods which modify the controls as a function of the steam time.

The interface of the Video type provides an operation to set the Area Of lrlterest within the source raster. The structure to define

an area of interest describes the origin (x. J) and size (width, /zeight) within the source raster which the obj ect is to process. Note

that the width and height can assume negative values. The four combinations of positive and negative values allow the client to

reflect the image across either or both of the vertical and horizontal axes.

The operation which specifies the area of interest (setlmageAOI) also takes a stream position (i. e. , stream relative time) argument

to allow for changes in the area of interest as the stream flows. The current value of the area of interest can also be inquired. Also,

since the region within the source raster can be larger than the target raster, there is a property to specify whether the obj ect is to

clip 01 . scale.

49
ISO/IEC 1447%3:1998(E) 0 ISYIEC

VideoDevice

Video

A VDevice

Audio MicrophoneDevice

AudioDevice

VirtualResource VirtualDevice SpeakerDevice

FileDevice

CDPlayer

CANTuner

\ M/D/Device

Figure 17- VirtualDevice subtyping hierarchy

c.3.2 Audio processing

The basic audio specific processing interface is defined by the Audio type. This is an abstract base type that is “mixed in” with

the VirtualDevice type through multiple subtyping to create the AudioDevice interface.

The Audio type was made a distinct type itself, rather than defining its methods directly in the AudioDevice type defined later, in

order to allow adding audio processing operations to other types of devices (such as an audio/video device) without encountering

ambiguous multiple subtyping. This approach ensures that there is exactly one path from a VirtualDevice subtype to its base

types.

The interface of Audio is very simple: it only defines a properties for both the gain and the attenuation of the signal from the

input(s) to the output(s) of an audio device.

c. 4 S p e c i fi c d e vi c e s

In this subclause, several useful subtypes of VirtualDevice will be described:

a) video,

b) audio,

c) file, and

d) external device.

These types will demonstrate how abstractions of real world devices can be realized within the Multimedia Systems Services

model. The types used here are examples only. Additional devices may be defined by registration.

c.4.1 Defining a device

When adding a new device type, it is necessary to evaluate the device’ s capabilities with respect to the following criteria:

a) What processing does the device perform on its data?

50
0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

b) What types of data can be processed? What characteristics define them?

c) What stream position and control vocabulary is needed?

The answer to the first question determines the new operations that the new Virtu a lD e vic e subtype should have. The answer to

the second question determines what new Fo rm a t and possibly Pro to c o l type(s) are necessary to configure the ports. The answer

to the third question determines if any new Stre a m Co n tro l subtype or position keys may be needed.

In addition, one should consider what the configuration of the device’ s ports should be. Typically, each point to which a connec-

tion can be made (either virtual or physical) should be exposed as a virtual device port. For example, an audio digitizer device

that can input data from a line input and produce a stream of digital data would have one input and one output port; in contrast,

a speaker device that can input data from a digital stream and produce sound would have one input port and no output ports.

C.4.2 Video

Most of the generat characteristics of video processing are abstracted in the separate Vide o obj ect type (see Annex C. 3 of this

Part), as well as in the various video related Fo rm a t types (see Annex Cl of this Part). No new stream control vocabulary is

necessary. This Annex of PREMO defines only one Vide o D e vic e type; the definition of specific subtypes for various operating

environments would go beyond the scope of this Annex and should refer to the special features of these environments.

NOTE - Informal IS0 documents or appendices to this standard may however be published to give a general highlight of how this could be

done for specific environments.

c.4.3 Audio

The addition of audio devices to this Annex involves the definition of audio specific processing capabilities and media formats.

No new stream control vocabulary is necessary.

C.4.3.1 Audio processing

The basic audio specific processing interface is defined by the A u di o interface (see Annex C. 3 . 2 of this Part). This type is an

abstract base type that is “mixed in” with the Virtu a lD e vic e type to create the A u dio D e vic e type. In addition, certain characteris-

tics specific to audio processing are defined, such as the encoding and sample rate associated with the inputs and outputs; this

defines a vocabulary sufficient for the client to specify simple constraints about the type of A u dio D e vic e , such as “an Audio De-

vice that can process 44. I KHz at its input and produce 8 KHz at its output”.

The A u dio D e vic e interface can be used to represent any device that processes audio and supports the gain and attenuation prop-

erties. If a device is incapable of affecting the gain, it can either be represented as an A u dio D e v ic e with its gain value fixed at

unity, or simply as a Virtu a lD e vic e that admits to audio Fo rm a t obj ects at its ports (see below).

C.4.3.1 .1 Speaker device

The Sp e a ke rD e v ice is a subtype of the A u dio D e vic e type. It is used to abstract a built-in speaker device. This device presents one

input port and has no output ports (it j ust pushes air). It defines no new operations.

The Sp e a ke rD e v ice type is defined to make an easy distinction for the client between this type of device and, say, an audio display

device that drives a line output. B oth can be equally well represented by the A u dio D e vic e interface. The Sp e a ke rD e vic e type pro-

vides a simple way for the client to get a speaker, without having to set the appropriate constraints on a generic A u dio D e v ic e .

C.4.3.1 .2 Microphone device

The Mic ro p h o n e D e vic e is a subtype of A u dio D e vic e . It is used to abstract a built-in microphone device. It presents one output

port and no input ports. Like Sp e a ke rD e vic e , it is defined as a simple way for a client to obtain a microphone, without having to

set the appropriate constraints on a generic A u dio D e vic e .

51
ISO/IEC 1 4478-3: 1 998(E) 0 ISO/IEC

c.4.4 Files

A pervasive characteristic of multimedia applications is the use of files to store and play back media. Defining a separate device

to describe file processing in a multimedia setting gives a high level of uniformity to multimedia applications.

Common to the processing of most media file types is a core set of operations required by clients for the playback and storage of

media data. These operations include:

a) setting the mode for file access, e. g. , read, write;

b) identifying the file format type;

c) inquiry on file and data characteristics;

d) setting the position within the file for data access;

e) setting ranges within the file to constrain data access;

f) repetitive data access; and

g) controlling the speed of playback.

Files introduce no new media formats, but rather use the same Fo rma t obj ects as already defined for the media-specific device

(i. e. , D ig ita lA u dio Fo rm a t, D ig ita lVide o Fo rm a t, etc. ). The operations unique to particular file formats are supplied by subtyping

the Virtu a lD e vic e type.

The specific characteristics of a file virtual device are determined by the file format type which it represents and its mode of op-

eration, e. g. , reading or writing. Several approaches are possible for managing the process of discovering the file’ s type and

launching the appropriate file reader or writer device. One fairly simple strategy is to assume that the client has knowledge, by

some means, of the type of file it wishes to read or write. The client creates a file virtual device by first locating a factory that can

provide an obj ect of the desired File D e vice subtype, then creates an obj ect on the factory with a constraint list that describes the

client’ s requirements and knowledge of the file. The constraint list minimally includes a file name, open mode, and file type, in

addition to any constraints required by supertypes. It may optionally include a location, a temporary file name, and an “automatic

save on close” indicator.

A variation on this approach could utilize a special factory to perform the task of creating File D e vic e obj ects, rather than the cli-

ent. Still other approaches could easily be described for handling complex file types, such as container files, but this is beyond

the scope of the this standard.

Whichever approach is used, as part of the creation process, a subtype of File D e vic e , identified by the file type, is instantiated

and the file device configures itself with the appropriate number and type of ports and associated Fo rm a t and File Stre a m obj ects.

Ports are designated for input or output according to the open mode constraint. Formats are defined according to information

found in the file, e. g. , a header that describes the media characteristics of the data. The client may inquire about the nature of the

ports configured by using the Virtu a lD e vic e . g e tPo rtCo rzfig method. This returns a list of ports which includes associated format

classes and input/output designations for each port. The client can use this information to decide which port to designate when

connecting to another virtual device.

c.4.5 CD player

The CD Pla ye r is a subtype of the D e vic e obj ect, used to abstract the access to compact disk players. It does not use any particular

format obj ects.

C.4.6 CATV tuner

The CA TVTu n e r is a subtype of the D e vic e obj ect, used to abstract the access to cable TV information. Its ports are controlled by

the CA TVFo rm a t obj ects (see Annex C. I . 3 of this Part).

52
0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

c.4.7 MIDI device

The is a subtype of the

MID /D e vic e objects, whose input and output ports are controlled by the
D e vic e objects (see MID IFo rm a t

Annex C. I .4 of this Part). It is used to abstract access to various MIDI hardware, like synthesizers, rhythm machines, etc. It may
have several input and several output ports.
C.4.8 External resources

An important aspect of multimedia in any computer environment, distributed or otherwise, is control of external devices. External
devices such as cameras, microphones, speakers, etc. provide the “eyes” and “ears” and “mouth” of a computer system, trans-
ducing real world analog signals to digital signals for communication or storage, and transducing digital signals to analog signals
for interaction with people. External devices such as VCRs and laser disc players provide source material and inexpensive mass
storage for analog information; TV or radio tuners provide access to additional analog sources. The list of useful external devices
is long, and the Multimedia Systems Services must allow for external device attachment and control.
The abstraction for external devices is the As with all virtual devices, the inputs and outputs for external devices
Virtu a lD e vic e .

are exposed as ports, which have associated objects. Since ports on external devices are used to represent external con-
Fo rma t

nectors, the generic type is subtyped from

Fo rm a t The type (see Annex C.5.2. I of this Part)
Co n n e cto rFo rm a t. Co n n e c to rFo rm a t

defines those characteristics specific to the type of data that passes through the port. It could be used to represent a physical con-
nector on an external device or an internal adapter card, such as an audio capture device.
By extending the same abstraction used for “internal” devices to “external” devices, the Multimedia Systems Services allows the
same sort of actions on external devices as on internal devices. For instance, external connectors can be connected (although some
connections may be hard wired), external formats can be constrained, queried, etc., in the same manner as for internal devices.
As an example, consider the in clause C.4.6. This device takes an RF analog video input and generates two channels
CA TVTu n e r

of analog audio (stereo) output plus one channel of analog video output. Thus, the admits to one input port and three
CA TVTu n e r

output ports all of which have The input format would actually be a
Co n n e cto rFo rm a ts . representing the RF analog
CA TVFo rm a t,

video. The audio output channels would each be represented by an The video output channel would be
A u dio Co n n e c to rFo rm a t.

represented by a Vide o Co n n e c to rFo rm a t.

Next consider a video capture adapter. Its output port would be represented by a Its input connector would
D ig ita lVide o Fo rm a t.

be represented by a With this design, the

Vide o Co n n e c to rFo rm a t. video output port could be successfully connected
CA TVTu n e r

to a video capture device input port to allow capture of the video output of the tuner. It is possible to connect the CA TVTu n e r

audio connectors to one or more audio capture adapters making similar assumptions.
It should be noted that there are a variety of ways to realize virtual connections between external devices. Some installations may
have physical device inputs and outputs routed to a switching device, such as an analog crossbar switch. When a Virtu a lCo n n e c -

tio rtobject is created, the resource manager controlling the crossbar switch could be instructed to connect the appropriate ports.
Another realization might simply be to display a message on a user’s screen and ask that the appropriate connection be made.
Finally, “persistent” connections could be stored in the Registration & Retrieval Service database, permitting a virtual connection
factory to determine whether a reference to a requested virtual connection could be made.

53
ISO/IEC 1447%3:1998(E) 0 IS O/IEC

C. 5 F un c t io n al S p e c i fi c a t i o n

This clause gives a more formal specification of the obj ects defined in this Annex. Note that the specifications are here as example

only, hence some of the keys and properties are not fully specified.

c.5.1 Area of interest for video objects

I== Im a g e A

Simp le PR EMO O b je ct

{ y, w idth , h e ig h t: R

Im a g e A

c.5.2 Format objects

C.5.2.1 Co n n e c to rFo rm a t objects
I==-
Ca n n e c to rFo rm a t, t, , , , . ,

Fo rma t

Co n n e c to rFo rm a t

54
0 IS O/IEC ISOAEC 1 4478-3: 1 998(E)

C. 5. 2 . 2 Vide o Co n n e c to rFo rm a t obj ect

Vide o Co n n e c to rFo rm a t

Co n n e c to rFo rm a t

Vide o Co n n e c to rFo rm a t

Properties defined:

Key Qpe of Value R.0 or R/W Description

-

En c o din g K String S horthand name which identifies the

video encoding or syntax.

Vide o Syn c Sta te K Strin g Indicates whether video is synchro-

nized.

Vide o Syn c So u rc e K Strin g Indicate the source of the video syn-

chronization signal.

Capabilities defined:

Key Type of VaIue Values

En c o din g CK array6 String < “ NTSC” , “ PA L” , “ SECA M” ,

“ R GB ” , “ YUV” , “ A UTO ” >

VideoS yncS tateCK array3 String < “ Go o dSyn c “, “ In v a lidSyn c “,

“ No Syn c ” >

Vide o Syn c So u rc e CK array3 Strin g < “ In te rn a lSyn c ” , “ Exte rn a lSyn c ” ,

‘ A u to Syn c” >

MutablePropertyListCK seq Ke y < “ En c o din g K” , Vide o Syn c Sta te K”

“ Vide o Syn c So u rc e K” >

55
ISO/IEC 1 4478-3: 1 998(E) 0 ISOAEC

C. 5. 2 . 3 A u dio Co n n e c to rFo rm a t obj ects

7 A u dio Co n n e c to rFo rm a t

Co n n e c to rFo rm a t

A u dio Co n n e c to rFo rm a t

Properties defined:

Key Type of Value R.0 or R/W Description

En c o din g K String R/W

Capabilities defined:

Key Qpe of Value Values

En c o din g CK array4 String < “ He a dp h o n e “, “ Lin e “,

“ Mic ro p h o n e ” , “ Sp e a ke r” >

56
0 IS O/IEC ISO/IEC 1 4478-3: 1 998(E)

C. 5. 2 . 4 D ig itdVide o Fo rm a t obj ect

LIig ita lVide o Fo rm a tUb , , , . ,

I==

Fo rma t

D ig ita lVide o Fo rm a t

Properties defined:

Key Qpe of Value R.0 or R/W Description

Width K z R. O.

He ig h tK Z R. O.

A s p e c tR a tio K R R. O .

Co lo u rSp a c e K Strin g R. O .

Pe rio dK R R. O .

Sa m p le R a te K R R. O .

Co m p o n e n tCo u n tK Z R. O .

CITjp e K Strin g R. O.

CID e p th K O c te t R. O.

CISu h s a m p lin g XK O c te t R. O.

CISu lxa m p lin g YK O c te t R. O.

C2 Typ e K Strin g R. O .

C2 D e p th K O c te t R. O .

CZSu lxa m p lin g XK O c te t R. O .

C2 Su b s a m p lin g YK O c te t R. O .

C3 irjp e K Strin g R. O .

C3 D e p th K O c te t R. O.

C3 Su lxa m p lin g XK Oc te t R. O .

C3 Su h s a m p lin g YK Oc te t R. O.

C4 7jp e K Strin g R. O.

C4 Lkp th K O c te t R. O.

C4 Su b s a m p lin g XK O c te t R. O.

C4 Su b s a m p lin g YK O c te t R. O.

51
 ISO/IEC 1 4478-3: 1 998(E) 0 IS O/IEC

Capabilities defined:

Key Type of Value Values

Width CK zxz <minimum, maximum>

He ig h tCK zxz <minimum, maximum>

Pe rio dCK RxR <minimum, maximum>

A s p e c tR a tio CK RxR <minimum, maximum>

Co lo u rSp a c e CK a rra y6 Strin g < “ R GB - LINEA R ” , “ R GB - 709” ,

“ YCC- LINEA R ” , ‘ IYCC- 709” ,

“ Y- LINEA R ” , “ Y- 709” >

MutablePropertyListCK se q Ke y < ‘IWidth K” , “ He ig h tK” ,

“ A s p e c tR a tio K” , “ Pe rio dK” ,

“ Sa m p le R a te K” ,

“ Co m p o n e n tCo u n tK” ,

“ ClTyp e K” , “ CID e p th K” ,

“ CISu b s a m p lin g XK” ,

“ CISu b s a m p lin g YK” ,

“ C2 Typ e K” , “ C2 D e p th K” ,

“ C2 Su b s a m p lin g XK” ,

“ C2 Su b s a m p lin g YK”

“ C3 Typ e K” , “ C3 D e p th K” ,

“ C3 Su b s a m p lin g XK” ,

“ C3 Su b s a m p lin g YK”

“ C3 Typ e K” , “ C3 D e p th K” ,

“ C3 Su b s a m p lin g XK” ,

“ C3 Su b s a m p lin g YK” >

58
0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

C. 5. 2 . 5 MPEGVide o Fo rm a t obj ect

MPEGVide o Fo rm a t

I===

D ig ita lVide o Fo rm a t

MPEGVide o Fo rm a t

Properties defined:

Key Type of Value R.0 or R/W Description

In tra Q Ma trixK array8(array8 Octet)

Irlte rQ Ma trixK arrayg(arrayg Octet)

Tim e Co de K array5 O c te t The values are (in this order): a dro p -

Fla g , hours, minutes, seconds, pictures.

A dro p Fla g value of zero is interpreted

as TRUE and any other value is inter-

preted as FALSE.

Capabilities defined:

Key Type of Value Values

MutablePropertyListCK seq Ke y < “ In tra Q Ma trixK” , “ In te rQ Ma trixK”

“ Tim e Co de K’ b

C. 5. 2 . 6 JPEGVide o Fo rm a t obj ect

JPEG Vide o Fo rm a t

f===

D ig ita lVide o Fo rm a t

JPEGVide o Fo rm a t

Properties defined:

None.

Capabilifies defined:

None.

C. 5. 2 . 7 Ps e u do Co lo u rVide o obj ect

Ps e u do Co lo u rVide o Fo rm a t

I==

D ig ita lVide o Fo rm a t

Ps e u do Co lo u rVide o Fo rm a t

59
ISO/IEC 1 4478-3: 1 998(E) 0 ISO/IEC

Properties defined:

Key Type of Value R.0 or R/W Description

NumColoursK 2 R. O.

ColourTableK seq(ZxZxZxZxZ) R/W The values are (in consecutive order):

index, red, green, blue, and alpha val-

ues.

Capabilities defined:

Key Type of Value Values

DynamicPropertyListCK seq Key < “ColourTableK” >

C. 5. 2 . 8 DigitalAudioFormat obj ect

S ee also the restrictions on changing property values, described in Annex C. 4. 3 . 1 of this Part.

r DigitalAudioFormat

Format

L DigitalAudioFornzat

Properties defined:

Key Type of Value R.0 or R/W Description

EncodingK String R/W Shorthand name which identifies the

audio encoding or syntax.

SampleRateK String

NunzCharlnelsK Z R. O.

SampleSize K Z R/W Size of a sample in bits. A zero value

indicates variable.

SignedK Boolean R. O. Refers to the interpretation of the sam-

ple values. The type of the native prop-

erty value is seq Boolean.

60
0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

Capabilities defined:

Key Type of Value Values

Etlcoding CK array4 String < “ALAW”, “UAW”, “LINEAR” ,

“ADPCM”>

SampleRateCK array5 String < “8KHz “, “lI. O3KHz” , “22. 05KHz” ,

“4O. OKHz” , “44. IKHz’b

SampleSizeCK seq(Z x Z, seq(minimum X maximum) (One pair

per channel)

MutablePropertyListCK seq Ke) < “EncodingK” , “SampleRateK” ,

“SampleSizeK” , “SignedK” >

C. 5. 2. 9 DynamicDigitalAudioFormat obj ect

S ee also the restrictions on changing property values, described in Annex C. 1 . 2. 1 . 1 of this Part. This type does not add any op-

eration nor does it add new properties or capabilities; the type is defined separately to stress the semantic differences.

DpnamicDigitalAudioFormat
t====
DigitalAudioFormat

c DynamicDigitalAudioFormat

C.5.2.1 0 CATVFormat obj ect

This type does not add any operation nor does it add new properties or capabilities; the type is defined separately to stress the

semantic differences. The format is relevant with relation to the CATVTuner device.

I== CATVFormat

Format

CATVFormat

C.5.2.1 1 MZDZFormat obj ect

I=== MlDlFormat

Format

MIDIFormat

61
ISO/IEC 1 4478-3: 1 998(E) 0 ISO/IEC

c.5.3 Digital Stream Control

C. 5. 3 . 1 D igita lStre a m Co n tro l obj ects

I= D ig ita lStre a m Co n tro l

Stre a m Co n tro l[Z, ]

D ig ita lStre a n Ko n trd

C. 5. 3 . 2 D igita lS tre a m Co n td o b je c ts

D ig ita lSyn c Stre a m Co n tro l

Syn c Stre a m Co n tro l[Z, ]

D ig ita lSyn c Stre a m Co n tro l

62
0 ISO/IEC ISO/IEC 1 4478-3: 1 998(E)

c.5.4 Video and audio processing

C.5.4.1 Video obj ect

Videorrbsrruct
I=

Propertylnquiry

[; ; ; ; , g Aoz
exceptions: { InvalidPosition]

The operation allows the client to specify the area of interest within the source image. The default value is the

entire source raster. aoii, , describes the origin (x, y) and size (width, height) within the source image which is

to be processed. The width and height can assume negative values. The four possible sign combinations allow

the client to reflect the image across either or both of the vertical (negative height value) and horizontal (nega-

tive weight value) axes, or to specify no reflection (both weight and height positive.) positioni, is a stream

position. Using it, the client can specify that the A01 is to be effective at and following the specified steam

time.

Exceptions raised:

InvalidPosition positioni, is not valid.

- getlmageAO1

positioni, , : Time

aoi, , , l: ReflmageAOI[Shallow Copy]

exceptions: (InvalidPosition)

The operation returns the area of interest at the specified stream time.

Exceptions raised:

InvalidPosition positioni, is not valid.

Video

Properties defined:

Key Type of Value R.0 or R/W Description

BrightnessK Z

ContrastK Z

SaturationK Z

SharpnessK Z

InzageAOlModeK String

63
ISO/IEC 1 4478-3: 1 998(E) 0 IS O/IEC

Capabilities defined:

Key Type of Value Values

BrightnessCK 2X2 <minimum value, maximum value>

ContrastCK zxz <minimum value, maximum value>

SaturationCK zxz <minimum value, maximum value>

SharpnessCK zxz <minimum value, maximum value>

ImageA OlModeCK array2 S tring < “Clip” , “Scale” >

DynamicPropertyListCK s eq Ke) < “BrightnessK” , “ContrastK” ,

“SaturationK” , “SharpnessK” ,

“lmageA OIModeK” >

C. 5. 4. 2 A udio obj ect

I=== Audio~, bsrruc~r

Propertylnquiry

L A udio

Properties defined:

Key Type of Value R.0 or R/W Description

GainK R RIW S ound Volume

Capabilities defined:

Key wpe of Value Values

DynamicPropertyListCK s eq Key < “GainK” >

64
0 IS O/IEC ISO/IEC 1 4478-3: 1 998(E)

c. 5. 5 Specific devices

C.5.5.1 Vide o D e vic e object

Vide o D e v ic e

I===
Virtu a lD e vic e . Vide o

c Vide o D e v ic e

Properties defined:

Key Qpe of Value R.0 or R/W Description

In p u tFra m e R a te K R

O u tp u tFra m e R a te K R

Capabilities defined:

Key Type of Value Values

Inp u tFra m e R a te CK R xR <minimum, maximum>

Ou tp u tFra m e R a te CK RxR < m in im u m , m a xim u m >

InputPortCK Z I

OutputPortCK Z I

InputFormatTypesCK s eq O b je ctTyp e < D ig ita lVide o Fo rm a t>

OutpuFormatTypesCK s eq O b je ctTyp e < D ig ita lVide o Fo rm a t>

C. 5. 5. 2 A u dio D e vic e obj ect

A u dio D e vic e

I===

Virtu a lD e vic e , A u dio

i A u dio D e vic e

Capabilities defined:

Key Qpe of Value Values

InputPortCK Z 1

OutputPortCK Z 1

InputFormatTypesCK s eq O b je ctTyp e < D ig ita lA u dio Fo rm a t>

OutpuFormatTypesCK s eq O b je ctTyp e < D ig ita lA u dio Fo rm a t>

65
 0 IS O/IEC
ISO/IEC 1 4478-3: 1 998(E)

C. 5. 5. 3 A VD e v ic e obj ect

This type represents A/V multiplexors, demultiplexors, A/V capture and display devices.

A VD e vic e

I==

Virtu a lD e vic e , Vide o , A u dio

L-
A VD e vic e

Capabilities defined:

Type of Vahe Values

Key

InputPortCK z 2

OutputPortCK Z 2

< D ig ita lVide o Fo rm a t,

InputFormatTypesCK se q O b je ctTyp e

D ig ita lA u dio Fo rm a t>

OutpuFormatTypesCK s eq O b je c tTyp e < D ig ita lVide o Fo rm a t,

D ig ita lA u dio Fo rm a t>

C. 5. 5. 4 Mic ro p h o n e D e v ic e obj ect

The Mic ro p h o n e D e vic e obj ect is a subtype of A u dio D e vic e . It is defined j ust to make it eas y for a client to get a microphone,

rather than specify the necessary constraints on A u dio D e vic e .

Mic ro p h o n e D e vic e

f===

A u dio D e vic e

Mic ro p h o n e D e vic e

Capabilities defined:

Key Type of Value Values

InputPortCK Z 0

OutputPortCK Z I

InputFormatTypesCK s eq O b je ctTyp e <>

OutpuFormatTypesCK s eq O b je ctTyp e < D ig ita lA u dio Fo rm a t>

GlobalFormatTypesCK s eq O b je ctTyp e < Q o SD e s c rip to r; A u dio Co n n e c to rFo r-

m a t>

66
0 IS O/IEC ISOflEC 1447%3:1998(E)

C. 5. 5. 5 SpeakerDevice object
The SpeakerDevice obj ect is a subtype of A udioDevice. It is defined j ust to make it easy for a client to get a s peaker, rather than

specify the necessary constraints on A udioDevice.

SpeakerDevice
I= = =

A udioDevice

SpeakerDevice

Capabilities defined:
Key Type of Value Values
InputPortCK Z I

OutputPortCK Z 0

InputFormatTypesCK seq ObjectType < DigitalAudioFormat>

OutpuFormatTypesCK seq ObjectTJjpe <>

GIobalFormatTypesCK seq ObjectType < QoSDescriptor; A udioConnectorFor-

mat>

67
ISO/IEC 1 4478-3: 1 998(E) 0 ISO/IEC

C. 5. 5. 6 FileDevice obj ect

FileDevice
I====

VirtualDevice

save

exceptions: (InvalidAccess)
r

Save the file content.

Exceptions raised:

InvalidAccess Invalid access rights to the file.

FileDevice

Properties defined:

Key Type of Value R.0 or R/W Description

NameK String

OpenMode K String

TypeK String

AutoSaveK String

Capabilities defined:

Key Type of Value Valuesa

OpenModeCK seq String < “Read Mode” , “Insert Mode “,

“Over Write Mode “, “A ppend Mode “,

“Create Mode” >

DynamicPropertyListCK seq Key < “AutoSaveK” >

InputPortCK Z 1

OutputPortCK Z 1

InputFormatTypesCK seq ObjectType < Format>

OutpuFormatTypesCK seq ObjectType < Format>

a. an instance of FileDevice may have either one output port or one input port, but not both (this is reflected in

the native property values for the properties InputPortC and OutputPortC)

68
0 IS O/IEC ISO/IEC 1447%3:1998(E)

C. 5. 5. 7 CD Pla ye r object

I=== CD Pla ye r

Virtu a lD e vic e

L CD Pla ye r

Properties defined:
Qpe of Value R.0 or R/W Description
Tra c kK Z R. 0 Current track

Tra c kD u ra tio n K se q Tim e R. O . Duration of each track

Tra c kCo u n tK Z R. O . Number of tracks

Pla p ListK se q Z List of tracks .

Capabilities defined:
Key Qpe of Value Values
DynamicPropertyListCK seq Ke y < “ Pla yListK” >

InputPortCK Z 0

OutputPortCK Z 2

InputFormatTypesCK se q O b je ctTyp e <>

OutpuFormatTypesCK se q O b je ctTyp e < D ig ita lVide o Fo rm a t, D ig ita lA u dio -

Fo rm a t>

69
ISO/IEC 1447%3:1998(E) 0 IS O/IEC

C. 5. 5. 8 CA TVTu n e r object
This device models a CATV tuner that takes an RF analog video at its input and generates two channels of audio plus one channel

of video as o u tp u t. Thus, it has one input port and three output ports .

I= CA TVPla ye r

Virtu a lD e vic e

CA TVPla ye r

Properties defined:

- Key Qpe of Value R-0 or R/W Description

Nu m b e rO fCh a n n e ls K Z R. 0

Cu rre n tCh a n n e lK Z R/W

Capabilities defined:
Key Type of Value Values
DynamicPropertyListCK se q Ke y < “ Cu rre n tCh a n n e lK” >

InputPortCK Z 1

OutputPortCK Z 3

InputFormatTypesCK se q O b je c tTyp e < CA TVFo rm a t>

OutpuFormatTypesCK se q O b je c tTyp e < D ig ita lVide o Fo rm a t, D ig ita lA u dio -

Fo rma t>

GlobalFormatTypesCK se q O b je c tTyp e < Q o SD e s c rip to r; Vide o Co n n e c to rFo r-

m a t>

70
0 IS O/IEC ISO/IEC 1447%3:1998(E)

C. 5. 5. 9 MID ID e v ic e object
This device models a MIDI device, to acces s synthesizers, rythm machines, etc. It may have several input and output ports .

I= MlD ID e vic e

Virtu a lD e vic e

MlD ID e vic e

Properties defined:
Key mpe of Value R.0 or R/W Description
Nu m b e rO fCh a n n e ls K Z R. 0 “Channel” is the term us ed in the MIDI

specification, and can be identified

with various ports in the device.

Omni B oolean When TR UE, it enables to receive

voice mes s ages in all voice channels

without discrimination.

Mono B oolean When TR UE, it res tricts the assignment

of voices to j ust one voice per channel.

When FA LSE, any number of voices

may be allocated.

Capabilities defined:
Key Type of Value Values
InputPortCK Z 16

OutputPortCK Z 16

InputFormatTypesCK se q O b je ctTyp e < MID IFo rm a t>

OutpuFormatTypesCK se q O b je ctTyp e < MID lFo rm a t>

GlobalFormatTypesCK se q O b je ctTyp e ~ Q o SD e s c rip to r; MID lFo rm a t>

MutablePropertyListCK se q Ke y < “ O m n i’ 5

DynamicPropertyListCK s eq Ke y < “ Mo n o “>

71
ISO/IEC 1447%3:1998(E) 0 ISO/IEC

Annex D
(informative)

Examples of virtual connection settings

What follows are some examples of how the virtual connections can be configured to support the types of connections defined

in 9. 3 .

D. l H a r d wa r e c o n n e c t io n e x a mp l e

In some cases, system hardware or operating system software performs the media data transport between the virtual devices. The

virtual connection determines this, but it is then the responsibility of the virtual devices to carry this out. Figure I8 shows an ex-

ample; the shaded area in the figure denotes a machine boundary.

D.2 D ir e c t c o n n e c t io n e x a mp l e

The direct connection case shown in Figure 1 9 is typical of a stand-alone system and will also be used when possible for optimi-

zation in a distributed environment.

D.3 Lo c a l c o n n e c t io n e x a mp l e

The local connection configuration is illustrated in Figure 20. Here a virtual connection adapter is instantiated and inserted by the

virtual connection between two virtual devices on the same system. This might be necessary when the virtual devices ports are

incompatible.

In the local virtual connection adapter case, the virtual connection adapter provides two ports. The virtual device port never knows

whether it is working with another virtual device port or a virtual connection adapter.

H ard ware )/

Si n g l e System

+ w vossme control flow

-b Data flow

Figure 18 - Hardware connection example

72
0 ISOAEC ISO/IEC 1 4478-3: 1 998(E)

Single System

4 + Possible control flow

-b Data flow

Figure 19 - Direct connection example

(--i i i -) (-i i i --]

Single System
I

4 b Possible control f/o w

-b Data flow
Figure 20 - Local virtual connection adapter example

73
ISO/IEC 1 4478-3: 1 998(E) 0 IS O/IEC

Virtual
Connection
( >

Virtual
Lonnecoon
I Device
Adapter

p
( ii- - j
Buffer
Manager
J

System 1 System 2

\ /

4 W Possible control f/o w

-L) Data flow

Figure 21 - Network virtual connection adapter example

D.4 N e t wo r k c o n n e c t io n e x a mp l e

In a distributed environment, the two virtual devices res ide on s eparate systems and a virtual connection adapter is required. Un-

like the local virtual connection adapter, which may be implemented as a single entity, the network virtual connection adapter

consists of two s eparate entities which must communicate acros s the network. This communication between the two parts of the

virtual connection adapter will include the media trans fer as well as control information. This communication will be accom-

plished on top of a network protocol.

74
I SOAEC 1 4478-3: 1 998(E) 0 I SOAEC

I CS 35. 1 40

Descri ptors: data processi n g , i n form ati on i n terch an g e, g raph i c data processi n g , i m ag e processi n g , vi deo data, au d i o data, cod i n g (d ata

con versi on ) , coded represen tati on .

Pri ce based on 74 pag es