ETSI TS 104 002 V1.1.1 (2023-08)

Publicly Available Specification (PAS); DASH-IF Forensic A/B Watermarking An interoperable watermarking integration schema

DTS/JTC-118

General Information

• Status: Not Published
• Technical Committee: BROADCAS - EBU/CENELEC/ETSI on Broadcasting
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 31-Aug-2023
• Completion Date: 28-Aug-2023

Standards Content (Sample)

TECHNICAL SPECIFICATION
Publicly Available Specification (PAS);
DASH-IF Forensic A/B Watermarking
An interoperable watermarking integration schema

CAUTION
The present document has been submitted to ETSI as a PAS produced by DASH-IF and
approved by the Joint Technical Committee (JTC) Broadcast of the European Broadcasting Union (EBU), Comité Européen de
Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI).
DASH-IF is owner of the copyright of the document DASH-IF CPIX and/or had all relevant rights and had assigned said rights to
ETSI on an "as is basis". Consequently, to the fullest extent permitted by law, ETSI disclaims all warranties whether express,
implied, statutory or otherwise including but not limited to merchantability, non-infringement of any intellectual property rights of
third parties. No warranty is given about the accuracy and the completeness of the content of the present document.

2 ETSI TS 104 002 V1.1.1 (2023-08)

Reference
DTS/JTC-118
Keywords
broadband, CDN, DASH, DRM, internet, PAS

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2023.
© European Broadcasting Union 2023.
All rights reserved.
ETSI
3 ETSI TS 104 002 V1.1.1 (2023-08)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 6
Executive summary . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 OTT Watermarking Using Variants . 9
5 Server-Driven Architecture and Workflows . 10
5.1 Introduction . 10
5.2 Functional Architecture . 10
5.3 System Configuration . 11
5.4 WM Token . 12
5.5 WMPaceInfo . 14
5.5.1 Introduction. 14
5.5.2 WMPaceInfo Data . 14
5.5.3 Conveying WMPaceInfo . 14
5.5.3.1 Introduction . 14
5.5.3.2 Sidecar File . 15
5.5.3.3 HTTP Header . 16
5.5.3.4 ISOBMFF Box . 17
5.5.3.5 SEI Message . 18
5.5.3.6 TS Adaptation Field . 18
5.6 Content Preparation . 18
5.6.1 Introduction. 18
5.6.2 Encoding Recommendations . 19
5.6.3 Delivering Content and WMPaceInfo from the Encoder to the Packager . 19
5.6.4 Segment Ingress Path Structure on the Origin . 20
5.6.4.1 Introduction . 20
5.6.4.2 Locating the Variants . 20
5.6.4.3 Locating the Sidecar File . 23
5.6.5 Packaging Recommendations . 24
5.7 Content Playback . 25
5.7.1 Introduction. 25
5.7.2 Dynamic Ad Insertion . 25
5.7.3 WM Token, DASH Manifest and HLS Playlists Acquisition . 26
5.7.4 Initialization Segment Acquisition . 27
5.7.5 Media Segments and WMPaceInfo Acquisition . 27
5.7.5.1 General Requirements . 27
5.7.5.2 WMPaceInfo Acquisition . 28
5.7.5.3 Discrete Files. 28
5.7.5.4 Byterange . 31
5.8 Monitoring and Watermark Detection . 33
Annex A (normative): Vendor Specific Core API . 34
A.1 Introduction . 34
A.2 Edge-Vendor Specific API . 34
ETSI
4 ETSI TS 104 002 V1.1.1 (2023-08)
Annex B (informative): Examples of Workflows . 35
B.1 Introduction . 35
B.2 Live Content Flows . 35
B.3 VOD Content Flows . 37
Annex C (normative): Registration Requests . 38
C.1 General . 38
C.2 IANA Considerations . 38
C.3 MP4RA Registration . 40
Annex D (informative): Code for Web Sequence Diagram . 41
D.1 Introduction . 41
D.2 Figure 3 . 41
D.3 Figure 5 . 41
D.4 Figure 6 . 42
D.5 Figure 7 . 42
Annex E (informative): Change History . 44
History . 45

ETSI
5 ETSI TS 104 002 V1.1.1 (2023-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European
Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European
Telecommunications Standards Institute (ETSI).
The present document had initially been prepared by DASH-IF (http://dashif.org) and was sent to ETSI under the PAS
agreement.
Comments on the present document may be provided at https://github.com/Dash-Industry-Forum/Watermarking/issues.
NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body
by including in the Memorandum of Understanding also CENELEC, which is responsible for the
standardization of radio and television receivers. The EBU is a professional association of broadcasting
organizations whose work includes the co-ordination of its members' activities in the technical, legal,
programme-making and programme-exchange domains. The EBU has active members in about
60 countries in the European broadcasting area; its headquarters is in Geneva.
European Broadcasting Union
CH-1218 GRAND SACONNEX (Geneva)
Switzerland
Tel: [phone]
Fax: [phone]
ETSI
6 ETSI TS 104 002 V1.1.1 (2023-08)
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document describes proposed architecture and API for supporting forensic watermarking for Over The Top
(OTT) on content that is delivered in an Adaptive Bit Rate (ABR) format. To the possible extend, the proposed
solutions do not make assumptions on the ABR technology that is being used, it can be for example, DASH or HLS.
While digital watermarking can be used for different use cases, the present document focuses on forensic use cases. In
this context, it is used to define the origin of content leakage. the watermarking technology modifies media content in a
robust and invisible way in order to encode a unique identifier, e.g. a unique session ID. The embedded watermark
provides means to identify where the media content, that has been redistributed without authorization, is coming from.
In other words, the watermark is used to forensically trace the origin of content leakage.
ETSI
7 ETSI TS 104 002 V1.1.1 (2023-08)
1 Scope
The present document specifies DASH-IF Forensic A/B Watermarking.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long-term validity.
The following referenced documents are necessary for the application of the present document.
[1] ISO/IEC 23009-1:2022: "Information technology -- Dynamic adaptive streaming over HTTP
(DASH) -- Part 1: Media presentation description and segment formats".
[2] ISO/IEC 13818-1:2019: "Information technology -- Generic coding of moving pictures and
associated audio information -- Part 1: Systems".
[3] IETF Internet Draft draft-pantos-hls-rfc8216bis-12: "HTTP Live Streaming 2nd Edition",
R. Pantos.
[4] IETF RFC 8949: "Concise Binary Object Representation (CBOR)", C. Bormann, P. Hoffman,
December 2020.
[5] IETF RFC 8610: Concise Data Definition Language (CDDL): A Notational Convention to Express
Concise Binary Object Representation (CBOR) and JSON Data Structures", H. Birkholz, C.
Vigano, C. Bormann, June 2019.".
[6] IETF RFC 8392: "CBOR Web Token (CWT)", M. Jones, E. Wahlstroem, S. Erdtman, H.
Tschofenig. May 2018.
[7] IETF RFC 4648: "The Base16, Base32, and Base64 Data Encodings", S. Josefsson, October 2006.
[8] UHD Forum: "Watermarking API for Encoder Integration, version 1.0.1", March 2021.
[9] IEEE Std 1003.1™ 2018 Edition, The Open Group Base Specifications Issue 7, 31 January 2018.
[10] DASH-IF registry of watermarking technology vendors IDs.
[11] IETF RFC 9053: "CBOR Object Signing and Encryption (COSE): Initial Algorithms", J. Schaad,
August 2022.
[12] IANA: "CBOR Web Token (CWT) Claims".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
ETSI
8 ETSI TS 104 002 V1.1.1 (2023-08)
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] DASH-IF Live Media Ingest Protocol.
[i.2] Web Sequence Diagram.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
client-driven watermarking: action of watermarking content when the user device is performing some actions
allowing it to make unique requests for content
NOTE: The user device embeds a watermarking agent that is integrated with the application.
client-side watermarking: action of watermarking when the user device is the sole responsible for doing the actual
watermarking of content
NOTE: The user device embeds a watermarking agent that is integrated with the audio-visual rendering engine.
server-driven watermarking: action of watermarking content when the user device is not performing any other
operation than conveying information such as tokens, between servers that are responsible for doing the actual
watermarking of content that is delivered to the user device
sequencing: action of returning a Variant of a segment when it is requested, based on a watermark token
NOTE: Typically, this action is performed on a CDN edge server and is thus referred to as "edge sequencing".
variant: alternative representation of a given segment of a multimedia asset
NOTE: Typically, a Variant is a pre-watermarked version of the segment.
WaterMark (WM) pattern: series of A/B decisions for every segment that is unique per user device
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ABR Adaptive Bit Rate
AES Advanced Encryption Standard
AF Adaptation Field
API Application Programming Interface
AVC Advanced Video Codec
CBOR Concise Binary Object Representation
CDDL Concise Data Definition Language
CDN Content Delivery Network
CMAF Common Media Application Format
COSE CBOR Object Signing and Encryption
CPU Central Processing Unit
CWT CBOR Web Token
DAI Dynamic Ad Insertion
DASH Dynamic Adaptive Streaming over HTTP
DRM Digital Rights Management
ETSI
9 ETSI TS 104 002 V1.1.1 (2023-08)
ECDH Elliptic Curve Diffie-Hellman
HEVC High Efficiency Video Coding
HLS HTTP Live Streaming
HMAC keyed-Hashing for Message AuthentiCation
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
IOP InterOPerability
IP Internet Protocol
ISOBMFF ISO Base Media File Format
JITP Just In Time Packager
JSON JavaScript Object Notation
JWT JSON Web Token
MPD Media Presentation Description
NAL Network Abstraction Layer
OTT Over The Top
RIST Reliable Internet Stream Transport
RTMP Real-Time Messaging Protocol
RTP Real Time Protocol
SEI Supplemental Enhancement Information
SRT Secure Reliable Transport
TS Transport Stream
TV TeleVision
UDP User Datagram Protocol
UHD Ultra-High Definition
URI Uniform Resource Identifier
URL Uniform Resource Locator
UUID Universally Unique IDentifier
VOD Video On Demand
WM WaterMark
WMID WaterMark IDentifier
WMT WaterMark Token
4 OTT Watermarking Using Variants
The objective of forensic watermarking is to deliver a unique version of a media asset to the different users consuming
the asset. This is somewhat in opposition with media delivery mechanisms that aim at delivering the same asset to all
users for efficiency purposes. As a result, in the broadcast era, a typical approach was to perform the watermarking
operation at the very last step of the media delivery pipeline, within the end user device e.g. a set-top box. This solution
has the virtue of leaving the whole media delivery pipeline unaltered but raises security and interoperability challenges
when a large variety of devices owned and operated by the end user shall be supported. This is for instance the case
with Over The Top (OTT) media delivery where content is consumed on mobile phones, tablets, laptops, connected
TVs, etc. As a result, new forensic watermarking solutions have gained momentum that do not perform security-
sensitive and complex operations in the end user realm. While such approaches require minimal changes in the end-user
devices, they do mandate the media delivery pipeline to be modified accordingly.
A notable example of such network-side watermarking solutions is OTT watermarking using Variants for Adaptive Bit
Rate (ABR) content. In this case, the content is delivered by segments. The baseline idea is then to generate
pre-watermarked Variants of each segment and to modify the delivery protocol so that each end user receives a unique
sequence of Variants depending on a watermark pattern that has been assigned to the end user. The semantic of this
pattern is context dependent and can be, for instance, a device identifier, an account identifier, a session identifier, etc.
Figure 1 illustrates a particular case of this strategy, coined as A/B watermarking, where there are two Variants
generated for each segment, each Variant containing a watermark that either encodes the information '0' or '1'. As a
result, the watermarking system will require the transmission of a sequence of Variants as long as the length of the
pattern to successfully recover the whole unique identifier.
ETSI
10 ETSI TS 104 002 V1.1.1 (2023-08)
Alice
Ingest
Deliver
Bob
Charlie
Original asset
ABR segments at different
Sequence of ABR segments
bitrates
(a) received by three users
Alice
Ingest Deliver
Bob
Original asset Charlie
A/B Variants of ABR segments at
Unique sequence of A/B Variants
different bitrates
received by three users
(b)
Figure 1: A/B watermarking concept with (a) ABR content delivery and (b) A/B Variants delivery
When using Variants, the serialization process essentially boils down to delivering a unique sequence of Variants to
each individual end user. There are two main families of methods to achieve this:
1) Server-driven methods, wherein the client does perform no operation related to watermarking. It simply
fetches and forwards a token to the CDN that is responsible for delivering a unique sequence of Variants.
2) Client-driven methods, wherein the client is responsible for the serialization operation. For instance, it relies
on some session-based digital object to tamper the URI ABR segments and thereby directly query a unique
sequence of Variants from the CDN.
The present document is describing the server-driven methods. Client-driven methods are not part of the present
document.
5 Server-Driven Architecture and Workflows
5.1 Introduction
In the server-driven architecture, the device is unaware that content it consumes is watermarked. The device only
exchanges a token with servers allowing these servers, usually CDN edges, to make the decision on which A or B
Variant it delivers to the device. In the present document, an end-to-end system is presented. It includes the definition of
watermarking metadata that limits the need for naming conventions by allowing the encoder to send this metadata all
the way to the edge through origins to enable the sequencing of bits. The following goes through the functional
architecture and describes the workflows when preparing content and when consuming content.
In the following, it is assumed that the edge is a CDN edge. There are optional architectures, but this does impact the
overall functional architecture and workflows. It is also assumed that multi-track content (audio and video multiplexed
in one segment) is out of the scope of the present document. In addition, all the workflows are only examples of
possible implementations.
5.2 Functional Architecture
Figure 2 shows the simplified high-level functional architecture and the different interaction between the components
that are involved in the flows when a device consumes watermarked content. Note that this also shows that content is
encrypted, as watermarking will likely be added for premium content that is also encrypted and protected by a DRM
system.
ETSI
11 ETSI TS 104 002 V1.1.1 (2023-08)
Encoder/
Watermarker A and B Variants
Packager
Content keys &
A and B Variants
DRM information
Origin
A and B Variants
Authorization WMT
Edge
DRM Server
Server Generator
WM tokens ;
Authz token ;
WM token
Authz token
A or B Variant
License
Device
Figure 2: Functional architecture
To consume content, a device needs, at minimum, to have an authorization token (for getting a DRM license) and a
WM token that contains a WM pattern, a series of A or B decisions. The device is responsible for obtaining the required
data before requesting segments to the CDN.
5.3 System Configuration
Enabling or disabling the edge sequencing logic is set through the configuration to the edge. As an example, this can be
useful for a service of live sporting events where only premium events require watermarking enforcement. Other
moments of the day do not require it. In this case, content is still watermarked but the edge is only configured to
sequence during the limited period of time of the premium event. When sequencing is disabled, the edge shall consume
segments on the endpoint for Variant A. If this endpoint is not working properly, the origin shall deliver any available
Variant on this endpoint.
NOTE 1: When enabling watermarking, all devices that do not have a WM token will receive an error when
requesting content, hence they are then forced to request such token.
NOTE 2: As an example, enabling and disabling sequencing can be done with an API enable (true/false).
Watermarked objects names shall include a pattern that the CDN can match to differentiate these objects from
non-watermarked objects (initialization segments, subtitles, trickplay images). As an example, for a DASH manifest
located at https://edge.hostname/path/to/endpoint/index.mpd that references video segments as:
initialization="video_init_$RepresentationID$.mp4" startNumber="10967120"
presentationTimeOffset="903486496960">

The pattern for the differentiation of these objects from non-watermarked objects is video_segment_.
One of the following identification schemes, referred as variantId in the present document, shall be used for the
identification of the Variants:
- A lower-case letter beginning with 'a'. Variants are then 'a', 'b' and so on.
- A number beginning with 0. Variants are then 0, 1 and so on.
When addressing content, variantId shall be translated into variantPath as follows:
- variantPath = ${variantId} followed by '/' with the exception, that if ${variantId} is 'a' or '0' then
${variantPath} may be empty.
ETSI
12 ETSI TS 104 002 V1.1.1 (2023-08)
5.4 WM Token
A WM token provides a WM pattern which is unique (for example per streaming session or per user). This pattern
allows the sequencing of A/B Variants.
Two tokenization schemes are defined in the present document. The first, named direct, embeds the WM pattern in the
token and can be opened and interpreted by an edge irrespective of the underlying WM technology and provider. The
second, named indirect, requires integration of a WM technology provider's edge sequencing software at the edge.
The following are requirements on the WM token:
- The token shall be a CWT token, the basic structural requirements are defined in IETF RFC 8392 [6].
- The token shall be with integer keys in "deterministically encoded CBOR" as specified in IETF RFC 8949 [4],
clause 4.2.
- Recipients shall process claims listed in IETF RFC 8392 [6], clause 3.1 when they are present. exp and iat
shall be present.
- The token shall include either a WM pattern (direct mode) or data for deriving the WM pattern (indirect
mode). Absence of a wmpattern claim implies that the token is in indirect mode.
- Recipients shall support direct mode and may support indirect mode.
- The token shall be signed as described in clause 7 of IETF RFC 8392 [6]. Recipients shall support the HMAC
256/256 (kty number 5) and ES256 (kty number -7) algorithms.
- The token shall be base64url-encoded as described in clause 5 of IETF RFC 4648 [7].
The following claims are defined and Table 1 provides the integer claim keys:
wmtoken = {
wmver-label ^ => wmver-value,
wmvnd-label ^ => wmvnd-value,
wmpatlen-label ^ => wmpatlen-value,
? wmsegduration-label ^ => wmsegduration-value,
wmtoken-direct // wmtoken-indirect,
* wmext-label => any
}
wmver-value = uint .size 1
wmvnd-value = uint .size 1
wmpatlen-value = uint .size 2
wmsegduration-value = [(wmtimeticks : uint, wmtimescale : uint)]
wmext-label = int
; direct mode
wmtoken-direct = {
wmpattern-label ^ => wmpattern-value
}
wmpattern-value = COSE_Encrypt0 // COSE_Encrypt // bytes

; indirect mode
wmtoken-indirect = {
wmid-label ^ => wmid-value
wmopid-label ^ => wmopid-value
wmkeyver-label ^ => wmkeyver-value
}
wmid-value = text
wmopid-value = uint
wmkeyver-value = uint
ETSI
13 ETSI TS 104 002 V1.1.1 (2023-08)
Table 1: Integer Claim key values for the WM token
Claim label Integer key
wmver-label 300
wmvnd-label 301
wmpatlen-label 302
wmsegduration-label 303
wmpattern-label 304
wmid-label 305
wmopid-label 306
wmkeyver-label 307
wmver
The version of the WM Token. Recipients shall support this claim. The present document describes version 1.
wmvnd
The WM technology vendor. Recipients shall support this claim. This provides the context for the key material needed
for signature verification. In the direct mode, it also provides the context for the key material needed for decrypting
wmpattern if needed. In the indirect mode, it identifies the vendor specific core to use. A list of WM technology
vendor identifiers is available at [10].
wmpatlen
The length in bits of the WM pattern. Recipients shall support this claim.
wmpattern
The WM pattern. Recipients shall support this claim in direct mode. It is recommended to encrypt the pattern.
Recipients shall support ECDH-SS+A128KW (key type -32) as defined in IETF RFC 9053 [11].
wmsegduration
The nominal duration of a segment. This claim is optional. Recipients may support this claim. When WMPaceInfo data
is not available, this may allow the edge to define the index to be considered in the WM pattern. If WMPaceInfo is
available, this claim shall be ignored. The array contains exactly 2 values. The first value is a duration in time ticks
where its base unit is defined by the second value. The second value is the scale in number of time ticks per second. As
an example, [60'000, 10'000] means that the segments are 60'000 ticks long while the scale is 10'000 ticks per second,
wmsegduration is then equal to 6 seconds.
wmid
Used as input to derive the WM pattern for indirect mode. Recipients shall support this claim in indirect mode. The
derivation algorithm is not defined in the present document and is vendor specific.
wmopid
Used as additional input to derive the WM pattern for indirect mode. Recipients shall support this claim in indirect
mode.
wmkeyver
The key to use for derivation of the WM pattern in indirect mode. Recipients shall support this claim in indirect mode.
Once the WM pattern is obtained from the token (either directly, decrypted or calculated), the CDN edge shall enforce
big-endian convention to address a single bit in it when using the value of position (defined in clause 5.5.2).
The following is an example with a WM pattern equal to 0x0A0B0C0D.
Byte 0 1 2 3
bit offset 01234567 01234567 01234567 01234567
binary 00001010 00001011 00001100 00001101
hex 0A 0B 0C 0D
For a value of position equal to 3, the bit to consider is highlighted in green (equal to 0). This is not any other bit,
especially, those highlighted in red.
ETSI
14 ETSI TS 104 002 V1.1.1 (2023-08)
For the indirect mode, there is a vendor specific core (identified by wmvnd). It is recommended that, performance-wise
and software-stack-wise, it is comparable with the direct case. In other words, the vendors specific core should be based
on the crypto operations which are used in the direct mode, and its performance should be equivalent. For example, the
direct mode relies on one decryption operation when wmpattern is encrypted, the vendor specific core should be
consisting of the similar operations to preserve the quantity of operations comparable between these two modes.
5.5 WMPaceInfo
5.5.1 Introduction
When a device requests a segment, the edge sequencing logic needs to know which bit in the unique WM pattern to
consider for retrieving either A or B Variant of the requested segment before delivering it to the device. WMPaceInfo
contains this mapping in addition to some data needed for content preparation. It is transmitted from the encoder (that is
combined with the watermarking pre-processor) to the following servers that may need it (packager, origin, or edge).
5.5.2 WMPaceInfo Data
WMPaceInfo is as shown in Table 2.
Table 2: WMPaceInfo data
Attribute Producer Consumers Purpose
variant Encoder Edge Integration, debugging
position
Encoder Edge Bit position in the WM pattern
firstpart
Encoder Packager, Origin Egress packaging
lastpart
Encoder Packager, Origin Egress packaging

Where
- variant gives the Variant identification, 0, 1 and so on. This information can be useful up to the edge for
verifying that the right Variant has been obtained.
- position is the index in the WM pattern to consider for this segment. Positions are zero-based. When it is
equal to -1, the corresponding segment is not watermarked. For example, position=33 indicates that this
segment refers to position 34 of the WM pattern.
- firstpart informs whether this segment is the first one with this position value. It is equal to true if this is
the case, otherwise it is equal to false. See clause 5.6.2 for further details.
- lastpart informs whether this segment is the last one with this position value. It is equal to true if this is
the case, otherwise it is equal to false. See clause 5.6.2 for further details.
5.5.3 Conveying WMPaceInfo
5.5.3.1 Introduction
WMPaceInfo is delivered from the encoder to other servers. There is no unique mechanism for this. The present
document does not recommend one preferred option applicable for all protocols, Table 3 only presents some possible
options for conveying WMPaceInfo with a preferred option for some protocols (in bold in the table). The following
goes through these different options.
ETSI
15 ETSI TS 104 002 V1.1.1 (2023-08)
Table 3: Possible options for conveying WMPaceInfo information
Ingest protocol WMPaceInfo delivery options
RTMP SEI
RTP/UDP/RIST/SRT SEI, TS adaptation field
HLS/TS over HTTP POST HTTP header, SEI
CMAF-based protocols/formats (HLS/fMP4, DASH) over HTTP POST HTTP header, ISOBMFF box, SEI
File access protocol ISOBMFF box, SEI, sidecar file

5.5.3.2 Sidecar File
When segments (discrete files or byteranges) are delivered with a file transfer protocol, it may be convenient to have
WMPaceInfo data in a sidecar file. For efficiency, the WMPaceInfo data is not copied directly as some would be
included multiple times.
The sidecar file is of the following format (using CDDL representation in IETF RFC 8610 [5]), following
recommendation of clause 5 of IETF RFC 8949 [4] and shall be encoded using deterministically encoded CBOR as
specified in IETF RFC 8949 [4], clause 4.2 with integer keys.
;---------------------------------------+
; Maps Integer Keys
version   = 1
segments   = 2
fileSize   = 3
startRange  = 4
segmentRegex = 5
position   = 6
firstpart  = 7
lastpart   = 8
;---------------------------------------+

discrete-segment = {
?segmentRegex : text,
position :   int .size 2 .ge -1,
?firstpart :  bool,
?lastpart :   bool
}
byterange-segment = {
startRange : uint .size 8,
position :  int .size 2 .ge -1
}
sidecar-discrete = {
version : uint .size 1,
segments : [+ discrete-segment]
}
sidecar-byterange = {
version : uint .size 1,
fileSize : uint .size 8,
segments : [+ byterange-segment]
}
sidecar = (sidecar-byterange // sidecar-discrete)

When segments are discrete files:
- sidecar shall contain only sidecar-discrete elements.
- version is set to 1 for sidecar files compliant to the present document.
- segmentRegex is a POSIX extended regular expression as described in clause 9 of [9]. It allows to define the
segmentRegex is optional.
filename of the segments for which the data applies.
- position, firstpart and lastpart are defined in clause 5.5.2. firstpart and lastpart are optional.
ETSI
16 ETSI TS 104 002 V1.1.1 (2023-08)
NOTE 1: Using regular expressions and file naming conventions allows reducing the number of required side car
files. The same side car file could be used for all renditions for example. This allows the origin to reduce
the number of sidecar files, but the edge will always receive several copies of the same data as caching is
done on the exact filename. It is recommended to balance the advantages and disadvantages of regular
expressions, because of its Central Processing Unit (CPU) load on the origin.
The following is an example for a set of segments where the filenames satisfy the segmentRegex expression. In this
example, the filenames are in the form of video_segment_[repID]_123.mp4,
video_segment_[repID]_124.mp4 and so on, allowing to have one sidecar file for all Representations (for DASH).
sidecar (
/version/ 1,
/segments/ [{/segmentRegex/ "video_segment_ .*?_123.mp4", /position/ 21},
...