DAVIC - Motivations and goals

Leonardo Chiariglione - CSELT, Italy

1. Introduction

For a long time the audio-visual world has been highly fragmented among different business players with sometimes overlapping roles. Two-way speech communications, audio and television broadcasting, audio and video distribution on package media and on cable see intertwined relationships among different business actors in some cases with a role of operators of an infrastructure, in others as producers of content and in some others with overlapping roles.

This complicated pattern used to be the excuse, if not the justification, of the existence of a plurality of incompatible systems, as information was supposed to flow from source to destination using just one delivery medium, flow of information across media not being intended.

This arrangement is being shaken to its roots by the advent of digital technologies. Because "bits are bits", once audio and video information is converted into digital form, any digitised delivery medium can be used to carry audio-visual information. If the current paradigm of incompatible systems were confirmed and every delivery medium were to set technical specifications independently, the end user would find himself with a multiplicity of sources of information represented by means of bits with an audio-visual meaning different from one delivery system to another. This, in addition to being irrational because the underlying common nature of digital audio and video, runs also counter to the interest of the differnt players, in particular the end users.

This would be a typical issue to be settled by appropriate standards. Unfortunately, standards bodies are still organised along traditional vertically-integrated systems with objective difficulties in addressing cross-system issues. The problem is exacerbated by the current speed of technology which forces an accelerating decision-making pace.

There is no time to lose. Either an effective means of defining horizontal standard cutting across applications is found or the opportunity of putting things right in this epochal conversion from analogue to digital is lost forever.

This paper is about the initiative of creating the Digital Audio-Visual Council, an organisation working with the goal of providing specifications that maximise interoperability across countries and applications/services.


2. What is DAVIC

The absence of an environment able to address interoperability issues across applications and services and across countries and the realisation that one needed to exist is at the root of the Digital Audio-Visual Council (DAVIC). DAVIC was conceived at the end of 1993 and a first meeting convened in Geneva in March 1994. In August 1994 DAVIC had already been formally established in Geneva as a non-profit Association. Its purpose, as set in the Statutes, is to favour the success of emerging digital audio-visual applications and services by the timely availability of internationally agreed specifications of open interfaces and protocols that maximise interoperability across countries and applications/services.

Membership in DAVIC is open to any corporation and individual firm, partnership, governmental body or international organization. DAVIC does not restrict Membership on the basis of race, colour, sex, religion or national origin. By joining DAVIC each Member agrees - both individually and collectively - to adhere to open competition in the development of digital audio-visual products, technology or services. Associate Member status is usually chosen by those entities, mostly government organisations, who do want to be members of the Council without taking an active role in the precise technical content of the specifications.

DAVIC Members are not restricted in any way from designing, developing, marketing or procuring digital audio-visual hardware, software, systems, technology or services. Members are not bound to implement or use specific digital audio-visual standards, recommendations and DAVIC specifications by virtue of their participation in DAVIC.

The (September 1995) DAVIC membership of 200 corporations represents 25 countries from all over the world and virtually all business communities with a stake in the emerging field of digital audio-visual applications and services.

Fig. 1 gives the current organisational structure of the Council. All DAVIC members are represented in the General Assembly (GA). The GA elects the Board of Directors (BD). Besides Finance and Audit (FA), and Membership and Nominating (MN) Committees there are three more Advisory Committees: Standardisation (ST), Strategic Planning (SP) and Management (MC). The technical work is carried out by Technical Committees (TC), under the supervision of the MC. Six TCs have been established: Applications, System Integration, Server, Delivery Systems , Set-top Unit and Technology.

Fig. 1 DAVIC organisation


3. The DAVIC philosophy

DAVIC has developed its own philosophy of work to reach its statutory goals of producing technical specifications providing interoperability across application and countries overcoming the current limitations of standardisation.

  1. Not systems but tools. Traditional standardisation tends to define vertically integrated systems with little or no attention to similar systems in other domains. DAVIC's goal being interoperability across applications systems cannot be specified but "components" (tools) that are non-"system-specific" because they have to be usable by different industries in different systems and still guarantee interoperability. Typically the process of tool specification is carried out as follows:
  2. Relocation of tools. The need to support business and service models of multiple industries impose that not only tools should be usable in a variety of different systems but also in different parts of the same systems. Therefore DAVIC defines its tools in such a way that they can be relocated, whenever this relocation is technically feasible and practically meaningful.
  3. One functionality - one tool. Tools should be unique, a principle sometimes hard to enforce, but compliance to this principle gives substantial benefits in terms of interoperability and availability of technology thanks to the easier achievement of a critical mass because of a wider field of applicability of the technology. Sometimes tools can contain normative improvements to specifications that do not affect backwards compatibility. What constitutes a tool is not always obvious, as tools may depend on the particular technological situation: a video decoder today must be implemented in dedicated silicon, but in a few years it will be possible to have programmable processors where decoding algorithms are "downloaded".
  4. Specify the minimum. That a standard should specify the minimum that is necessary for interoperability looks like obvious. But it was not always so. When standards were produced by associations of particular industries it was natural to add to the "minimum" those nice little things that bring a standard nearer to a product specification. The border of "minimum" then became blurred. This approach was fostered by the concept of "guaranteed quality" so dear to broadcasters and telecommunication operators alike because of their "public service" nature. A multi-industry environment like DAVIC does not have a single constituency to satisfy but tens of them so it has to specify the very minimum that is needed for interoperability.

The need to be able to respond to the changed needs of standardisation still requires that the specification development process be open. Although only DAVIC members are allowed to take part in DAVIC meetings, these are the steps taken by DAVIC to open specification development process and make the specifications available:

  1. When a request for technologies is issued anybody is allowed to submit a response to a Call for Proposals. DAVIC reserves the right to accept or reject a proposed technology after a period of study where the merits of the different proposals are assessed;
  2. When specifications have reached sufficient maturity they made pubblicly available for comments. Anybody is allowed to propose modifications to specifications. DAVIC reserves the right to accept or reject a proposed modification if these point out to the existence of inadequacies or inconsistencies in the published specifications;
  3. DAVIC makes the results of the activities available to all interested parties on reasonable terms applied uniformly and openly;
  4. DAVIC intends to contribute the results of its activities to appropriate formal standards bodies;
  5. DAVIC adheres to the established policy adopted by IEC/ISO/ITU in Intellectual Property Rights (IPR) matters. In case an IPR item is required for implementing a part of the DAVIC specification, the owner of the relevant IPR has to declare his availability to either give free use of the patented items, or licence on fair and reasonable terms and on a non-discriminatory basis.


4. The DAVIC way of producing technical specifications

DAVIC has substantially innovated the way specification work is defined, approved and executed. Purpose of this paragraph is to give a brief description.

As other standard bodies DAVIC activities are structured on the basis of work items (WI). These are the new systems, tools, profiles and reference points that need to be added to the DAVIC specifications and at what time they are needed. The DAVIC workplan (WP) is the collection of all active and planned work items.

The WP is produced by the Board of Directors using a draft proposed by the Strategic Planning Committee. The proposed WP is submitted to the membership for comments and a final WP taking the comments into account is approved by the General Assembly. Complementary to the WP is the "Inventory of Standards and Specifications of potential DAVIC interest" produced by the Technology TC using information coming from standards bodies, industry consortia and individual members.

When a new WI is to be activated a Call for Proposals (CFP) is produced and made known to the membership and all interested parties. Submissions are screened to identify whether, for any of the items requested in the CFP, there is sufficient technology either through submissions or from available standards. If, for any item, insufficient technology is available, another call for these items is issued or a decision to develop the necessary technology internally is made.

Submissions retained for consideration and standards identified to be relevant for the work item are assigned to the appropriate TCs. On this occasion existing TCs may be disbanded and new TCs may be established to provide a better match between the kind of technologies to be specified for the particular new WI and the organisation of work. TCs are given a precise duration of time to produce the version of DAVIC specifications corresponding to the current work item.

A TC produces progressive revisions of the DAVIC specification part(s) assigned to it. In its technical work a TC is driven by the basic requirement of delivering specifications of the highest possible quality within the given deadline. A TC Chair will usually assign sufficient time to clarify an issue and will resort to membership voting when consensus cannot be reached. Of course only one tool may be specified for any functionality. As a principle, specifications draw elements from existing standards, but TCs, in making their decisions, also balance other criteria such as technical merit, cost and wide usage.

When specifications have reached a sufficient degree of maturity they are "frozen". The meaning of "frozen" is that all multiple choices for a DAVIC tool have been reduced to just one. When this is achieved the document is made public, i.e. known also outside the DAVIC membership, and comments are solicited from anybody.

DAVIC holds regular quarterly meetings which typically last five working days. DAVIC weeks usually involve all TCs and the MC. All work is done by Member representatives physically present at the meeting. The work of a DAVIC week is coordinated by the General Assembly meeting in plenary sessions. Plenaries are usually held three times, at the beginning of the first day, on the third day, and at the end of the fifth day. MC meetings are held every day at different times of the day, however, at the end of every working day TC Chairs and Vice Chairs are usually asked to join the MC.

The main purpose of a DAVIC week is to produce either the initial version or the next revision of the DAVIC specifications currently under development. Using the procedure described above the TCs work towards the goal of producing either the initial version or next revision of the part(s) of the specifications they are responsible for. The TCs attempt to reach a consensus on a sequence of issues and on rare occasions they may need to resort to TC membership voting.

Even though on certain issues there are joint TC meetings, the component parts of the specifications are usually so interrelated that daily harmonisation and coordination meetings are called at the initiative of the MC and are attended by TC Chairs and Vice Chairs as required. This process is usually repeated every day of the meeting.

A further synchronisation and consensus building point involving all delegates occurs at the mid-week plenary where short reports are made by the different TC Chairs on the progress of work of their TCs.

In the general case, because of the many synchronisation meetings, the recommendations proposed by the different TCs at the final plenary meeting are accepted, possible modifications being agreed upon by consensus. On certain rare occasions during the final plenary, an issue already resolved by one or more TCs during that week may be the subject of reconsideration if two or more members request a membership vote. At such time as the Chairman of the General Assembly deems that the issue has been sufficiently debated, a vote can be taken of all Members present.

The results of a DAVIC meeting are summarised in a set of approved resolutions, including the recommendations produced by the TCs.


5. The nature of DAVIC specifications

In the current phase of work DAVIC is concentrating on digital audio-visual applications and services of broadcast and interactive type and Fig. 2 is a very general representation of the system being addressed. It comprises 5 entities: the content provider system, the service provider systems and the service user system; the three entities being connected by two entities - delivery systems - the first connecting the content provider to the service provider and the second the service provider to the service user.

As a rule DAVIC specifications contain normative and informative parts. Normative parts have to be implemented as in the specifications in order to claim conformity of a subsystem to DAVIC specifications. Informative parts are included as well for the purpose of clarifying the normative parts of the specifications and to give general assistance to implementors of specifications.

DAVIC specifications contain the reference model of the DAVIC system and its subsystems. DAVIC specifications also define reference points, i.e. points of particular interest in the system. These points have a normative value if they are accessible. Therefore a digital audio-visual subsystem conforms to DAVIC specifications if its accessible reference points do. This means that a subsystem can be considered as a black box and DAVIC specification conformity is only assessed at the external reference points.

DAVIC specifications define the technical "tools" whose use allows the provision of "functionalities" required by the DAVIC system and the applications that make use of it. Tools are usually associated with grades that determine the level of performance of a given tool, e.g. mono-stereo-multichannel audio, TV-HDTV, bandwidth of a return channel etc.

Fig. 2 - The general DAVIC system

DAVIC specifications are issued in versions: DAVIC 1.0, DAVIC 1.1 etc. The current DAVIC 1.0 version of specifications defines a first set of tools enabling the deployment of systems that support initial applications such as TV distribution, near video on demand, video on demand and some basic forms of teleshopping. Each future version will specify different grades of previously defined tools or more tools in addition to previously specified tools.

Even if DAVIC defines only one tool per functionality the toolkit nature of DAVIC specifications would lead to too many incompatible instantiations of subsystems. It is therefore necessary to define groupings of tools with associated grades which are deemed to have a particular value in the application domain. These serve as a guidance to manufacturers and application providers, are called profiles and have normative value.

DAVIC specifications are developed by making use of the best available technologies or combinations thereof and as far as feasible are validated by technical interoperability tests. Because of the toolkit nature of the specifications, however, no claim can be made as to the suitability of DAVIC specifications or of any of its parts for any intended purpose of a user.

As a rule DAVIC specifications are accompanied by documents specifying methods to test the conformity of reference points to the specifications.


6. Outline of DAVIC 1.0

DAVIC 1.0 is organised in 11 parts. These can be classified in three groups, as indicated in Tab. 1. Parts in Group 1 identify all the tools that are necessary to build DAVIC-conforming systems. Parts in group 2 describe how the three main DAVIC subsystems can be assembled using the tools of group 1. Parts in group 3 address system-wide issues.



Part no.



Group 1





High-layer and Mid-layer protocols DAVIC 1.0


Lower-layer protocols and physical interfaces DAVIC 1.0


Information representation DAVIC 1.0


Security DAVIC 1.1


Usage information protocols DAVIC 1.1

Group 2





Service Provider System architecture and interfaces DAVIC 1.0


Delivery System architecture and interfaces DAVIC 1.0


Service Consumer System architecture and interfaces DAVIC 1.0


Content Provider System DAVIC 1.2

Group 3


System-wide issues



Description of DAVIC System functions DAVIC 1.0


System reference models and scenarios DAVIC 1.0


Dynamics, reference points, and interfaces DAVIC 1.0


Conformance testing DAVIC 1.1


7. Tool relocatability, Security and Downloading

This paragraph illustrates the particularly important role played by tool relocatability in supporting the security functionality. It also elaborates on the meaning of downloadability in the Service Consumer System (SCS).

Fig. 3 below is a possible model of an SCS which is in general composed of 4 subsystems:

  1. NIU (Network Interface Unit)
  2. STU (Settop Unit)
  3. HMSC (Human or Machine Service Consumer) and
  4. Security.

The Security subsystem is very important because it controls the way information is consumed. It may happen, therefore, that a network operator is willing to be the guarantor of secure delivery of information to the final user. In this case some of the tools, typically "Security Filter" and "Descrambling" will be resident in the NIU (which is likely to be owned by the network operator), while "Security Management" is likely to be resident in the STU. In other cases all of the Security subsystems will be resident in the STU.

DAVIC does not issue specifications where the location of a tool, which can have multiple locations, is determined a priori, because DAVIC is the place where all those with a stake in digital audio and video can find their needs recognised. Part 10 (Security) will also be published in December 1995, but will not be normative, in the sense that specifications will not appear there yet, as they are planned to be developed for DAVIC 1.1. can find a technical solution to their exploitation plan.

The following guidelines for development of DAVIC 1.1 security tools have been agreed:

  1. In general a security system requires the use of several tools. Tools may have different grades.
  2. DAVIC needs to specify a set of tools each with different grades that can be used to assemble security systems capable of supporting a wide range of applications.
  3. DAVIC will define security tools and their grades by means of the following process
    1. Identification of services/applications of interest to DAVIC members
    2. Identification of functionalities needed by each application
    3. Identification of common functionalities across applications
    4. Definition of a set of tools with appropriate grades supporting the identified functionalites
  4. In this process grade minimisation is strongly demanded
  5. DAVIC may want to describe some typical assembly of tools for some typical applications as an informative annex.
  6. DAVIC will specify its recommended security tools and grades.
  7. DAVIC will specify a mechanism by means of which a Content/Service Provider and a User can negotiate the appropriate tools and grades.
  8. DAVIC will specify a mechanism for replacement/augmentation of its recommended tools.
  9. DAVIC does not want to prevent people from using the mechanisms above for other purposes.

Fig. 3 - Schematic diagram of a Service Consumer System

Downloadability, a subtler form of tool relocatability, is becoming more and more important because the progress of microelectronics is such that even complex algorithms can be executed on generic programmable processors. Flexibility of software implementation can lead to implementation of modules identified in an SCS in hardware or software or a mix of both technologies, modules can be grouped in different ways and need not be physically or logically identifiable and modules can be split in submodules and these can be grouped to produce modules having functions different from those described in the figure.

What is the meaning of interoperability in an environment where downloadability is possible? It is to be noted that an Service Consumer System whose software modules are partly or wholly downloaded can claim conformity to this DAVIC 1.0 specification only if, after software downloading, it can successfully execute DAVIC 1.0 applications, i.e. applications built using information representation tools defined in part 9 "Information representation".


8. The DAVIC workplan

As mentioned before DAVIC published its specifications in versions. DAVIC 1.0, currently being developed, will be published in December 1995. A Call for Proposals has been issued in September 1995 and the corresponding specifications will be published in June 1996. A fourth Call for Proposals will be issued in December 1995 and the corresponding specifications will be published in December 1996.

This information is contained in the DAVIC workplan. This is divided in three sections:

Section 1: Items for DAVIC 1.1;

Section 2: Items for DAVIC 1.2;

Section 3: Future items.

The most important DAVIC 1.1 sub work-items, requested by Call for Proposals #3 are:

The most important DAVIC 1.1 sub work-items, that will be requested by Call for Proposals #4 are:

The third section contains items which will be specified in future activities, e.g.


9. Conclusion

DAVIC has a vision of a digital audio-visual world, where producers of digital audio-visual content can reach the widest possible audience, users have seamless access, carriers can offer effective transport, and manufacturers can provide hardware- and software to support unrestricted production, flow and use of information has been accepted by a large number of companies throughout the world. The DAVIC 1.0 specifications agreed at the Berlin meeting in December 1995 are a proof that it is possible to make that vision real.

Dr. Leonardo Chiariglione Tel. +39 011 228 6120/6116/5111
Multimedia and Video Services Fax +39 011 228 6299/6190/5520
CSELT Email leonardo.chiariglione@cselt.it
Via G. Reiss Romoli, 274 URL http://www.cselt.it/leonardo/
I-10148 Torino (ITALY)