EN 62261-2:2006

SLOVENSKI STANDARD
01-marec-2007
7HOHYL]LMVNLPHWDSRGDWNL±GHO3URWRNRO]DNRGLUDQMHSRGDWNRY]XSRUDER
YUHGQRVWLGROåLQHNOMXþD,(&
Television METADATA -- Part 2: Data encoding protocol using key-length-value
Fernseh-Metadaten -- Teil 2: Protokoll zur Datencodierung mit Schlüssellängenwert
Métadonnées des applications télévision -- Partie 2: Protocole de codage des données
par méthode de longueur de clés
Ta slovenski standard je istoveten z: EN 62261-2:2006
ICS:
33.160.01 Avdio, video in avdiovizualni Audio, video and audiovisual
sistemi na splošno systems in general
35.040 Nabori znakov in kodiranje Character sets and
informacij information coding
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 62261-2
NORME EUROPÉENNE
December 2006
EUROPÄISCHE NORM
ICS 33.160; 35.040
English version
Television METADATA
Part 2: Data encoding protocol using key-length-value
(IEC 62261-2:2005)
Métadonnées des applications télévision Fernseh-Metadaten
Partie 2: Protocole de codage des Teil 2: Protokoll zur Datencodierung mit
données par méthode de longueur de clés Schlüssellängenwert
(CEI 62261-2:2005) (IEC 62261-2:2005)

This European Standard was approved by CENELEC on 2006-12-01. CENELEC members are bound to comply
with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard
the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in two official versions (English and German). A version in any other language
made by translation under the responsibility of a CENELEC member into its own language and notified to the
Central Secretariat has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Cyprus, the Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

© 2006 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 62261-2:2006 E
Foreword
The text of the International Standard IEC 62261-2:2005, prepared by Technical Area 6: Higher data rate
storage media, data structure and equipment, of IEC TC 100, Audio, video and multimedia systems and
equipment, was submitted to the formal vote and was approved by CENELEC as EN 62261-2 on
2006-12-01 without any modification.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
(dop) 2007-12-01
national standard or by endorsement
– latest date by which the national standards conflicting
(dow) 2009-12-01
with the EN have to be withdrawn
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the International Standard IEC 62261-2:2005 was approved by CENELEC as a European
Standard without any modification.
__________
- 3 - EN 62261-2:2006
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.

NOTE  When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year

ISO/IEC 8825-1 2002 Information technology - -
ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding
Rules (DER)
ANSI/SMPTE 1997 Television - Universal Labels for Unique - -
298M Identification of Digital Data

INTERNATIONAL IEC
STANDARD 62261-2
First edition
2005-08
Television METADATA –
Part 2:
Data encoding protocol using key-length-value

 IEC 2005  Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
Commission Electrotechnique Internationale V
International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
For price, see current catalogue

– 2 – 62261-2  IEC:2005(E)
CONTENTS
FOREWORD.4

1 Scope.6
2 Normative references .6
3 KLV protocol.6
3.1 General .6
3.2 ANSI/SMPTE 298M universal label key .7
3.3 Encoding of the KLV length field.10
3.4 Encoding of data values .11
3.5 Empty metadata items.12
4 KLV coding of individual data items .12
4.1 General .12
4.2 Identification of value data representations .12
5 KLV group coding .13
5.1 General .13
5.2 Universal sets .14
5.3 Global sets .14
5.4 Local sets.16
5.5 Variable-length packs.19
5.6 Fixed-length packs .22
6 Labels .24

Annex A (normative)  Glossary of terms.25
Annex B (informative) Example usage of Universal Label Key.27
Annex C (informative) Example of the KLV encoding of a single metadata item .28
Annex D (informative) Example of a universal set .29
Annex E (informative) Example of a global set .30
Annex F (informative) Example of a local set .31
Annex G (informative) Example of a variable-length pack .32
Annex H (informative) Example of a fixed-length pack .33
Annex I (informative)  Example of a label.34

Bibliography.35

Figure 1 – KLV encoding.7
Figure 2 – KLV coded universal set data structure .15
Figure 3 – KLV coded global set data structure.17
Figure 4 – KLV coded local set structure.18
Figure 5 – Informative illustration of local set label to global key linking.20
Figure 6 – KLV coded variable-length pack structure .21
Figure 7 – KLV coded fixed-length pack structure .23
Figure 8 – UL key for labels .24
Figure B.1 – Example of universal label fields for metadata encoding in the SMPTE
namespace .27

62261-2  IEC:2005(E) – 3 –
Table 1 – KLV fields for encoding of data.7
Table 2 – Field descriptions for the universal label key for the KLV encoding of data .8
Table 3 – UL designators for octets 5 through 7.9
Table 4 – Field descriptions for the UL key for the KLV encoding of universal sets .15
Table 5 – Field descriptions for the UL key for global set encoding .17
Table 6 – Coding of registry designator (octet 6) for global set syntax .18
Table 7 – Field descriptions for the UL key for local set encoding .18
Table 8 – Coding of registry designator (octet 6) for local set syntax .19
Table 9 – Field descriptions for the UL key for variable-length pack encoding.21
Table 10 – Coding of registry designator (octet 6) for variable-length pack syntax .21
Table 11 – Field descriptions for the UL key for fixed-length pack encoding.23
Table 12 – Field descriptors for the UL key for labels.24
Table B.1 – Expanded example of SMPTE universal label fields for metadata encoding.27
Table C.1 – Informative example of KLV individual value encoding of metadata.28
Table D.1 – Informative example of KLV universal set encoding of metadata (octets
separated by spaces for readability) .29
Table E.1 – Informative example of KLV global set encoding of metadata (octets
separated by spaces for readability) .30
Table F.1 – Informative example of KLV local set encoding of metadata (octets
separated by spaces for readability) .31
Table G.1 – Informative example of KLV variable-length pack encoding of metadata
(octets separated by spaces for readability) .32
Table H.1 – Informative example of KLV fixed-length pack encoding of metadata
(octets separated for readability) .33
Table I.1 – Example of a label.34

– 4 – 62261-2  IEC:2005(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
TELEVISION METADATA –
Part 2: Data encoding protocol using key-length-value

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62261-2 has been prepared by Technical Area 6: Higher data rate
storage media, data structures and equipment, of IEC technical committee 100: Audio, video
and multimedia systems and equipment
This standard cancels and replaces IEC/PAS 62261 published in 2001.
This first edition constitutes a technical revision.
The text of this standard is based on the following documents:
CDV Report on voting
100/854/CDV 100/955/RVC
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

62261-2  IEC:2005(E) – 5 –
IEC 62261 consists of the following parts, under the general title Television metadata:
Part 1: Metadata dictionary structure
Part 2: Data encoding protocol using key-length-value
Part 3: Universal labels for unique identification of digital data
The committee has decided that the contents of this publication will remain unchanged until
the maintenance result date indicated on the IEC web site under "http://webstore.iec.ch" in
the data related to the specific publication. At this date, the publication will be
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

– 6 – 62261-2  IEC:2005(E)
TELEVISION METADATA –
Part 2: Data encoding protocol using key-length-value

1 Scope
This part of IEC 62261 defines an octet-level data encoding protocol for representing data
items and data groups. This protocol defines a data structure which is independent of the
application or transportation method used.
The standard defines a key-length-value (KLV) triplet as a data interchange protocol for data
items where the key identifies the data, the length specifies the length of the data, and the
value is the data itself. The KLV protocol provides a common interchange for all compliant
applications irrespective of the method of implementation or transport.
The standard also provides methods for combining associated KLV triplets in data sets where
the set of KLV triplets is itself coded with KLV data coding protocol. Such sets can be coded
in either full form (universal sets) or in one of four increasingly bit-efficient forms (global sets,
local sets, variable-length packs, and fixed-length packs). The standard provides a definition
of each of these data constructs. The encoding octet range (length of the payload) specified
in this standard may generate unusually large volumes of data. Consequently, a specific
application of KLV encoding is capable of only a limited operating data range and those
details shall be defined in a relevant application document.
Of necessity, keys and other reference data have to be globally unique if clashes are to be
avoided. The IEC will therefore, from time to time, designate other bodies to act as its
registration authority and agent in this respect; it is important to note that, as a result of this,
registrations will always contain the designator of the registration authority acting at the time
of registration and not that of the IEC (unless the IEC was acting directly as its own
registration authority). A mixture of registration authority designators is therefore to be
expected.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.
ISO/IEC 8825-1:2002, (ITU-T X.690), Information Technology – ASN.1 Encoding Rules –
Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and
Distinguished Encoding Rules (DER)
ANSI/SMPTE 298M:1997, Television – Universal Labels for Unique Identification of Digital
Data
3 KLV protocol
3.1 General
Table 1 and Figure 1 present an introductory view of the KLV protocol for encoding data. The
data encoded may be a single data item or a data group. The coding of data items is
described in Clause 4 while the coding of data groups is described in Clause 5 of this
standard.
62261-2  IEC:2005(E) – 7 –
The KLV coding protocol is composed of a universal label (UL) identification key (UL key),
followed by a numeric length (value length), followed by the data value.
The composition of the UL key is described in 3.2 of this standard. The length of the full UL
key shall be 16 octets. The length field is described in 3.3 of this standard. The value is
described in 3.4 of this standard. The value is a sequence of octets of the data type as
specified in a relevant standard and is not further specified by the KLV protocol. The length of
the value field is variable and any limitations are defined in a relevant defining standard.
Table 1 – KLV fields for encoding of data
Field Description Length Content/Format
UL key Universal label for identification of 16 octets Subclause 3.2
the value
Length Length of the value field Defined in a relevant dictionary, essence, Subclause 3.3
application standard, but variable length
Value Value associated with the UL key Variable Subclause 3.4

Length
UL Key Length Value
16 octets BER Variable Length Octets

IEC  1161/05
Figure 1 – KLV encoding
The bit-order (lsb or msb first) for KLV encoding shall be that of the transport used to carry
the information.
3.2 ANSI/SMPTE 298M universal label key
3.2.1 General
KLV coding protocol shall use a 16-word universal label (UL) generated according to
ANSI/SMPTE 298M as the UL key to identify the data in the value field but with the
appropriate registration authority’s 4-octet prefix following the OID tag and length byte.
Each word in the ANSI/SMPTE 298M UL is coded using the basic encoding rules (BER) for
the encoding of an object identifier value specified in ISO/IEC 8825-1, 8.19. Each word of the
UL key shall be limited to the range 0x00 to 0x7F and shall be represented by a single octet.
The UL key shall have left-to-right significance with the first octet as the most significant. The
leftmost octet of value 0x00 in the UL key shall define the termination of the label and all
octets of lower significance shall also be set to 0x00. Octets of value 0x00 shall have no
significance to the meaning of the UL key.
The full UL key consists of a 16-octet field including an object ID (OID) and the UL size (0x0E
indicating a total UL key size of 16 octets) followed by a UL code and a series of sub-
identifiers which shall define the UL designators. The first two UL designators shall have
reserved values for the KLV coding protocol according to this standard.

– 8 – 62261-2  IEC:2005(E)
NOTE The ANSI/SMPTE UL itself adopts KLV coding with the object ID as the key, the UL size as the length, and
the UL designators as the value.
When applying the ANSI/SMPTE UL to the coding of data according to this standard, these
fields shall be categorized as the UL header, UL designators, and item descriptor as shown in
Table 2.
Annex B shows an informative example of a metadata UL key in tabular and figure formats.
Note that decoders which recognize the UL key but do not want to, or cannot, decode the
associated value, may ignore the item and shall continue the decoding process of subsequent
items using the length value to skip the value of the undecoded item. If decoders only store or
forward the item, they shall forward the item unaltered.
3.2.2 UL designators
Table 3 defines octet values for the designators to be used in octets 5 through 7 of the UL
designators. Standards and recommended practices which define a UL key with the value of
octet 5 (registry category designator) in the range 0x01 to 0x04 shall register the full UL key
or keys used with the IEC’s designated registration authority in the registry identified by octets
6 and 7 (registry designator and structure designator).
Table 2 – Field descriptions for the universal label key for the KLV encoding of data
No. Field Description Length Content/format
UL header
1 OID Object identifier 1 octet Always 0x06
2 UL size 16-octet size of the UL 1 octet Always 0x0E
UL designators
3 UL code Concatenated subidentifiers ISO, ORG 1 octet Always 0x0B
4 Registration Registration authority subidentifier 1 octet Dependant on
authority designator Registration Authority
(for example, 0x34 for
SMPTE)
5 Registry category Registry category designator identifying the 1 octet See Table 3
designation category of registry described (for example,
dictionaries)
6 Registry designator Registry designator identifying the specific 1 octet See Table 3
registry in a category (for example, metadata
dictionary)
7 Structure Designator of the structure variant within the 1 octet Subclause 3.2.3
designator given registry
8 Version number Version of the given registry which first defines 1 octet Incrementing number
the item specified by the item designator
9-16 Item descriptor Unique identification of the particular item within 8 See relevant standard
the context of the UL designator octets
and version
62261-2  IEC:2005(E) – 9 –
Table 3 – UL designators for octets 5 through 7
Registry
Registry Structure
category Described in
Octet 6 Octet 7
Octet 5
01 - Dictionaries Clause 4
01 – Metadata dictionaries 0x01-0x07F – Structure designator Other standard/practice
02 – Essence dictionaries 0x01-0x07F – Structure designator Other standard/practice
03 – Control dictionaries 0x01-0x07F – Structure designator Other standard/practice
04 – Types dictionaries 0x01-0x07F – Structure designator Other standard/practice
02 – Groups (sets and packs) Clause 5
01 – Universal sets 0x01-0x07F – Structure designator Subclause 5.2
02 – Global sets (default) 0x01-0x07F – Structure designator Subclause 5.3
03 – Local sets (default) 0x01-0x07F – Structure designator Subclause 5.4
04 – Variable-length packs 0x01-0x07F – Structure designator Subclause 5.5
(default)
05 – Fixed-length packs 0x01-0x07F – Structure designator Subclause 5.6
03 – Wrappers and containers
01 – Simple wrappers 0x01-0x07F – Structure designator Other standard/practice
02 – Complex wrappers 0x01-0x07F – Structure designator Other standard/practice
04 – Labels Clause 6
01 – Labels dictionary 0x01-0x07F – Structure designator Other standard/practice

3.2.2.1 Dictionaries
Standards and recommended practices which define the value of word 5 of the UL key as
0x01 are dictionary standards and shall be used to define single data items with the KLV data
construct. The coding of individual items is defined in Clause 4.
3.2.2.2 Sets and packs
Standards and recommended practices which define the value of word 5 of the UL key as
0x02 are set and pack standards and shall be used to define groups of KLV coded data items.
The coding of data groups is defined in Clause 5.
3.2.2.3 Wrappers and containers
Standards and recommended practices which define the value of word 5 of the UL key as
0x03 are wrapper and container standards and use the UL key to identify the wrapper or
container and its contents. Wrappers and containers differ from sets and packs in that they do
not necessarily employ an overall KLV data construct for the entire contents of the wrapper or
container. It is recommended that individual parts of a wrapper or container encode data
using the KLV coding protocol, but these parts may be bound together by other techniques. In
some cases, a wrapper or container may employ an overall KLV construct in certain
applications (such as a streaming interface) but employ another technique in other
applications (such as a storage container). In these cases, the wrapper or container is not
redefined as a set or a pack but retains the definition as a container or wrapper for
consistency of identification.
Simple wrappers and containers are defined as embedding all the data into a single
framework with no external references. Complex containers and wrappers are defined by
frameworks where individual data items may be included in a file by reference rather than
embedding. Complex containers and wrappers can be more efficient and are suited to local
environments where references can be easily resolved. The definition of wrappers and
containers is outside the scope of this standard and can be found in other documents.

– 10 – 62261-2  IEC:2005(E)
3.2.3 Structure designator
Octet 7 shall contain the structure designator for the given registry. Structure designators are
allocated to distinguish between incompatible versions of the same registry. They may be
thought of as a major version number.
NOTE Different structure designators may be assigned when a registry becomes so cluttered that it has outlived
its usefulness, or when changes to the contents, structure, or class relationships of the registry are necessary
which prevent backward compatibility.
Different structure designators may also be assigned to distinguish between different syntax
rules for construction and interpretation of values. Different structure designators may also be
assigned when more than one standard or practice is used to define the contents of a specific
registry. The precise discipline for allocation of structure designators is described for each
specific registry in the clauses below.
3.2.4 Version number
Octet 8 shall contain the version number of the given registry which first defines the item
specified by the item designator.
New items may be added to registries after initial approval of the controlling standard or
practice. Each time a set of item definitions is added, the current version number of the
particular registry is incremented. Each entry in a registry includes the version number in
which the item was first defined. It is this number which is carried in octet 8.
Parsers may use the version number as an additional guide and consistency check in the
process of parsing a UL key.
3.2.5 Item designator
Octets 9 through 16 of the UL key comprise the item designator. The item designator field is
fixed 8 octets in length. Item designators are from 1 to 8 bytes long, and are padded on the
right with zero octets to fill the 8-byte field. ASN.1 object identifier coding is used to provide
for allocation of varying quantities of sub-identifiers in a hierarchical manner.
The precise meaning and construction of the item designator depends upon the specific
registry and structure variant, and is described further in the clause below.
3.3 Encoding of the KLV length field
In the KLV coding protocol, the value of the length field shall be encoded using the basic
encoding rules (BER) for either the short-form or long-form encoding of length octets specified
in ISO/IEC 8825-1, 8.1.3. This method of value length encoding is self-contained and allows
for efficient parsing of KLV encoded data. When the KLV coding protocol is applied to groups
of KLV coded units, the length field for individual units may adopt a different method as
defined by the standard for the coding of that group (see Clause 5).
NOTE 1 Bits are numbered bit 8 to bit 1 with bit 8 as the MSB.
NOTE 2 Receivers/decoders must decode the length field correctly whether the long or short form is used.
3.3.1 BER short-form length encoding
The following normative subclause (including the example) is quoted from ISO/IEC 8825-1:
8.1.3.4: In the short form, the length octets shall consist of a single octet in which bit 8
is zero and bits 7 to 1 encode the number of octets in the contents [value]
octets (which may be zero), as an unsigned binary integer with bit 7 as the
most significant bit.
Example: L = 38 can be encoded as 00100110 .
62261-2  IEC:2005(E) – 11 –
The short form for length encoding shall be used whenever the data value length is less than
128 octets.
3.3.2 BER long-form length encoding
The following normative subclause (including the example) is quoted from ISO/IEC 8825-1:
8.1.3.5: In the long form, the length octets shall consist of an initial octet and one or
more subsequent octets. The initial octet shall be encoded as follows:
a) bit 8 shall be one;
b) bits 7 to 1 shall encode the number of subsequent octets in the length
octets, as an unsigned binary integer with bit 7 as the most significant bit;
c) the value 11111111 shall not be used.
NOTE 1 This restriction is introduced for possible future extensions.
Bits 8 to 1 of the first subsequent octet, followed by bits 8 to 1 of the second subsequent
octet, followed in turn by bits 8 to 1 of each further octet up to and including the last
subsequent octet shall be the encoding of an unsigned binary integer equal to the number of
octets in the value field, with bit 8 of the first subsequent octet as the most significant bit.
NOTE 2 This is sometimes known as big-endian byte order.
Example: L = 201 can be encoded as: Octet 1 = 10000001 Octet 2 = 11001001 [b8 . b1]
2 2
NOTE 3 While there are no restrictions in this standard on the maximum number of octets in the data value length
field, the presence of large data value lengths can be determined from the first octet in the BER long-form length
encoding.
Where appropriate, individual application standards and recommended practices may define
the maximum octet length of the length field or may place limitations on the value range of the
length field in order to simplify decoder requirements.
Implementations shall make every effort to apply a valid value to the length field. However, in
certain operations, it may prove impractical to establish the length of the value field. Such a
case is an incoming data stream which is assigned a key and a length field at the start point.
In this case, the value of the length cannot be established until the termination of the stream
and at that point, it may prove impossible to return to the length field to enter the value. In
such cases, the length field shall be set to [0x80] which shall indicate a non-deterministic
length of the value field. Any application document which allows the length of the value field
to be undefined must define an alternative method of locating the end of the value field.
NOTE The length value [0x80] is used because it is normally meaningless as a BER long-form value as it
indicates zero subsequent octets.
3.4 Encoding of data values
Data values may be either individual data items or data groups. In either case, the data is an
octet string whose length is specified by the length value. The last octet of the value shall be
the terminating octet of the data sequence.

– 12 – 62261-2  IEC:2005(E)
3.5 Empty metadata items
Specifications for contiguity of KLV packets, including any gaps between KLV packets, are
outside the scope of this standard, and are addressed in the appropriate transport layer
documents. However, should applications so require it, breaks in the data sequence can be
inserted by the use of a specific empty metadata item. Use of empty metadata items is not
mandatory. The empty metadata item is a KLV coded packet which shall define a length value
followed by an empty value field. No attempt should be made to interpret the data in the value
field.
The empty metadata item shall be defined in the metadata dictionary. Empty metadata items
may be coded as individual items or within sets, when allowed by the specific set definition.
Applications may delete or skip any or all empty metadata items upon receipt. Applications
may insert empty metadata items but shall not require other applications to preserve such
items.
4 KLV coding of individual data items
4.1 General
The KLV coding of individual data items is a simple application of the key, length, and value
as defined in Clause 3.
The UL key of individual data items is defined in a dictionary together with the ranges of
length and the specification of the value itself. For individual data items, the value of word 5
of the UL key shall be 0x01.
4.2 Identification of value data representations
The value of many dictionary items can be represented in more than one way. For example, a
start time in the metadata dictionary can be represented as a character string of the time code
or as an efficient bit-packed form. The first offers direct mapping to a display whereas the
second offers high-transmission efficiency for use in narrow-band data channels. There are
many such dictionary items which have multiple data representations for the same descriptor.
Where a dictionary item has more than one data representation for the value, one
representation shall be designated as the default representation and shall be assigned a key
with at least one trailing zero octet. Alternate representations shall be assigned keys by
replacing the leftmost trailing zero octet with nonzero values, which shall be assigned
sequentially. Each representation shall be documented in the dictionary.
Example:
01.02.03.04.00.00.00.00 is name (default data representation in UTF 16 unicode characters);
01.02.03.04.01.00.00.00 is name (different data representation in ISO 7-bit characters);
01.02.03.04.02.00.00.00 is name (another data representation in UTF 8 unicode characters).
The parser treats all representations as the same item; i.e. it recognizes 01.02.03.04.00, then
looks for xx in place of the 00 to identify different encodings. Since the default representation
is defined, the extra non-zero term in the fifth position is known to be a new data
representation of the default dictionary item and not a new dictionary entry.
Many dictionary values share a common set of definitions for multiple data representations.
To simplify the dictionary definitions, a types dictionary shall be used to define these data
representations. The types dictionary shall be used as a shared resource for all other
dictionaries.
Annex C shows an example of KLV coding for a single metadata item.

62261-2  IEC:2005(E) – 13 –
5 KLV group coding
5.1 General
Group coding of data elements can be used to reduce the overhead of repeating redundant
information that appears in the key of each unit. Group coding also allows logical groups of
individual data elements, or groups of elements, to be encoded together and provides options
for increased coding efficiency. In steps of increasing code efficiency, the KLV coding
protocol can be used to support universal sets, global sets, local sets, variable-length packs,
and fixed-length packs described as follows.
– Universal sets shall be used to construct a logical grouping of data elements and other
KLV encoded items. Universal sets use the full KLV coding construct throughout.
– Global sets are defined as per universal sets, but offer coding efficiency by sharing a
common key header. This coding gain is lossless and every UL key can be fully recovered
from the data in the global set alone.
– Local sets are defined as per universal sets, but offer coding efficiency through the use of
short local tags whose meaning is defined only within the context of the local set. Local
sets retain the KLV data construct but require a separate standard or recommended
practice to define the meaning of the local tags and to provide a map from the local tag
value to the UL key value.
– Variable-length packs are defined as a further grouping of data elements that eliminates
the use of UL keys and local tags for all individual elements within the group. Variable-
length packs, therefore, rely on a standard or recommended practice which defines the
order of data elements within the pack.
– Fixed-length packs are the most efficient (and least flexible) grouping of data elements
that eliminates the use of both UL keys and local tags and removes the length for all
individual elements within the group. Thus, fixed-length packs rely on a standard or
recommended practice which defines both the order of data elements and the length of
each data element within the pack.
Sets and packs shall consist of a number of individual data elements which are coded as a
group by the KLV set or pack data construct. The set or pack shall be defined by a full UL key
whose value shall be registered with the designated IEC registration authority. A set may
encode data elements which are themselves sets or packs as well as individual dictionary
items. This is called KLV recursive coding, and this standard provides no limit on the number
of levels of recursion which may be used by any particular application. A pack shall only
encode a group of individual dictionary items, i.e. packs shall not use recursive coding.
The presence of sets or packs shall be indicated by 0x02 in the registry category designator
field (octet 5) of the set or pack UL key. The registry designator field (octet 6) shall be used to
identify the type of set or pack. The set or pack standard or practice and registry shall be
identified by the structure designator field (octet 7) and the version of the registry shall be
identified by the version number field (octet 8).
The length of a set or pack shall be encoded as either BER short-form or long-form coding.
Application standards or recommended practices may provide an upper bound to the value of
the BER coded length to ease decoder requirements. Application standards or recommended
practices may also provide a fixed-length coding scheme specific to the application for sets or
packs embedded within sets or packs. However, this is discouraged.
Where the length fields of the KLV items in a global set, a local set, and a variable-length
pack are identified as fixed length, the most significant byte shall be encoded first (big-
endien). The set or pack value shall be comprised of a number of individual data elements
with coding as defined by the set or pack type.
The following clauses define how the data elements are encoded for universal sets, global
sets, local sets, variable-length packs, and fixed-length packs.

– 14 – 62261-2  IEC:2005(E)
5.2 Universal sets
The UL key of a universal set shall be defined by an accompanying standard or recommended
practice including a structure designator and an accompanying universal set registry including
a version number. The UL key of a universal set shall be 16 octets in length.
The length of a universal set shall be coded as per ASN.1 notation, BER long or short form as
required. The value of a universal set shall be a sequence of KLV-encoded elements whose
total length is given by the length field. Each and every data element in a universal set shall
apply KLV data coding protocol including the full UL key value.
Relevant application standards or practices may specify constraints upon the value of a
universal set such as the number and size of items, the allowed sequence of items, and
whether any items are mandatory or optional.
The UL key for universal sets is described in Table 4. Figure 2 illustrates the data structure
for the encoding of universal sets.
5.3 Global sets
The UL key of a global set shall be defined by an accompanying standard or recommended
practice including a structure designator and an accompanying global set registry including a
version number. The UL key of a global set shall be 16 octets in length. The length of a global
set shall be coded as per ASN.1 notation, BER long or short form as required.
The value of a global set shall be a sequence of KLV-encoded elements wh
...