Cross Platform Extras: CPE-ManifestCPE-Manifest DRAFT Ref: TR-CPE-M1 Version: v0.7 Date: March 4, 2016 Motion Picture Laboratories, Inc. 1

CPE-Manifest DRAFT

Ref: TR-CPE-M1 Version: v0.7 Date: March 4, 2016

Motion Picture Laboratories, Inc. 1

Cross Platform Extras: CPE-Manifest

CPE-Manifest DRAFT



CONTENTS

1 Introduction ................................................................................................................... 5 1.1 Background ............................................................................................................ 5 1.2 Document Organization ......................................................................................... 5

1.3 Document Naming and Conventions ..................................................................... 5 1.4 Normative References ........................................................................................... 5 1.5 Informative References .......................................................................................... 6

2 Using This Document .................................................................................................... 7 2.1 Using Media Manifest to Support Interactivity ........................................................ 7

2.1.1 Media Manifest Player .................................................................................... 7 2.1.2 CPE-HTML Package as a CPE-Manifest Player ............................................. 8

2.1.3 XML, JSON and Pre-processing ..................................................................... 9 2.2 Related Material ..................................................................................................... 9

3 General Guidance ....................................................................................................... 12 3.1 Packaging Content into Media Manifest XML Documents ................................... 12

3.2 Identifiers ............................................................................................................. 12 3.3 Determining Entitlement ....................................................................................... 12

3.3.1 Matching Avails to Media Manifest ............................................................... 12

3.3.2 Cross-Platform Extras HTML (CPE-HTML) Entitlements .............................. 14 4 Manifest Information Model ......................................................................................... 16

5 Manifest Encoding Constraints.................................................................................... 20 5.1 Metadata .............................................................................................................. 20

5.1.1 Metadata Source .......................................................................................... 20

5.1.2 Required Metadata ....................................................................................... 20

5.2 Applications .......................................................................................................... 22 5.2.1 Application Groups ....................................................................................... 22 5.2.2 Graceful Degradation .................................................................................... 22

5.2.3 Application Reference and Delivery .............................................................. 22 Annex A Profiles ............................................................................................................. 25

A.1. Information Profile IP-0 ........................................................................................ 26 A.2. Information Profile IP-1 ........................................................................................ 27

A.2.1. General Rules ............................................................................................... 28 A.2.2. Experience Structure .................................................................................... 28

A.2.3. Audiovisual, App and Gallery ........................................................................ 29 A.2.4. Metadata ....................................................................................................... 29 A.2.5. Images .......................................................................................................... 29

CPE-Manifest DRAFT



This work is licensed under a Creative Commons Attribution 3.0 Unported License. NOTE: No effort is being made by the Motion Picture Laboratories to in any way obligate any market participant to adhere to this specification. Whether to adopt this specification in whole or in part is left entirely to the individual discretion of individual market participants, using their own independent business judgment. Moreover, Motion Picture Laboratories disclaims any warranty or representation as to the suitability of this specification for any purpose, and any liability for any damages or other harm you may incur as a result of subscribing to this specification.

http://creativecommons.org/licenses/by/3.0/

http://creativecommons.org/licenses/by/3.0/

CPE-Manifest DRAFT



REVISION HISTORY

Version Date Description

1.0 Initial publication

CPE-Manifest DRAFT



1 INTRODUCTION

This document describes Cross Platform Extras Manifest (CPE-Manifest), defining how to

use Common Media Manifest and to create a portable interactive experience.

This document assumes familiarity with the referenced specifications, particular Common

Media Manifest Metadata. In many cases, this document builds on the best practice for delivery

called Using Media Manifest, File Manifest and Avails for File Delivery (Best Practices).

1.1 Background

The MovieLabs Common Manifest allows complex user experiences to be assembled from

individual assets, e.g. a video track, audio track, subtitle track, images, applications and more. It

forms the basis for other aspects of the workflow including product definition and component based

asset delivery.

This document provides specific instructions on using and interpreting Media Manifest

documents to describe content structure, bonus material, metadata, applications and other aspects of

a consumer experience. The experience defined by Media Manifest fully describes content and its

relationship, but leaves the presentation (user interface) to the player designer.

1.2 Document Organization

This document is organized as follows:

1. Introduction—Provides background, scope and conventions

2. Using this Document – Recommendations for document use

3. General Guidance – General rules for using Media Manifest for interactivity

4. Manifest Construction Models – Base models on which specific Profiles are based

5. Manifest Encoding Constraints – Specific encoding instructions for various elements

and attributes

6. Annex: Profiles – Specific Profiles for interactivity Manifests

1.3 Document Naming and Conventions

This document uses conventions as defined in [CM]. This is a less formal document, so strict

conventions may not expressly apply in all cases.

1.4 Normative References

[CM] Common Metadata, TR-META-CM, www.movielabs.com/md/md

[Manifest] MovieLabs Common Media Manifest Metadata v1.4, TR-META-MMM,

www.movielabs.com/md/manifest

http://www.movielabs.com/md/md

http://www.movielabs.com/md/manifest

CPE-Manifest DRAFT



[Avail] EMA Content Availability Data (Avails), TR-META-AVAIL,

www.movielabs.com/md/avails

[Delivery] BP-META-MMMD, Using Media Manifest, File Manifest and Avails for File

Delivery (Best Practices). www.movielabs.com/md/manifest

[IMFDelivery] TR-META-MMMIFM, Using Common Media Format with Interoperable

Media Format, www.movielabs.com/md/manifest

[MEC] Media Entertainment Core, TR-META-MEC, www.movielabs.com/md/mec

[MMC] Media Manifest Core, TR-META-MMC, www.movielabs.com/md/mmc

[CPE-HTML] Cross-Platform Extras API, TR-CPE-API, www.movielabs.com/md/cpe

[EIDR-UG] EIDR 2.0 Registry User’s Guide, eidr.org/technology/

[EIDR-ID] EIDR ID Format, eidr.org/technology/

1.5 Informative References

[CMP] Common Media Package, www.uvcentral.com

[DOI] Digital Object Identifier (DOI), www.doi.org

[XML-C] Canonical XML, Version 1.0. http://www.w3.org/TR/xml-c14n

[ISO26324] ISO 26324:2012, Information and documentation -- Digital object identifier

system

[EIDR-V] How to Use EIDR to Identify Versions for Distribution Purposes: Edits,

Languages and Regional Releases (FAQ), eidr.org/technology

[Chromium] Chromium, open source browser project, http://www.chromium.org

http://www.movielabs.com/md/avails



http://www.movielabs.com/md/mec

http://www.movielabs.com/md/mmc

http://www.movielabs.com/md/cpe

http://eidr.org/technology/

http://eidr.org/technology/

http://www.uvcentral.com/

http://www.doi.org/

http://www.w3.org/TR/xml-c14n

http://eidr.org/technology

http://www.chromium.org/Home

CPE-Manifest DRAFT



2 USING THIS DOCUMENT

This document is targeted to people who are implementing interactivity using CPE-Manifest.

The primary focus is on controlled uses of Media Manifest for supporting a constrained user

experience. For the simple delivery of Trailer or Bonus Material with a title, see Media Manifest

Core [MMC] and section 2.3.2 of Best Practices for Delivery [Delivery].

The Media Manifest is very general and supports many applications. However, it would be

impractical to take an arbitrary Media Manifest and build a user experience around it. Our goal is to

provide an outstanding user experience while keeping both authoring and playback as simple as

possible. So, this document describes rules (constraints) for authoring Media Manifest. From this,

players can be written.

There are two levels of definition

Models – this defines general rules for a set of Profiles.

Profiles – very specific rules for one specific use. Ultimately, every interoperable

implementation must comply with a Profile.

This document defines one Model and two Profiles.

If the reader is looking to implement a specific Profile we suggest reading the rest of this

section for background, then jumping to the specific Profile in the Annex. The Profiles refer back to

earlier sections that provide additional rules. The context of the Profile will aid in the understanding

of the model. Note that implementation of a Profile will ultimately require reading of the entire

document.

This document is intended to be used with Media Manifest Core [MMC] and Best Practices

for Delivery [Delivery]. A properly constructed Manifest built to the delivery best practices defines

the relationships between the various media components (main title, trailers, bonus material, etc.).

This document supplements that definition to help a Manifest fit into a given interactivity profile.

2.1 Using Media Manifest to Support Interactivity

To use the Media Manifest in an interactive application it is necessary to author Media

Manifests in accordance with rules (defined here), and playback that Manifest on a “Player”. What

that Player does with the Manifest is defined by the Profile.

2.1.1 Media Manifest Player

Media Manifest is played through what we refer to here as a “Player”. The Media Manifest

tells the player about the content (metadata), how it is organized, how it is to be played and where to

find it. The Player interprets information from the Media Manifest and creates the user experience.

Although the Media Manifest XML document could hypothetically be directly interpreted by a

Player, we expect that the Media Manifest would be pre-processed into a form more easily

CPE-Manifest DRAFT



interpreted in real time. The Player would need access to all assets referenced in the Inventory

(media tracks, images, apps, etc.)

Experiences, media assets and other assets can be downloaded. Currently, there is one

complete solution for his model, based on the Common Media Package (CMP), documented in

[CMP]. Note that when playing from a downloaded file, playback can be from downloaded files,

online files or both. This gives the flexibility of using streaming for components that are not desired

in the CMP (e.g., to save space).

2.1.2 CPE-HTML Package as a CPE-Manifest Player

One option for playing content using a Media Manifest is HTML. CPE-HTML defines how

to integrate authored content into a retailer environment. In this model, the Media Manifest is input

to an CPE-HTML Package (possibly with pre-processing).

The CPE model is as illustrated here:

The CPE-HTML API facilitates the coordinated efforts of both content producers and content

retailers/distributors in the creation of interactive viewing experiences. [CPE-HTML] defines a

language-neutral interface between the retailer-supplied components (referred to as the

“Framework”) and the content producer’s components (referred to as the “Package”). A full

description is [CPE-HTML].

When using Media Manifest with CPE-HTML, the HTML/JavaScript part of the Package

uses Media Manifest data as input. The CPE-HTML Package would be implemented as a generic

HTLM/JavaScript Manifest player. This player would read the Manifest and act in accordance with

its instructions. The following picture illustrates how CPE-HTML fits into a retailer environment.

CPE-Manifest DRAFT



Note that CPE-HTML can be independent of the Manifest and the Manifest can be

independent of the CPE-HTML. But, in the model we are discussing here, the CPE-HTML is driven

by the Media Manifest.

Note that the retailer could implement its own HTML player, but in that case they would

probably use their own APIs rather than conform to CPE-HTML.

2.1.3 XML, JSON and Pre-processing

Some implementations may prefer a format other than XML for execution within their player

(CPE or otherwise). It is assumed that these implementations will pre-process the XML into a

format more appropriate to their environment. For example, we expect many applications,

especially JavaScript-based apps, will prefer JSON. Preprocessing can also apply to media assets as

well.

MovieLabs sample implementation, found at test.movielabs.com/cpe provides an example of

preprocessing Media Manifest XML into JSON then using that JSON in a player.

2.2 Related Material

The Player needs a Media Manifest, media (audio, video, images, apps), and potentially

entitlement information. Although there are many ways to deliver these pieces, there are supporting

specifications that are fully compatible with this specification. We believe that using these

specifications will ultimately simplify the end-to-end process, illustrated in the following:

Cont

ent

Pro

vid

er

CPE-HTML Package

CPE-Manfest

Reta

ilerC

PL-

HTM

L A

PI

CPE Application

Data

Profiles

Pre

pro

cess

or

CPE-Manifest

Appearance

Orange = Standardized

http://test.movielabs.com/cpe

CPE-Manifest DRAFT



Studio Mastering Distribution Entity

StudioDistribution

RetailerFulfillment

Avail,Initial Metadata

Media Manifest (Product Definition),Metadata

Media,Production Metadata,Media Manifest (Delivery)

Asset Request

Mezzanine

RetailerSales

Order

Reporting

Entitlement

Sales

Fulfillment

InteractivityPreprocessing

Media Manifest (Interactivity)Interactivity metadata

Manifest “Player”ProprietaryFormatManifest App Data

Interactivity Server

microHTML

CPEPackage

CPE Framework

CPE Package

Media Playback

Consumer Experience

Media Server(option)

This model has the following participants. Note that these are roles and do not necessarily

align exactly with corporate entities. Although, this document focuses primarily on the Media

Manifest input to the Retailer, the referenced documents cover the other areas.

Studio – Entity that defines the product and the business rules around the product.

Distribution Entity – generating media files, Media Manifest and File Manifest. This

function is often provided by a post-production organization.

Retailer – Consumes the various pieces as part of offering an experience to the consumer.

Although the term Retailer is used, it does not necessarily imply selling the product.

The model also addresses various data objects and messages. Many of these are described in

referenced specifications:

Product Asset Definition – This is the definition of the various components (abstractly)

that together create an offering. In this document the collection of assets is referred to as

a Logical Asset

Avail – Data defining assets (abstractly) and business terms; such as, when and where the

assets can play, and what pricing tier is used. [Avail]

Order – A Retailer orders based on an Avail.

Asset Request – A Retailer will request assets from the Distribution Entity.

File Manifest – Data describing a set of files that are part of a delivery. See [Manifest].

CPE-Manifest DRAFT



IMF – Interoperable Media Format useful as a mezzanine file [IMFDelivery]

Media Manifest – Definition of how various media assets are connected to provide an

experience to a user. Defined in [Manifest].

Metadata – Consumer-facing description of media assets. This is preferably based on the

Media Entertainment Core (MEC) [MEC].

CPE-Manifest DRAFT



3 GENERAL GUIDANCE

3.1 Packaging Content into Media Manifest XML Documents

As a general rule, the best practice is to put a single media entity (e.g., a movie, TV episode,

trailer, featurette, etc.) in its own XML document. This allows maximum flexibility for ingestion

and incremental deliveries.

3.2 Identifiers

There are multiple identifiers associated with these objects. These are necessary to sustain

the information model, but unfortunately they are confusing. In this section, we provide an informal

description of these identifiers to provide a better intuitive understanding of what they are.

Most identifiers are specific to what they identify so it is important to use them correctly.

Using them correctly will avoid confusion about what is covered by the identified object and will

avoid much confusion and many errors. A detailed discussion of identifiers is provided in

[Delivery], particularly Section 3.

3.3 Determining Entitlement

An Interactivity Player must only play content the user is allowed to play. DRM is the

ultimate method of preventing unauthorized access, but the interactive player should not offer

content that is not playable.

Both Media Manifest and CPE provide information and mechanisms that allow Player to use

entitlement information, wherever it may come from, to determine what the user may see and play.

The following information must be determined:

Content associated with entitlement

‘Condition’ of offering/ownership (e.g., pre-sale, acquired, etc.)

Region and language

Media Profile(s) included in the entitlement (e.g., SD, HD, UHD)

3.3.1 Matching Avails to Media Manifest

3.3.1.1 Mapping ALID to Experiences

It is necessary to map entitlements to Experiences. This model for interactivity is very

similar to the delivery model. That is, an ALID maps to an ExperienceID. In summary, the process

follows these steps:

Map the ALID to one or more Experience elements

Narrow to one localized top-level Experience based on language and region

Determine which tracks match the entitlement Media Profile

CPE-Manifest DRAFT



This is done using MediaManifest/ALIDExperienceMap. This defines the set of Experiences

that satisfy a set of entitlements.

3.3.1.2 Selecting Localized Experience

Entitlements may be specific to a given locale or set of locales. The potential top-level

Experiences must be filtered based on allowed locales. This is done using Experience/Language,

LanguageExcluded, Region and RegionExcluded. These are described in [DManifest] with

additional information provided in [Delivery] Section 8.1.

Only Experiences that satisfy the locale information in the entitlement are allowed. This

should be enforced by the Player.

3.3.1.3 Matching Media Profile

Each track in a Presentation is associated with one or more Media Profiles. This information

is found in

Presentation/TrackMetadata/[Audio|Video|Subtitle|Ancillary]TrackReference/TrackProfile. Each

TrackProfile is associated with a profile definition that is either pre-defined in [Manifest], Section

2.3.3, or an organization-specific namespace. Within the Manifest, namespace is in

TrackProfile/Namespace and that namespace will have zero or more instance of TrackProfile/Profile.

A match occurs when the entitlement’s media profile matches one instance of TrackProfile/Profile

where TrackProfile/Namespace matches the namespace used by the entitlement.

If there are no instances of Namespace in any TrackProfile/Namespace for that track, then it

is assumed that the track is associated with all profiles. Typically, timed text would not be

associated with Media Profile and therefore Subtitle tracks would not include any TrackProfile

instances. These subtitle tracks would then match all media profile entitlements. Note: Do not

confuse this with subtitle resolution which could determine the best esthetics for playback—

completely independently from entitlement.

Therefore, to determine if a track is playable, first determine the entitlement media profile

and the namespace for that media profile. For a given track, if there are no instances of

TrackProfile/Namespace that match the entitlement namespace—including the case of no instances

of TrackProfile—then the track is playable. If there is a matching namespace, then the track is

playable if one instance of TrackProfile/Profile matches the entitlement’s media profile.

3.3.1.4 DECE/UltraViolet Entitlements

The UltraViolet (DECE) ecosystem uses ALID as its primary entitlement identifier. This is

the same ALID used in Media Manifest, so the mapping can be direct.

ALID (ProductID) ALID à Experience ExperienceID

CPE-Manifest DRAFT



MediaManifest/@condition is subject to the actual condition of the sale. If the ALID is in

the User’s DECE Account, @condition would be “Acquired”. Any pre-sale conditions would have

to be known to the player.

Once the candidate Experience elements are identified the player must select the appropriate

one based on region and language. This is generally either a retailer setting or determined by the

player based on its physical device.

Finally, the Rights Token specifies which media profiles are allowed. This is determined by

matching the Media Manifest Presentation’s track reference to the Rights Token. Specifically,

where TrackProfile/Namespace=‘org:decellc.org’ and TrackProfile/Profile matches the Rights

Token’s Media Profile (PurchaseProfile/@MediaProfile). Matching rules are in [Manifest], Section

2.3.3.

3.3.1.5 DMA Entitlements

TBD

3.3.2 Cross-Platform Extras HTML (CPE-HTML) Entitlements

The CPE-HTML API [CPE-HTML] defines APIs to determine entitlements. The Package

presents content accordingly. However, the Framework should prohibit playback of content for

which there is no entitlement. That is, even if the Package makes a mistake and says to play a movie

the user does not own, the Framework must not play that movie.

The CPE-HTML Package must know the ALID. The Player determines entitlement by

passing the ALID as the contentID argument to the getAvailability() call. getAvailability()

is part of the Content Availability API Group found in [CPE-HTML], Section 5. This API returns

information about the entitlement.

The Package must know the localized language and region. Generally, this is obtained from

the browser, although it could be known via other mechanisms.

In a CPE environment the Framework is responsible for identifying and loading the Package

that will instantiate an Experience for a given ALID. Since a single Package may be capable of

handling multiple ALID, the Framework will pass the ALID to the Package as the context

argument when it invokes the Package initialize() function (see [CPE-HTML], Section 4.3.1.1).

The Package is responsible for identifying the appropriate Experience for an ALID based on

entitlement information provided by the Framework. The Package obtains the entitlements by

passing the ALIDs as the contentID argument to the getAvailability() call (see [CPE-HTML],

Section 5.2.1.1). The Package may than select the appropriate Experience using the

ALIDExperienceMaps contained in the manifest. The Framework may obtain the selected

ExperienceId from the Package by invoking the Package's getExperinceId() function (see [CPE-

HTML] Section 4.3.1.6).

CPE-Manifest DRAFT



The Package will next select specific Experience elements based on multiple factors. These

include the region, the capabilities provided by the current operating environment, and user

preferences (e.g. language). The Package will obtain this information via the

getEnvironmentDesc() function ([CPE-HTML] Section 4.2.3.1), getAccountProperties()

function ([CPE-HTML] Section 6.1.1.4), and getPreferences() function ([CPE-HTML] Section

6.1.1.5). If an Experience supports multiple media profiles (e.g., SD or HD), Entitlement information

for specific profiles is obtained by passing the TrackID as the contentID argument of a

getAvailability() call.

CPE-Manifest DRAFT



4 MANIFEST INFORMATION MODEL

This section provides additional guidance on Media Manifest construction. All

recommendations in [Delivery], Section 6 apply except as noted below.

The Media Manifest supports a wide variety of choices of who defines what in the user

interface. This document focuses on what we call the “Informational Model”.

The Information Model supplies the content structure associated with bonus material, but

does not provide any navigation information. The Information Model is used when a pre-defined

user interface expects specific information. Note that this model does not specify the user interface

appearance beyond the inclusion of text and graphics that are used in the UI.

The information model assumes a user interface already exists and is supplying information

to fill in the portion of the user interface associated with information from the Experience.

Consider the following example based on a hypothetical movie, “Way to Row”. This

example complies with Interactivity Profile 1 described later in this document.

The top-level screen is provided by the player. This screen has four options: Play, Extras,

Search and Explore. The Player implements Search and Explore, with no additional information

from the Manifest, other than metadata.

The Play button leads to a screen like the following that plays the movie with additional

material offered on the screen (perhaps when a button is pressed). The first screen shows Shorts and

the second shows Galleries (after Galleries tab is selected). We call the data associated with these

screens “In Movie”.

Extras+

Play

Search

Explore

Way to RowAll Wet Studios

Way to Row Extras BonusWay to Row

Extras Bonus

Play Play

CPE-Manifest DRAFT



Back to the original screen, if the user selects Extras they get the following screen. We call

the data associated with this screen “Out of Movie”.

Notice that there are three tabs along the top, Studio Extras, Cast & Crew, and Share. The

Studio Extras option is based on Media Manifest. The others are implemented by the player,

perhaps using metadata and external data such as social network feeds.

Information is fed from a Media Manifest as illustrated below. In this illustration, each box

represents an Experience element. This example has a “main” Experience that references the film in

an Audiovisual instance. It also has an “in-movie” (used during playback) Experience to describe

the Play screens. And, it has an “out-of-movie” (used outside of playback) Experience that describes

the extras on the “Studio Extras” tab.

Each in-movie child has a Timed Event Sequence associated with it. This information is used by the

Player to synchronize the content with playback.

Extras+

Play

Search

Explore

Way to Row

Studio Extras

Cast & Crew

Share

Racing

Rowers

Regatta

Extras+

CPE-Manifest DRAFT



The trees under “in-movie” and “out-of-movie” drive the In Movie and Out of Movie screens

illustrated above. All other screens are driven by the player application.

“in-movie”

“out-of-movie”

“Extras” “Bonus”

“Regatta”“Racing” “Rowers”

(Timed Event Sequence)

“main”

CPE-Manifest DRAFT



The following picture illustrates how all objects in the Manifest map onto the user interface.

Way to Row Extras Bonus

Way to RowExtras Bonus

Extras+

Play

Search

Explore

Way to Row

Studio Extras

Cast & Crew

Share

Racing

Rowers

Regatta

“in-movie”

“out-of-movie”

“Extras” “Bonus”

“Regatta”“Racing” “Rowers”

(Timed Event Sequence)

“main”

CPE-Manifest DRAFT



5 MANIFEST ENCODING CONSTRAINTS

5.1 Metadata

This section defines which metadata to include.

The best references for metadata are Common Metadata [CM], Best Practices for Delivery

[Delivery] Section 6, and Media Manifest Core [MMC] Section 4 (which references Media

Entertainment Core [MEC]). These should be followed except where they conflict with specific

recommendations in this document. For example, Audiovisual metadata (i.e.,

Audiovisual/ContentID) is not required as there is at most one Audiovisual instance in Experience

element.

5.1.1 Metadata Source

Each Experience instance must include a ContentID element referencing metadata (i.e.,

ContentID is mandatory). The referenced metadata must be in the Inventory (i.e.,

Inventory/Metadata). The Metadata/Alias mechanism may be used.

Images should be handled in accordance with the recommendations in [Delivery], Section

4.2.3. In particular, LocalizedInfo/ArtReference should reference the Inventory via an Image ID.

And, there should be a PictureGroupID in the Experience referencing a Picture Group that references

all the metadata images. Any indirection to image locations should occur through the inventory.

It is recognized that certain implementations may prefer images to be directly referenced

from ArtReference as a URL. This is allowable if both the author and player organizations agree.

Note: Using practices defined in [Delivery] allows interactivity implementers to take

advantage of existing processes such as adding new localization updating media files.

5.1.2 Required Metadata

There are currently three defined uses for metadata

Media Metadata – typical metadata use to describe content

UI metadata for Information Model – text and graphical elements used in an Information

Model-based UI

5.1.2.1 General Metadata Rules

Following are general metadata constraints:

Required elements and attributes must be included.

o WorkType must be correctly encoded as per [CM] and [Delivery].

o RunLength should be 0 duration if not otherwise applicable.

CPE-Manifest DRAFT



If there is more than one instance of LocalizedInfo, the default localization will be the

first instance and have @localized=‘true’

5.1.2.2 Media Metadata

Basic Metadata should include the subset defined as part of the Media Entertainment Core

(MEC) [MEC] definitions for Basic Metadata (Section 2.2.1). Additional metadata is allowed.

Metadata associated with each track in the Inventory should, at a minimum, include those

data defined in MEC, [MEC] definitions for Digital Asset Metadata (Section 2.2.2). Note that the

Inventory schema defines metadata using Common Metadata types, so there is a direct

correspondence between what is specified in MEC and what is in the Inventory.

5.1.2.3 Metadata for Interactivity Model UI

The UI uses metadata as UI elements. Most relevant information is in LocalizedInfo. As this

is user-facing, localizations should be provided for each language of interest.

The exact usage depends on the Profile information. The profile will specify where text is

used, where images are used and constraints on those text and images (e.g., text length; and size and

aspect ratio).

The following rules apply to top-level grouping nodes (i.e., those that are not presented to the

user), such as “in-movie” and “out-of-movie” in the examples above:

There is only one instance of LocalizedInfo

That instance has TitleSort set to the name of the grouping category (e.g., “in-movie” or

“out-of-movie”).

LocalizedInfo@language may contain any language code, and it is ignored.

No other metadata is present unless it is a required element or attribute in the schema.

The following rules apply to nodes that contain user-visible information, such as a title (e.g.,

“Galleries”), an image, or both.

An instance of LocalizedInfo should be included for each language supported for the title.

LocalizedInfo/TitleDisplayUnlimited and TitleSort contains the user-visible name for that

node. Note that even when an image is the intended UI element, text should still be

provided for accessibility (text to speech).

LocalizedInfo/ArtReference includes images associated with the node. Note that as the

reference is already localized and multiple sizes can be included, ImageID is referenced

rather than PictureID.

CPE-Manifest DRAFT



5.2 Applications

Applications are difficult because not all applications can be executed in all environments.

The goal is to support a graceful degradation so that at least some functionality is available across all

platforms. In the worst case, it should be possible to omit the application without substantial

negative impact on the UI.

5.2.1 Application Groups

The Application Group, documented in [Manifest], Section 7.1, provides the mechanism to

signal the same application implemented for different platforms. All applications in the Application

Group should offer the same function. Each application in an Application Group supports a

particular platform. For example, all applications in the Application Group might be mapping

application; one for HTML, one for iOS, one for Android, one for PC, one for Mac, and so forth.

This can be more granular if necessary (e.g., iOS 6-8, vs IOS 9).

It is up to the Player to compare the Compatibility element to its own capabilities and choose

the appropriate app.

5.2.2 Graceful Degradation

Some platforms may be unable to implement certain applications. In this situation, there are

two options

Omit this application – The application disappears from the UI entirely.

Show an image in lieu of the application

The choice of which one goes with the content author. If the application cannot be

implemented and there would be no ‘hole’ in the UI (e.g., a menu list with no items) the application

should be omitted. If a menu item has child elements that only consist of applications that cannot be

played, that menu item is not shown. Authors should take care to avoid situations where this may

occur.

In certain specific cases, an image is a sufficient replacement for the application. For

example, if a mapping application could not be implemented in HTML, it might be sufficient to

show a map image with the point of interest highlighted. An Interactive element is created in the

Inventory as follows:

Type=‘Image’

Encoding/RuntimeEnvironment=‘Default’

PictureID references a Picture that contains the default images. Note that these can be

localized—this is why PictureID is referenced instead of ImageID.

5.2.3 Application Reference and Delivery

Currently, the model for executing application is to follow an URL to HTML5/JavaScript.

CPE-Manifest DRAFT



If a platform supports specific application types, these can be included in the Manifest.

However, delivery is outside the scope of this specification. Generally, these will be delivered in a

manner similar to delivery of content.

Where application-specific data is required, we recommend using Manifest Application Data.

This specification is not yet published, but if you are interested, please contact MovieLabs. This can

support both built-in apps and HTML apps.

5.2.3.1 HTML

A popular model for applications is HTML, even in players that are not HTML/JavaScript

based. This assumes the player has the ability to perform web browsing functions typical in

browser.

The expectation is that the player will support current web browser capabilities. Players that

cannot confidently play a typical web page should probably avoid playing HTML apps.

Web design for HTML apps should follow the same practices as for general internet design.

That is, the app must run across a wide range of platforms.

We have established Chromium R41 as the reference platform for testing.

Specific HTML requirements and recommendations are as follows

Layout shall support a16:9 aspect ratio canvas down to 720x1280 resolution. Non-

standard aspect ratios should be supported.

The recommended title safe area is 70 pixels from each side and 36 pixels from the top,

regardless of resolution. [CHS: Should this be percentage?]

Responsive web design (best experience across a range of devices) is recommended.

Even if initial platforms do not require responsive design, it’s worth considering it for the

long term.

Player interaction with an app is typically minimal. However, when functions addressed

by CPE-HTML are required, they should be implemented using the CPE-HTML APIs.

Custom APIs are strongly discouraged.

Unless CPE-HTML playback APIs are supported, playback through the browser should

use MP4. Playback of video played outside of HTML (i.e., delivered to the retailer)

should be in whatever format is supported by the platform.

When supporting a 5-way remote, typical for the 10’ experience, the following key

mappings should be used. Note that these are standards ASCII values

Button PC Keyboard Key Code

Left Left Arrow 37

Up Up Arrow 38

Right Right Arrow 39

CPE-Manifest DRAFT



Down Down Arrow 40

Ok Enter 13

Last Backspace 8

When at the top-level of the app, the Last button exits the application.

CPE-Manifest DRAFT



ANNEX A PROFILES

The body of this specification defines structure, but leaves some details to the design of

specific UI models. For example, grouping nodes and image aspect ratio choices are not specified

above. Profiles include sufficient implementation to guarantee that a specific set of UI

implementations will receive all information in the correct form.

Note that profiles do not specify media encoding rules (e.g., bitrates, channels, and codecs).

CPE-Manifest DRAFT



A.1. Information Profile IP-0

Information Profile IP-0 assumes no specific interactivity guidance within the Manifest. This

is used when the Retailer determines where and how bonus material is displayed. It works

essentially from Type elements and Metadata rather than from Experience structure, although

Experience structure can be a hint (e.g., Sequence can be used to order elements).

Constraints are as follows:

Profile IP-0 supports any content structure.

Profile IP-0 is based on the Information Model.

In Manifests using Profile IP-0, Compatibility/Profile=‘IP-0’

IP-0 Manifests should comply with delivery as defined in [Delivery].

CPE-Manifest DRAFT



A.2. Information Profile IP-1

Profile IP-1 defines a Manifest with three distinct sections:

Main title (e.g., movie)

Hierarchically organized collection of bonus material designed to fit into a section of a UI

designed for such material. This is referred to as ‘out of movie’.

Groups of time-oriented (tied to the video timeline) collection of bonus material that is

displayed in conjunction with playback. This is referred to as ‘in movie’. [Add “pre-

sale”?]

SequenceNum=1 SequenceNum=1SequenceNum=1SequenceNum=2

“in-movie”

“out-of-movie”

Tab 1 Name Tab 2 Name

Row n Name“Featured” Row 2 Name

SequenceNum=2 SequenceNum=2

(Timed Event Sequences)

Type=”Main”

Tab n Name

... ... ...

...

...

CPE-Manifest DRAFT



A.2.1. General Rules

Profile IP-1 supports a single title (e.g., movie or episode), not a collection such as a TV

season.

Profile IP-1 is based on the Information Model.

In Manifests using Profile IP-1, Compatibility/Profile=‘IP-1’

A.2.2. Experience Structure

Experience Element encoding

(root) Contains a ContentID referencing Basic Metadata in the Inventory that describes the main title (movie)

An Audiovisual instance is included, referencing the main title. Type=‘Main’

Two ExperienceChild instances are included.

Each has Relationship=‘issuplementto’.

The first has SequenceInfo/Number=‘1’and references the “out-of-movie” Experience

The second has SequenceInfo/Number=‘2’and references the “in-movie” Experience

“out-of-movie” Contains a ContentID referencing Basic Metadata in the Inventory that contains TitleDisplayUnlimited and

TitleSort=‘out-of-movie’

For each group of content in out-of-movie, there is one ExperienceChild. In the example, “Racing” is a

grouping. It is encoded as follows

Relationship=‘ispartof’

SequenceInfo/Number starts with one and increases monotonically for each child

References (group) Experience.

(group) Contains a ContentID referencing Basic Metadata in the Inventory that contains a localized

TitleDisplayUnlimited with the user-visible title for the group.

For each item of bonus material (audiovisual, app or gallery) associated with that group, there is one

ExperienceChild. It is encoded as follows:



References (bonus) Experience.

(bonus) Contains and Audiovisual, App or Gallery instance corresponding with an item of bonus material

References metadata with ArtReference referencing images suitable for display as thumbnails underneath

the grouping. Under image specs below, these are referred to as ‘Thumbnails for videos, apps and galleries”.

CPE-Manifest DRAFT



“in-movie” Contains a ContentID referencing Basic Metadata in the Inventory that contains TitleDisplayUnlimited and

TitleSort=‘in-movie’

Contains one ExperienceChild instance for each subcategory referencing Experience elements that describe

these categories. Note that space is assumed to be limited so care should be taken to limit the string length

and number of tabs (generally no more than three). ExperienceChild is encoded as follows:



References (tab) Experience.

(tab) Contains a ContentID referencing Basic Metadata in the Inventory that contains TitleDisplayUnlimited and

TitleSort with the name of the tab (e.g., “Shorts”).

Contains a TimedEventSequence referencing Presentations, Media Applications, Galleries and Text Groups.

Note that these objects will be displayed in the order corresponding with TimedEvent/StartTimecode in

TimedEventSequence.

Contains Audiovisual, App and Gallery instances that correspond exactly with the Presentations, Media

Applications and Galleries referenced in the TimedEventSequence.

A.2.3. Audiovisual, App and Gallery

Audiovisual, App and Gallery instances reference Presentations (PresentationID),

Applications Groups (AppGroupID) and Galleries (GalleryID) respectively.

Each of these is constructed in accordance with rules for their type as defined in [Manifest]

and in the body of this document, with the additional constraints:

Each “Features” Presentation must include Chapters. Each Chapter must have @index,

EntryTimecode and DisplayLabel (localized if appropriate). Chapters should not be

included in bonus content.

Image constraints for galleries are supplied under Images below.

A.2.4. Metadata

The following additional metadata constraints are imposed:

Inventory/Video/Encoding/ActualLength must be included.

A.2.5. Images

All images are 16:9 unless otherwise stated. A few pixels of cropping should be expected.

CPE-Manifest DRAFT



Preferred resolutions are as follows:

Image Type Preferred resolution (pixels)

Thumbnails for videos, apps and galleries 352x198,

714x406,

1076x614

Gallery image 1920x1080

Entity page background image 1280x720