apex specification 0415 media & device ife ecosystem … · 2019-05-06 · • enabling content...

AIRLINE PASSENGER EXPERIENCE ASSOCIATION

APEX SPECIFICATION 0415

MEDIA & DEVICE IFE ECOSYSTEM SPECIFICATION

VERSION 2

© 2019 Airline Passenger Experience Association. All Rights Reserved.

The Airline Passenger Experience Association (APEX) is the author and creator of this specification for the purpose of copyright and other laws in all countries throughout the world. The APEX copyright notice must be included in all reproductions, whether in whole or in part, and may not be deleted or attributed to others. APEX hereby grants to its members and their suppliers a limited license to reproduce this specification for their own use, provided it is not sold. Others should obtain permission to reproduce this specification from the Airline Passenger Experience Association, Attn: Executive Director, 355 Lexington Avenue, 15th Floor, New York, NY 10017 USA; Phone: (212) 297-2177; Fax: (212) 370-9047; email: [email protected].

© 2019 APEX of 37 Version 2 draft16 – 2019-Mar-28

IMPORTANT NOTICES

This document is a specification adopted by the Airline Passenger Experience Association (APEX). This document may be revised by APEX. It is intended solely as a guide for companies interested in developing products that can be compatible with other products developed using this document. APEX makes no representation or warranty regarding this document, and any company using this document shall do so at its sole risk, including specifically the risks that a product developed will not be compatible with any other product or that any particular performance will not be achieved. APEX shall not be liable for any exemplary, incidental, proximate or consequential damages or expenses arising from the use of this document. This document defines only one approach to compatibility, and other approaches may be available to the in-flight industry.

This document is an authorized and approved publication of APEX. Only APEX has the right and authority to revise or change the material contained in this document, and any revisions by any party other than APEX are unauthorized and prohibited.

Compliance with this document may require use of one or more features covered by proprietary rights (such as features which are the subject of a patent, patent application, copyright, mask work right or trade secret right). By publication of this document, no position is taken by APEX with respect to the validity or infringement of any patent or other proprietary right. APEX hereby expressly disclaims any liability for infringement of intellectual property rights of others by virtue of the use of this document. APEX has not and does not investigate any notices or allegations of infringement prompted by publication of any APEX document, nor does APEX undertake a duty to advise users or potential users of APEX documents of such notices or allegations. APEX hereby expressly advises all users or potential users of this document to investigate and analyze any potential infringement situation, seek the advice of intellectual property counsel, and, if indicated, obtain a license under any applicable intellectual property right or take the necessary steps to avoid infringement of any intellectual property right. APEX expressly disclaims any intent to promote infringement of any intellectual property right by virtue of the evolution, adoption, or publication of this document.


TABLE OF CONTENTS

1 FOREWORD ......................................................................................................................................................... 52 SCOPE .................................................................................................................................................................... 73 REFERENCE MODEL ........................................................................................................................................ 84 REFERENCES & DEFINITIONS .................................................................................................................... 114.1 NORMATIVE REFERENCES ................................................................................................................................... 114.2 INFORMATIVE REFERENCES ................................................................................................................................. 114.3 DEFINITIONS OF TERMS ....................................................................................................................................... 125 MEDIA OBJECTS .............................................................................................................................................. 145.1 MEDIA PACKAGING ............................................................................................................................................. 145.2 MEDIA PROFILES ................................................................................................................................................. 145.2.1 IFE-SD Video Profile ...................................................................................................................................... 145.2.2 IFE-HSD Video Profile ................................................................................................................................... 155.2.3 IFE-HD Video Profile ..................................................................................................................................... 155.2.4 IFE-HHD10 Video Profile .............................................................................................................................. 165.2.5 IFE-UHD10 Video Profile .............................................................................................................................. 165.2.6 IFE-HDR10 Video Profile ............................................................................................................................... 175.2.7 IFE-AAC Core Media Profile .......................................................................................................................... 185.2.8 IFE-IMSC1 Text Subtitle Media Profile .......................................................................................................... 186 AUDIO PROGRAM LOUDNESS AND TRUE-PEAK ................................................................................... 196.1 OVERVIEW .......................................................................................................................................................... 196.2 DIALOG LEVEL .................................................................................................................................................... 196.3 MAXIMUM PROGRAM LOUDNESS ........................................................................................................................ 196.4 MAXIMUM DIALOG/PROGRAM DIFFERENCE ........................................................................................................ 196.5 MAXIMUM LOUDNESS RANGE ............................................................................................................................ 206.6 MAXIMUM TRUE-PEAK ....................................................................................................................................... 207 CONTENT IDENTIFICATION ........................................................................................................................ 217.1 CONTENT ............................................................................................................................................................. 217.2 ADVERTISEMENT ................................................................................................................................................. 218 SECURITY .......................................................................................................................................................... 228.1 SECURITY REQUIREMENTS: CONTENT VS. PLAYBACK DEVICES ......................................................................... 238.1.1 Common Encryption (MPEG-CENC) ............................................................................................................. 248.2 SECURITY REQUIREMENTS: CONTENT TYPES VS. LICENSE SERVERS .................................................................. 258.3 DRM ................................................................................................................................................................... 288.4 WATERMARKING ................................................................................................................................................. 288.4.1 Forensic Watermarking ................................................................................................................................... 288.4.2 Visible Watermarking ...................................................................................................................................... 288.5 WIRELESS CONTENT LOADING ............................................................................................................................ 299 INFORMATIVE ANNEX- TECHNICAL ........................................................................................................ 309.1 AUDIO BITRATE RECOMMENDATIONS ................................................................................................................. 309.2 DELIVERY TARGETS FOR SPECIFIC OPERATIONS ................................................................................................. 319.2.1 Simple .............................................................................................................................................................. 319.2.2 Complex ........................................................................................................................................................... 319.2.3 Re-packaging ................................................................................................................................................... 319.3 VIDEO QUALITY MEASUREMENT PROCESS AND TOOLS ...................................................................................... 319.3.1 Overview .......................................................................................................................................................... 319.3.2 Venera Technologies – Pulsar/Quasar/Nima .................................................................................................. 31


9.4 ADVERTISEMENT ................................................................................................................................................. 329.4.1 Trackable Media identification ....................................................................................................................... 329.4.2 Ad ID ............................................................................................................................................................... 329.4.3 Ads customized for IFE vs. other media .......................................................................................................... 329.4.4 An introduction to cross-platform marketing .................................................................................................. 329.4.5 Technology in transition .................................................................................................................................. 329.5 CMAF ................................................................................................................................................................. 339.6 IMF – APEX IMF OPL ....................................................................................................................................... 3310 INFORMATIVE ANNEX- ACRONYMS AND ABBREVIATIONS .......................................................... 3411 INFORMATIVE ANNEX- LIST OF PARTICIPANTS ................................................................................ 3512 INFORMATIVE ANNEX- WIDEVINE CROSS-REFERENCE ................................................................. 37

TABLE OF FIGURES

Figure 1: System Reference Model ................................................................................................................................ 8


1 ForewordThe Encoding and Encryption Technologies Working Group (EETWG) is a working group established by the Airline Passenger Experience Association (APEX) and its standing committee, the Digital Content Management Working Group (DCMWG), with the objective of integrating the inflight entertainment industry’s content delivery supply chain into the broader content delivery ecosystem(s) of the entertainment and media industries from which IFE deliverables are sourced.

The EETWG was launched on April 2015 and has conducted weekly web conference meetings during most weeks through May 2017. An in-person meeting was held on 24-25 May 2017 at Panasonic Hollywood Labs, Los Angeles, California. Membership was open to members of APEX as well as qualified subject matter experts (SMEs). This document is the result of consensus between participants.

This Specification and the EETWG build on previous standards produced by working groups and committees dating from the introduction of digital media to IFE uses in 1994. The preceding core standards are “APEX 0395: Content Delivery for Inflight Entertainment” and “APEX 0403: MPEG-4 Content Specification & Content Security Requirements for Airline Inflight Entertainment and Connectivity Systems”. These standards were based on codecs and/or file formats that have been broadly superseded by the formats incorporated here.

An important factor in the evolution and integration of these specifications has been APEX’s outreach to entities such as the Digital Entertainment Content Ecosystem (DECE), the Society of Motion Picture and Television Engineers (SMPTE), MovieLabs, and others, to establish relationships ranging from collaborative to formal liaisons.

The vision behind this effort is seen in the principles of digital asset management that maintain that deliverables for such content as theatrical motion pictures and television are created once, at the top of the supply chain, and are repurposed market-by-market from the original assets. The concept of an interoperable file format has been around for some time, but the concept of truly interoperable files gained the most traction when the Digital Entertainment Content Ecosystem (DECE) launched the Common File Format (CFF), now known as Common Format.

The cooperation, input, and collaboration of DECE in the activities of EETWG and development of this Specification have been invaluable.

MPEG-CMAF (ISO/IEC 23000-19) has further codified Common Format, and is now the single deliverable media format for all IFEC uses.

The related MPEG Common Encryption (ISO/IEC 23001-7 CENC) scheme established a DRM independent common set of encryptions. This APEX 0415 Security specification is built on top of APEX 0403 Security to support Enhanced content (UHD, HDR), PED content, and wireless upload of content to onboard IFEC systems.

Additionally, the work by the Society of Motion Picture and Television Engineers (SMPTE) on an international standard for the file-based interchange of multi-version finished audio-visual works, mezzanine files, known as the Interoperable Master Format (IMF) continues to gain adoption by studios. SMPTE’s IMF Working Group has worked collaboratively and supportively with APEX for several years.

MovieLabs, the research and development organization of the major studios, codified Media Manifest which has become an essential element of delivering files from studios to retailers in the home entertainment market.

For automation of digital workflows and supply chain efficiency, MovieLabs recommends adoption of a suite of compatible standards and specifications. They cover core aspects of online distribution, including identification, metadata, avails, asset delivery, and reporting. Developed and delivered through industry collaboration, these


standards and technologies enable automation, cost reduction, and improved consumer experiences across the industry. Collectively, these are called the MovieLabs Digital Distribution Framework.

Major airlines are looking ahead to greater utilization of passenger devices (PEDs) in IFE. An important enabler of streaming to PEDs will be the Web Application Video Ecosystem (WAVE). Various initiatives will be involved in WAVE implementation, including CTA’s Content Specification Task Force—that will identify requirements in content streams centered around the MPEG CMAF proposal—and the HTML5 API Task Force that will identify requirements for the HTML5 app environment on the device side.

This Specification includes an informative reference to trackable media identification and Ad-ID for the purpose of making advertising sales in IFE compatible with an emerging global initiative to enable cross-platform marketing of advertising.

The next steps beyond this Specification involve further outreach, including establishing IFE profiles in CMAF and IMF, and the establishment of cooperative workflows that support the utilization of interoperable assets and monetizable impressions throughout the supply chain.

Specific objectives include:

• Enabling content providers to deliver to IFE using established profiles, for example, in IMF and CMAF.

• Streamlining IFE workflows and reducing post-production activity by enabling the use of such tools as late-binding.

• Providing for the secure delivery of higher quality materials for use in IFE such as UHD and HDR. • Providing for potential increased use of PEDs in IFEC.

• Enabling IFE providers a wide range of compliant parameters while supporting the concept of content providers delivering a single set of deliverables into the IFE space.

• Harmonizing IFEC media delivery with the current and emerging standards used to serve consumers. This will enable broader media use and availability.

• The development and publication of an open, voluntary technical specification that highlights a common digital content delivery methodology for IFEC systems.

• The interoperability of content across multiple IFEC implementations.

• The utilization of efficient encoding methods for high quality image and sound, helping to ensure a quality airline passenger experience.

• Non-proprietary and interoperable system components.

• A secure IFEC system infrastructure with secure content preparation and delivery.

While this specification includes profiles of security and quality level requirements, the ultimate decision to approve a profile/level falls on the content owner.


2 ScopeThis specification describes an ecosystem for delivery and distribution of next generation IFEC content to passengers. As with the previous 0403 specification, 0415 describes minimum security requirements, format constraints, workflow recommendations and a single unifying file format. The specification utilizes the Common Media Application Format for Segmented Media (CMAF), as defined in ISO/IEC 23000 Part 19 (MPEG-A), as the single deliverable media format for all IFEC uses. CMAF utilizes standardized encoding and packaging of segmented media objects that is well documented and allows a wide range of delivery implementations without specifying any single one. This format supports IFEC embedded systems as well as airline-owned and passenger-owned (PAX) Portable Electronic Devices (PED) and is an appropriate foundation for new designs of dedicated IFE hardware.


3 ReferencemodelThis specification is primarily intended for future generations of cabin networks.

Figure 1: System Reference Model

The system reference model addressed by this specification is illustrated in Figure 1. In Figure 1, the following key components and workflow descriptions apply, with the letters/numbers in the figure corresponding to the lettered/numbered items below:

A. Airline or Airline’s Authorized Agent: Periodically, it selects appropriate content targeted to its passengers for each route.

B. Content Providers (CP): Movie, documentary, news, TV and radio programs, music, interviews, educational courses, games, map, etc. owners and licensors.

Disk

AirlineDataLoader

ContentServiceProvidersand/or

PostProductionLabs

Airlineor

Airline’sAuthorized

Agent

ContentProviders

ContentProviders

conten

torder

IFECIntegrationLabsecurecontent

inIMF(preferred)

metadata

securecontentdeliveryinCF

ContentProviders

securecontentdeliveryinCF

customizedmetadatainDCMETA

AircraftCabin

AircraftServers

In-SeatDisplays

AircraftCabin

AircraftServers

AircraftServers

In-SeatDisplays

In-SeatDisplays

1

2

3

4

5

AirportSecureFacility

AircraftCabin

IFECServers

IFECServers

customized

metad

atasecur

econtent

loaddeliv

ery


PostProductionLabs

securewiredorwirelesscabindelivery

contentdecryptionatplayback

6


PostProductionLabs

IFECServers

IFECd

ata

IFECdata AirlineDataLoader

content

conten

t

IFECdata

printedAirlineMagazine,ifany,

containingprogramguide

7

8 1013

wireddataloading/unloading

9

Disk contentIFECdata

AirlineDataLoader

Disk Wirelessdatato/from:-Airline-IFECManufacturer-Internet/LiveTV-Merchants/Banks

physicaldataloading/unloading

A

B CD

E

F

devicescont

ent

LoadingRackforAirlineOwnedPortableDevices

IFECdat

a In-SeatDisplaysIn-SeatDisplaysIn-SeatDisplays

14

AirlineownedPED

AirlineownedPED

AirlineOwnedPED

PAXownedPED

PAXownedPED

PAXOwnedPED

1112

Studioapprovedsecureoffaircraftcommunications:SatCom/WiMAX/Wi-Fi/Cellular

securedataOR

securecontentOR

securecontentsecuredata


C. Content Service Providers and/or Post Production Labs (CSP/PPL): Encoding and transcoding houses, close captions and subtitles productions, metadata providers, encryption and multiplexing facilities.

D. IFEC Integration Lab: Storage management of IFEC servers, seats or airline-owned PEDs, passenger experience integration with available content.

E. Airport Secure Facility: Airline / service facility situated inside airport, as needed.

F. Aircraft Cabin: Equipped with IFE seat displays, passenger control units and IFE networks (wired or wireless) to consume available content. Airlines may instead provide airline-owned PEDs that may or may not require a Wi-Fi connection. Passenger may bring on board their own devices such as smartphones, tablets and notebooks and may expect similar services as available on the ground. Aircraft may use air to ground communication for data loading/unloading.

1. A Content Provider accepts an order from an Airline or from an Airline’s authorized agent. The Content Provider elects content to be categorized as enhanced, premium or non-premium.

2. Content may be delivered directly to the IFEC Integration Lab in APEX 0415 Compliant CMAF from a Content Provider.

3. Or content and metadata may be delivered to a Content Service Provider (CSP) and/or Post Production Laboratory (PPL) with content preferably in an IMF format.

4. All content customized metadata required by the Airline’s applications including the monthly magazine (containing the program guide) are delivered by the CP or by the CSP/PPL.

5. The CSP/PPL securely delivers to the Airline’s IFEC Integration Lab all content (in APEX 0415 Compliant CMAF) and metadata (in DCMETA format), customized to airline requirements.

6. After any required content encryption and integration, the IFEC Integration Lab securely delivers content to an airline/airport secure facility.

7. Airline’s maintenance personnel or authorized agents transfer content to airline-owned PEDs through loading racks. The airline-owned PEDs are then carried to the aircraft. Airline-owned PEDs play out the content for use by passengers with or without the use of secure wireless connections.

8. Other types of aircraft content loading exist such as duplicating an encrypted content disk for each aircraft embedded content loader or loading multiple servers on a bench loader and delivering them to the cabin.

9. Alternatively, airline’s maintenance personnel or authorized agents transfer content updates to portable data loaders (PDL) that are carried to each aircraft for loading content to onboard IFEC servers.

10. If equipped, using studio approved secure wireless communications such as SATCOM, WiMAX, Wi-Fi or cellular standards. Other types of content and transactions are then facilitated such as bi-directional data exchange with Airline or IFEC Manufacturer, internet/live TV and Merchants/Banks.

12. The onboard IFEC servers deliver the content in APEX 0415 Compliant CMAF either over secure wired or secure wireless connections to in-seat displays for use by passengers.

13. PAX-owned PEDs may play out content if equipped with an airline approved application or player on their personal devices.


14. IFEC data, such as Built-In Test Equipment data (BITE), passenger usage information, passenger purchase orders, etc. may be uploaded to the airline facility for further processing. As agreed between the necessary parties, passenger content usage data may be shared to enable better content customization.

15. Printed airline’s magazines, if any, containing the periodic program guide are sent to the Airline’s airport maintenance facility to be carried into the aircraft.


4 References&Definitions

4.1 Normativereferences• ISO/IEC 23000-19 Information technology - Coding of audio-visual objects - Part 19: Common Media

Application Format for Segmented Media o http://www.iso.org

• TR-META-MPD Media Manifest Product Definition, v1.0 o http://www.movielabs.com/md/manifest/product/ o BP-META-MMMD Using Media Manifest, File Manifest and Avails for File Delivery (Best

Practices), v1.2 • TR-META-MMIMF Using Common Media Manifest with Interoperable Media Format (IMF), v0.5a • TR-META-CM

o www.movielabs.com/md/md/v2.3/Common_Metadata_v2.3c.pdf • ITU-R BS.1770-4 Algorithms to Measure Audio Programme loudness and true-peak audio level • EBU R 128 Loudness Normalisation And Permitted Maximum Level Of Audio Signals • EBU TECH 3342 Loudness Range: A Measure To Supplement EBU R 128 Loudness Normalization • APEX Specification 0403 v3.0 “MPEG Content Specification & Content Security Requirements for Airline

In-Flight Entertainment and Connectivity Systems” o http://apex.aero

• APEX Specification 0814 v1.0 Captions and Subtitles for Inflight Entertainment Systems o http://apex.aero

• EIDR- Entertainment Identifier Registry Association o http://eidr.org/technology/

• Ad-ID, LLC o www.ad-id.org o http://www.ad-id.org/how-it-works/ad-id-structure

• ECP1.2 Specification for Enhanced Content Protection – Version 1.2 o https://movielabs.com/ngvideo/MovieLabs_ECP_Spec_v1.2.pdf

• SMPTE, ST 2084:2014, High Dynamic Range Electro-Optical Transfer Function of Mastering Reference Displays

o https://doi.org/10.5594/SMPTE.ST2084.2014

4.2 Informativereferences• ATSC A/85:2013 Establishing and Maintaining Audio Loudness • UltraViolet Specifications and Schemas, System Release 2.4

o http://www.uvcentral.com/specs\ o http://uvcentral.com/page/ultraviolet-online-guide-homepage o DSYTEM: System Specification version 2.4

• Technical Note on EIDR and UltraViolet o http://eidr.org/documents/Technical_Note_on_EIDR_and_UV.pdf

• How to use EIDR in UltraViolet o http://eidr.org/documents/FAQ_How_to_Use_EIDR_in_UltraViolet_2013-11-07.pdf

• EIDR Documentation Guide o http://eidr.org/documents/EIDR_Documentation_Guide.pdf

• EIDR Data Fields Reference Guide o http://eidr.org/documents


• NIST SP 800-164, Guidelines on Hardware-Rooted Security in Mobile Devices (Draft) o https://csrc.nist.gov/csrc/media/publications/sp/800-164/draft/documents/sp800_164_draft.pdf

4.3 DefinitionsofTermsThis document follows the requirements terminology of RFC 2119, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Terms used in §8.1:

4K : 4096 x 2160

UHD: 3840 x 2160

SD: up to 576p

Wide-color gamut (WCG): DCI-P3 D65 or BT2020 or wider

Enhanced format: content with one or more of these characteristics: • Greater than 1080p resolution, typically 4K or UHD • Wide-color gamut • frame rate: greater than 60 fps • Intended for presentation on HDR EOTF (Electro-Optical Transfer Function) displays as

standardized in SMPTE ST 2084

Non-enhanced: content without any of the above parameters. Such can be at most 1080p resolution.

Premium or non-premium content valuation is defined by each content provider and is typically aligned with its Early Window or Late Window designation

SEE - Secure Execution Environment, also called a Trusted Execution Environment or Secure Computation Environment (ECP1.2), is an isolated environment that runs in parallel with the operating system, providing confidentiality and integrity to application execution and data inside the SEE.

Closed network: not accessible to passenger devices (have no access to or are securely partitioned from the closed network) or eavesdropping (if wireless, the network transport is encrypted)

Secure video path: the secure media pipeline from ECP1.2, such that decrypted video is protected from unauthorized access.

COTS DRM: a commercially off-the-shelf (COTS) offered digital rights management (DRM) system; alternatively a professional grade (see below) DRM may be acceptable. See also §8.3.

Terms used in §8.2:

white box cryptography - cryptographical techniques designed to be resistant to white box attacks, in which the attacker has complete control over the execution platform and access to the software binaries.

Professional grade – known and proven across multiple industries and clients; audits by third parties can be considered as alternatives. Does not imply any cost level nor open source.


tamper resistance- a methodology used to hinder, deter or detect unauthorized access to a device, software or circumvention of a security system.

Content decryption keys- keys used to decrypt content. Per CENC will be a symmetric key, so the same key is used to encrypt and decrypt content.

License Server- a server that authenticates and authorizes client requests and distributes licenses. In this document, it always refers to a DRM license server that issues licenses with a DRM decryption key and may include DRM policy attributes such as a time-based validity period, output protection, etc.

Root of trust – the hardware/software/firmware component that is inherently trusted and provides a set of security primitives; other aspects of trust in the system (of further hardware/software components) are built upon this basis. [Ref NIST SP 800-164]

Strong authentication – authentication credentials are not transmitted in the clear, and two independent credentials are required (i.e. two-factor authentication).

Attributes of license servers:

Remote – License server is in a trusted environment (a secure managed data center) on the ground. System does not operate if the connection is down.

Installed – License server hardware is installed and secured into the aircraft, typically in an electronics bay.

Portable – License server hardware is incorporated in a portable, typically battery-powered, unit. Often it is located in the passenger cabin, in a dedicated bag bin location.


5 MediaObjectsThe format and specification of Common Media Application Format (CMAF) as described in ISO/IEC 23000-19 is hereby referenced and incorporated into this document. Media objects shall comply with the specification, and the further constraints defined by the IFE specific media profiles defined in Section 5.2.

CMAF defines the encoding and packaging of segmented media objects for delivery and decoding on end user devices in adaptive multimedia presentations. Delivery and presentation are abstracted by a hypothetical application model for segmented Media Objects described by a manifest that allows a wide range of implementations without specifying any. CMAF constrains media encoding and packaging to allow interoperable adaptive delivery to different devices, over different networks. CMAF does not specify a manifest, player, or delivery protocol, with the intent that any that meet the functional requirements can be used.

5.1 MediaPackagingCMAF Presentations contain sets of tracks comprising addressable video, audio, and subtitle objects.

5.2 MediaProfilesThis section contains specific media profiles based on the requirements of IFE hardware.

5.2.1 IFE-SDVideoProfileThe IFE-SD Media Profile defines a visual content profile for devices supporting standard definition (up to 576P) video encoded as AVC. This profile is based on the CMAF SD media profile as specified in ISO/IEC 23000-19 Annex A, and all requirements apply except as modified here.

5.2.1.1 OverviewThe IFE-SD Media Profile is identified by the ‘ifsd’ four character code registered with [MP4RA]. The profile includes and is based on the constraints of Annex A, SD Media profile as detailed in CMAF.

5.2.1.2 ConstraintsonIFE-SD[AVC]ElementaryStreams

5.2.1.2.1 ProfileandLevelNo additional constraints.

5.2.1.2.2 Bitrate[AVC] elementary streams conforming to the IFE-SD Media Profile SHALL comply with APEX0403 video bit rate guidance.

5.2.1.2.3 EncodingParameters[AVC] elementary streams conforming to the IFE-SD Media Profile

SHALL be encoded as Constrained VBR. This is meant to effectively be a constant bit rate.

SHALL have an IDR frequency set to one on every key frame.


5.2.2 IFE-HSDVideoProfileThe IFE-HSD Media Profile defines a visual content profile for devices supporting standard definition (up to 576P) video encoded as HEVC. This profile is based on the CMAF SD media profile as specified in ISO/IEC 23000-19 Annex A, with a change of codec to HEVC

5.2.2.1 OverviewThe IFE-HSD Media Profile is identified by the ‘ifhs” four character code registered with [MP4RA].

5.2.2.2 ConstraintsonIFE-HSD[HEVC]ElementaryStreams

5.2.2.2.1 TierandLevel[HEVC] elementary streams conforming to the IFE-HHD10 Media Profile SHALL comply with the following [HEVC] Profile and Level constraints:

• Main Profile, Main Tier as defined in [HEVC] • Up to Level 3 as defined in [HEVC].

5.2.2.2.2 Bitrate[HEVC] elementary streams conforming to the IFE-HSD Media Profile SHALL be compatible to APEX0403 video bit rate guidance.

5.2.2.2.3 EncodingParameters[HEVC] elementary streams conforming to the IFE-HSD Media Profile

SHALL be encoded as Constrained VBR


5.2.3 IFE-HDVideoProfileThe IFE-HD Media Profile defines an audio-visual content profile for devices supporting high definition (up to 1080p) video encoded as AVC. This profile is based on the CMAF HD media profile as specified in ISO/IEC 23000-19 Annex A, and all requirements apply except as modified here.

5.2.3.1 OverviewThe IFE-HD Media Profile is identified by the ‘ifhd’ four character code registered with [MP4RA].

5.2.3.2 ConstraintsonIFE-HD[AVC]ElementaryStreams

5.2.3.2.1 ProfileandLevelNo additional constraints.

5.2.3.2.2 Bitrate[AVC] elementary streams conforming to the IFE-HD Media Profile SHALL comply with APEX0403 video bit rate guidance.


5.2.3.2.3 EncodingParameters[AVC] elementary streams conforming to the IFE-HD Media Profile



5.2.4 IFE-HHD10VideoProfileThe IFE-HHD10 Media Profile defines an audio-visual content profile for devices supporting high definition (up to 1080) video encoded at 8 to 10 bits. This profile is based on the CMAF HHD10 media profile as specified in ISO/IEC 23000-19 Annex B, and all requirements apply except as modified here.

5.2.4.1 OverviewThe IFE-HHD10 Media Profile is identified by the “ifhx” four character code registered with [MP4RA].

5.2.4.2 ConstraintsonIFE-HHD10[HEVC]ElementaryStreams

5.2.4.2.1 ProfileandLevel[HEVC] elementary streams conforming to the IFE-HHD10 Media Profile SHALL comply with the following [HEVC] Profile and Level constraints:

• Main10 Profile, Main Tier as defined in [HEVC] • Up to Level 4 as defined in [HEVC].

5.2.4.2.2 Bitrate[HEVC] elementary streams conforming to the IFE-HHD10 Media Profile SHOULD comply with APEX0403 video bit rate guidance.

5.2.4.2.3 EncodingParameters[HEVC] elementary streams conforming to the IFE-HHD10 Media Profile:


SHALL have an IDR frequency set to one on every key frame

5.2.5 IFE-UHD10VideoProfileThe IFE-UHD10 Media Profile defines an audio-visual content profile for devices supporting high definition (up to 4096 x 2160) video encoded at 8 or10 bits. This profile is based on the CMAF UHD10 media profile as specified in ISO/IEC 23000-19 Annex B, and all requirements apply except as modified here.

5.2.5.1 OverviewThe IFE-UHD10 Media Profile is identified by the “ifhu” four character code registered with [MP4RA].


5.2.5.2 ConstraintsonIFE-UHD10[HEVC]ElementaryStreams

5.2.5.2.1 ProfileandLevel[HEVC] elementary streams conforming to the IFE-UHD10 Media Profile SHALL comply with the following [HEVC] Profile and Level constraints:

• Main 10 Profile, Main Tier as defined in [HEVC]

• Up to Level 5 as defined in [HEVC].

5.2.5.2.2 Bitrate[HEVC] elementary streams conforming to the IFE-UHD10 Media Profile SHALL NOT exceed 20 Mb/s, with a default of 15 Mb/s.

5.2.5.2.3 EncodingParameters[HEVC] elementary streams conforming to the IFE-UHD10 Media Profile



5.2.6 IFE-HDR10VideoProfileThis IFE-HDR10 is based on SMPTE 2084.

The IFE-HDR10 Media Profile defines an audio-visual content profile for devices supporting high definition (up to 4096 x 2160) 10 bit video with high dynamic range (HDR), which includes wide-color gamut (WCG). This profile is based on the CMAF HDR10 media profile as specified in ISO/IEC 23000-19 Annex B, and all requirements apply except as modified here.

Note: UHD HDR content to be defined in a subsequent revision of this specification.

5.2.6.1 OverviewThe IFE-HDR10 Media Profile is identified by the “ifhr” four character code registered with [MP4RA.

5.2.6.2 ConstraintsonIFE-HDR10[HEVC]ElementaryStreams

5.2.6.2.1 ProfileandLevel[HEVC] elementary streams conforming to the IFE-HDR10 Media Profile SHALL comply with the following [HEVC] Profile and Level constraints:

• Main 10 Profile, Main Tier as defined in [HEVC] • Up to Level 5.0 as defined in [HEVC].


5.2.6.2.2 Bitrate[HEVC] elementary streams conforming to the IFE-HDR10 Media Profile SHALL NOT exceed 25.0 Mb/s, with a default of 20.0 Mb/s.

5.2.6.2.3 EncodingParameters[HEVC] elementary streams conforming to the IFE-HDR10 Media Profile



5.2.7 IFE-AACCoreMediaProfileThe IFE-AAC Core Media Profile defines an audio content profile. The profile includes and is based on the constraints of Annex A, AAC Core Media profile as detailed in CMAF

5.2.7.1 OverviewThe IFE-AAC Core Media Profile is identified by the “ifaa” four character code registered with [MP4RA].

5.2.7.2 Constraintson[AAC]ElementaryStreams

5.2.7.2.1 CodecandProfile[AAC] elementary streams conforming to the IFE-AAC Core Media Profile SHALL comply with the following [AAC] Codec and Profile constraints:

• AAC-LC or HE-AAC as specified in APEX0403, for mono or stereo programs.

5.2.8 IFE-IMSC1TextSubtitleMediaProfileThe IFE-IMSC1 Text Media Profile includes and is based on the constraints of Annex A, IMSC1 Text Subtitle Media profile as detailed in CMAF. Subtitles and captions shall otherwise be compatible with specification APEX 0814 “Captions and Subtitles for Inflight Entertainment Systems”. Media files should minimally include closed caption files matching language tracks as required by law or regulation.


6 AudioProgramLoudnessandTrue-Peak

6.1 OverviewThe audio parameters of IFE programs require constraint from a typical theatrical or quiet room listening mix. This may be achieved either in the mix room equipped to emulate the aircraft listening environment, or in source files provided for encoding or by audio processing during encoding.

The technical requirements indicated in this section are meant to allow the most engaging and pleasant listening experience to passengers, provided that full range, full dynamic, noise cancelling headphones are used. This is achieved by controlling several loudness parameters such as “Maximum Dialog/Program Difference” and “Maximum Loudness Range” as specified in the paragraphs below. In case frequency/dynamic range limited, non-noise cancelling earphones or in-earbuds are used, it is advised to apply further loudness adaptation to conform with the narrower comfort zone allowed by the lower quality electroacoustic transducer. This additional adaptation process can be performed either offline on a duplicated copy of the audio asset, thus appearing as an additional audio option in the device, or online, as a real-time audio process occurring in the seatback device or in the PED.

Dialog Level, as described in ATSC A/85, shall be used as the Anchor Element to measure and normalize overall audio average levels to Target Level, and to produce consistent average loudness across all content. When dialog is not present, Program Loudness should be used instead.

Furthermore, in order to supply the airline with quality audio content, the source program should be produced in accordance with the following requirements:

• Sampling rate 44.1kHz or 48kHz (or higher) • Bit depth 16bit or 24bit (or higher)

• Frequency range 20Hz to 20kHz When producing audio content, all requirements indicated in the parameters below should be entirely fulfilled. However, some tolerances are anticipated and accepted in order to allow minor measurement inconsistencies due to differences in dialog meters’ detection and audio meters’ resolution, and to facilitate QC operations.

6.2 DialogLevelDialog Level shall be normalized to a Target Level of -18 LUFS with a tolerance of ±1 LU, as measured per recommendation ATSC A/85. When dialog is not present, Program Loudness should be used instead to normalize the content to the Target Level of -18LUFS.

6.3 MaximumProgramLoudnessAll content shall have a Program Loudness level not greater than -15 LUFS as measured per recommendation ITU-R BS.1770-4. Note that this is a maximum allowed integrated Program Loudness level, not a target level, for content that is being normalized as per 6.2 using a Target Level at -18LUFS.

6.4 MaximumDialog/ProgramdifferenceAs a result of applying the requirements specified in 6.2 and 6.3, the allowed Maximum Dialog to Program difference is 3 LU, as measured per recommendations ATSC A/85 and ITU-R BS.1770-4, and with a tolerance of +1 LU.


6.5 MaximumLoudnessRangeThe allowed Maximum Loudness Range is 15 LU as measured per EBU TECH 3342-2016, and with a tolerance of +1 LU.

6.6 MaximumTrue-PeakThe Maximum True-Peak shall be constrained to -1 dBTP as measured per Recommendation ITU-R BS.1770-4

Note: “Program Loudness” is labeled “Programme Loudness” in ITU-R.BS1770-4 and in EBU R128.


7 Contentidentification

7.1 ContentContent Identifiers (CIDs) and Asset Logical IDs (ALIDs) SHALL be structured according to [DSYSTEM] v2.4, Section 5.

Content conforming to APEX 0415 SHALL NOT use the concept of "DECE Bundles" to identify composite groupings of content.

Asset Physical IDs (APIDs) defined in [DSYSTEM] are not applicable to content conforming to APEX 0415.

Please see the informative section of this specification for more details on the use of EIDR IDs with content conforming to APEX 0415. http://eidr.org/documents/Technical_Note_on_EIDR_and_UV.pdf

7.2 AdvertisementAs opportunities for non-broadcast video advertising expand, the pace of efforts to standardize content identification systems accelerates.

The structure of the Ad-ID (and shortly the utilization within MPEG-CMAF) can be found at www.ad-id.org/how-it-works/ad-id-structure

For an overview of the latest trends and unifications currently underway, please see the informative section on advertising.


8 SecurityAPEX 0403 security still governs Content Transfer between Secure Facilities (Section 7.2).

The guidelines and requirements outlined below are created in conjunction with APEX0403 security standards to support Enhanced Content, content to PEDs, and wireless upload of content to on-board IFEC Systems. .

The guidelines and requirements outlined herein are intended to be applicable only to IFE systems submitted for approval after publication of this document and do not apply to any existing and/or approved systems.

For the purposes of this section, the definitions in §4.3 are used. There are significant differences in requirements for enhanced and non-enhanced content. To assist in understanding the following cross-reference of media profiles from §5.2 is given below:

Profile name Enhanced? Comments

IFE-SD Non-enhanced

IFE-HSD Non-enhanced

IFE-HD Non-enhanced …unless > 60 fps

IFE-HHD10 If encoded with WCG 10 bit color does not mean WCG

IFE-UHD10 Enhanced, if >1080p If <1080p, recommend using IFE-HHD10

IFE-HDR10 Enhanced

IFE-AAC N/A Audio only

For readability, requirements terms (SHALL/MAY) are not capitalized within the tables.


8.1 SecurityRequirements:Contentvs.PlaybackDevicesThe following table summarizes the minimum requirements for content of different values when played on different playback devices.

In general, requirements for each row may increase as you read down, and requirements for content may decrease as you read left to right. These requirements are intended to comply with ECP1.2, but some requirements are reduced for lower value content. For details on Watermarking: see §8.4. For details on DRM, see §8.3.

Playback Device

Enhanced Premium

Enhanced Non-Premium

Non-Enhanced Premium

Non-Enhanced Non-Premium

Non-Enhanced SD Non-premium

Wired or Wireless

Seat Devices (closed

network)

All requirements to the right plus:

• Aircraft-information Forensic Watermarking

• Secure video Path


• Forensic Watermarking- minimum of Airline information


• COTS DRM • If content or

content keys are delivered wirelessly to a device, such transmissions shall encrypted and over a closed network

• The network shall have measures to detect attempts at unauthorized access. In such event, the system shall have means to respond to active threats.


• MPEG-CENC (see §8.1.1) replaces AES128

• Each playback

device shall be authenticated by the server before authorizing delivery of content or content keys

• AES128 minimum encryption

• Content shall be encrypted while at rest and in transit to end user device, until processing within the display

• Watermarking

Airline-owned

Portable Electronic

Devices

All requirements to the right plus: • Airline &

Device-information Forensic Watermarking


• COTS DRM

All requirements to the right plus: • Device-

information Forensic Watermarking


• COTS DRM

All requirements to the right plus: • MPEG-CENC

(see §8.1.1) • COTS DRM • Any data output

on the device shall not be active at any time while premium content is locally accessible to passengers or playing

• Any content keys shall be stored physically separate from the encrypted content

• Streaming of content to a

All requirements to the right plus: • Each playback

device shall be authenticated to the server before authorizing delivery of content or content keys

• Content shall be maintained encrypted while on board except during rendering in the display

• Forensic Watermarking

• No device video outputs

• only airline authorized applications shall be accessible on the device,

• Tamper resistant case


device over Wi-Fi shall only occur on a closed airline-controlled network.

• The network shall be monitored to detect any network attack and take appropriate action to protect premium content

PAX-owned PEDs


• SEE • Secure video path


• Session-based Forensic Watermarking

• MPEG-CENC (see §8.1.1) • COTS DRM • Watermarking

Notes

• Secure delivery required for off aircraft connectivity

8.1.1 CommonEncryption(MPEG-CENC)MPEG-CENC as used above implies with the following requirements:

MPEG-CENC (CMAF Requirement): AES-CBC encryption recommended with AES-CTR encryption optional

[CMAF] specification, Section 8, Common Encryption of Tracks.

CENC-MPEG systems technologies -- Part 7: Common encryption in ISO base media file format files (ISO/IEC 23001-7:2016)


8.2 SecurityRequirements:ContentTypesvs.LicenseServers

Definitions of terms used below can be found in §4.3:

Requirements Enhanced Premium

Enhanced Non-

Premium

Non-Enhanced Premium

Non-Enhanced

Non-Premium

Non-Enhanced SD Non-premium

1. All databases storing content decryption keys must be encrypted. Their access must be authenticated. No single encrypting key protecting content decryption keys shall be shared between or among airlines (the entity licensing the content)

√ √ √ √ √

2. The transfer of the content decryption keys to the local license server must enforce mutual authentication and secure transfer. If IFE connectivity is provided, mutual authentication shall be immediate. Authentication acknowledgement of sneakernet solutions may be delayed.

√ √ √

√

√

3.All credentials and private keys related to protection and authentication of content decryption keys and private keys must be protected by a root of trust of storage.

a. If the root of trust is not hardware-based, its protection shall be based on professional-grade whitebox cryptography.

√ √

b. For increased security, the root of trust shall be hardware-based

√Portable

√Installed √Portable


√Installed

c. For seed-based solution (where a secret is used to derive decryption keys), the seed should be protected by a hardware root of

√ √

√ √

√


trust.

4. The elements of the license server handling cryptographic material and credentials must be protected from reverse engineering by one of the methods (a) or (b) described herein. Note: Server libraries of industry standard studio approved DRMs, when provided only in binary form by the DRM vendor, may impose limitations to the level of protection possible for cryptographic material when passed to those 3rd party components. It is understood that the license server manufacturer has limited influence on the capabilities of 3rd party DRM components of studio approved DRMs.

a. If a Secure Execution Environment (SEE) is not used, elements handling cryptographic material and credentials shall be protected with professional grade obfuscation and tamper resistance techniques

√

√ √

b. For increased security, these elements should execute in a hardware-based SEE

√Portable


√Installed √Portable √Portable

5. Firmware and patches which affect content protection and operating system patches must be encrypted during transfer. √

√

√

√

√

a. For additional security, OS and content protection binaries shall have their integrity checked at run-time √

√

√

6. Root access to the license server must be authenticated. √

√ √

√ √

a. For increased security, the credentials should not be common to all

√ √ √ -

-


license servers.

7.The installed license server must be uniquely individualized, i.e., a pristine dump of a license server shall not be able to grant content licenses on a computer other than its initial one.

a. This individualization should be based on a root of trust

√

√

√

√

√

b. For increased security, the root of trust shall be hardware-based

√Portable


√Installed

8. The Operating System must be up to date with all applicable security patches based on a documented update process

√

√

√

√

√

a. A secure boot feature shall be provided that protects the boot sequence all the way to kernel loading, creating a chain of trust that is rooted in a hardware root of trust that shall be immutable, guaranteeing integrity and authenticity of the SW

√

√ √

9.The update process must enforce the use of the minimal version of the license server software. Studios have the right to define the minimal version of the license server to be used. Documented process must be in place for license server updates.

√ √ √ √ √

10.An instance of a license server must be revocable. The revocation interval must not exceed the content update interval.

√ √ √

11. Access to the license server administration account(s) must use strong authentication (SSH for remote access, two-factor authentication)

√ √ √ √ √

12. A license server shall perform runtime √ √ √


Legend:

√ - applies to all license server deployments: portable, installed, or remote

√Portable – applies to Portable servers

√Installed – applies to installed servers

8.3 DRMUse of commercial (COTS) Digital Right Management systems, if any, SHALL be required and approved by each content owner through bilateral agreements with airlines, IFE suppliers and content aggregators. Custom DRM systems MAY also be possible, though will require more detailed scrutiny before approval.

8.4 Watermarking

8.4.1 ForensicWatermarkingWhen required, forensic watermarking technology should minimally meet the following requirements:

1. Forensic watermarking SHALL be imperceptible to the passenger.

2. No audio, closed caption, or subtitle watermarks are required for airline licensed content.

3. The level of traceability provided by watermarking MAY vary from identifying, in increasing complexity: • Airline-information: particular airline(s) or licensing entity licensing the content, • Aircraft-information: information about the vendor system (vendor, system name), and if available, the

system version, flight number, date, and aircraft identifier.

• Client-information: Make and model of the rendering device (a seat and/or device that the content was played on) with OS version if available; also called session-based. If inserted on the on the server, this information should be retrieved and authenticated by DRM exchange.

• NOTE: The variable reliability and accuracy of the optional information above is acknowledged; it nevertheless can be useful in an investigation

4. The above level of watermarking required is in table §8.1 and may vary based on the premium/non-premium determination by each content owner.

5. Session based watermark processing if done on the client side and if an SEE is otherwise required SHALL be done within the Secure Execution Environment (SEE).

6. The robustness of the watermark SHALL resist to the following attacks: • Camcorder capturing (straight or with offset angle), • Image rotation, cropping, blurring and stretching,

• Adding noise, quantization, temporal modifications and MPEG compression.

8.4.2 VisibleWatermarkingVisible watermarking as defined in APEX Recommended Practice 0210, “Visible Watermarking Best Practices”, Version 9, July 26, 2010 is no longer required if forensic watermarking is in use.

security intrusion prevention.


Visible watermarking involves “burnt-in” insertion of a logo/name of the airline or operator at random times within the video. Besides from detracting from the user experience, they can sometimes obscure captions; furthermore, technology now exists to easily detect and remove such insertions in post-processing, so they provide little security added value.

8.5 WirelessContentLoadingWireless loading of content to on-board IFEC systems could be performed through SATCOM, WiMAX, Wi-Fi and cellular at the gate or in the air. Wireless transfer of content and security keys between airlines and aircraft cabins SHALL comply with the following security requirements:

• Enhanced and premium, content SHALL at all times remain encrypted in AES-128, • Each unique content key SHALL at all times remain encrypted in RSA-2048,

• A ground wireless transport shall be authenticated and encrypted by an industry standard method, such as ARINC 822A

• All the keys needed to decrypt the content keys shall not be transmitted wirelessly.

• Each secure client on the airlines’ side SHALL use a different client computer with a different certificate.


9 InformativeAnnex-TechnicalThe information included in this annex is meant to help in understanding the relationship to industry standards and guide implementations.

9.1 AudioBitrateRecommendationsIn the past years, several independent subjective listening assessment tests have been performed by various international organizations including EBU, ITU, AES and ISO/IEC, and with the goal to determine what is the minimum bitrate required for providing transparent audio quality resulting after a lossy encoding/decoding pass (MUSHRA rating). Amongst others, AAC, HE-AAC and HE-AAC v2 codecs were tested. The table below is the result of averaging the indicated recommended minimum bitrate officially published by those organizations. Mono, Stereo and Multichannel 5.1 formats, with sampling rate at either 44.1kHz or 48kHz, are specified and for each of the supported APEX audio codec*.

CODEC AUDIO FORMAT SAMPLING RATE MINIMUM BITRATE

AAC-LC MONO 44.1 kHz 64 kb/s AAC-LC MONO 48 kHz 72 kb/s AAC-LC STEREO 44.1 kHz 128 kb/s AAC-LC STEREO 48 kHz 144 kb/s AAC-LC MULTICHANNEL 5.1 44.1 kHz 284 (426**) kb/s AAC-LC MULTICHANNEL 5.1 48 kHz 320 (480**) kb/s

HE-AAC V 1/2 * MONO 44.1 kHz 58 kb/s HE-AAC V 1/2 * MONO 48 kHz 64 kb/s HE-AAC V 1/2 * STEREO 44.1 kHz 96 kb/s HE-AAC V 1/2 * STEREO 48 kHz 110 kb/s HE-AAC V 1/2 * MULTICHANNEL 5.1 44.1 kHz 148 (220**) kb/s HE-AAC V 1/2 * MULTICHANNEL 5.1 48 kHz 160 (240**) kb/s

* Please notice that in “ISO/IEC JTC 1/SC 29/WG 11N7137”, published by ISO/IEC in 2005, as well as in “EBU Technical Review: MPEG HE-AAC v2 – audio coding for today’s digital media world”, published by EBU in 2006, it is reported that HE-AACv2 produces benefits only at very low bitrate, while for bitrate higher than 48 kbps it performs as good as HE-AACv1. This evidence seems to suggest applying the same minimum bitrate recommendation to both HE-AACv1 and HE-AACv2.

** For multichannel 5.1 encoding, some critical audio samples would require higher bitrate in order to be encoded/decoded transparently. Values indicated in parenthesis are recommended for guaranteeing transparent audio quality for all content.

Official reference documents include:

• AES CP4740 Subjective Evaluation of State-of-the-art 2-channel Audio Codecs • ITU-R.BS.1196-5: Audio coding for digital broadcasting

• ITU-R.BS.1548-4: User requirements for audio coding systems for digital broadcasting

• EBU tech3324: Evaluation of Multichannel Audio Codecs • EBU Tech Review: MPEG-4 HE-AAC v2 – audio coding for today’s digital media world

• ISO/IEC JTC 1/SC 29/WG 11N7137: coding of moving pictures and audio • AES 17 Conference: mp3 and AAC explained


9.2 DeliveryTargetsforSpecificOperationsThis section lists two delivery target types for IFE use in specific operation workflows.

9.2.1 SimpleThis is a package containing a single profile. Suitable for delivery to end users.

9.2.2 ComplexA collection of profiles that enable multiple device types. Ideal for re-packaging operations.

9.2.3 Re-packagingThe process of extracting a specific profile from a complex set, and creating a simple package. The new package has a manifest listing only the elements included.

9.3 VideoQualityMeasurementProcessandTools

9.3.1 OverviewThe Quality methodology and guidelines in APEX 0403 apply here. Info on one QC tool suite is updated below.

9.3.2 VeneraTechnologies–Pulsar/Quasar/Nimahttp://www.veneratech.com

Venera Technologies provides three different QC systems, depending on user’s platforms and needs, to satisfy the QC requirements defined by APEX. These systems enhance and augment the Venera Technologies functionality stated in APEX 0403 specifications document. Please refer to the APEX 0403 – section 10.4 for details of Venera support for APEX defined specifications.

Pulsar is the ‘on-premise’ file-based QC system that supports the APEX specifications. It provides a series of pre-canned APEX “templates” (profiles) to QC media content and to verify compliance with APEX 0403 and 0415 specifications. With these templates, the QC process is simplified dramatically as little time is needed to define what needs to be checked and more on the results of the QC.

Quasar is the first ‘native’ cloud based file-based QC system, with similar QC functionality as Pulsar. And similar to Pulsar, Quasar provides support for APEX 0403 and 0415 specifications. The same pre-canned templates have been ported to Quasar. For the users who have moved their file-based workflow to the cloud, using Quasar to QC their content would allow them to continue working in the cloud and avoid dealing with on-premise tools.

Nima is a reference-based quality of experience scoring system, offering the advanced capabilities to score a media content in comparison to a source media file. It provides the user with the advantage of quickly and easily verifying that many variations of a media file (e.g. different bit rates, different resolutions), provide user experience similar to the original/reference file. The many variations may be due to creation of multiple Adaptive Bit Rate (ABR) variants, or needing other derivatives of the main source media file. Nima supports and incorporates various industry standard quality scoring technologies to provide the user with the ability and flexibility to choose the technology of their liking. Nima has the flexibility to include additional scoring technologies as they become available.


9.4 Advertisement

9.4.1 TrackableMediaidentificationMainstream advertisers around the world adhere to the principles of good conduct expressed in the Minimum Standards for Media Rating Research as set forth by the Media Rating Council (MRC). The commonly accepted mechanisms that protect against measurement bias impose specific content identification delivery and tracking system requirements. The current ATSC candidate standard for content metadata recovery employs an audio watermark called VP1. This system, also known as ‘Aspect’, is optimized for live TV and is not designed to convey MRC compliance accreditation on its own. Forthcoming standards from SMPTE support both live and on-demand workflows and will help close that accreditation gap. Without that helpful unification, on-demand system implementers and service providers are typically obliged to build proprietary systems for measuring audience impressions. These systems are regularly submitted to the MRC for review and accreditation on a case-by-case basis.

9.4.2 AdIDSome well-known agreements require that professionally produced commercial messages be registered with Ad-ID, LLC. This mirrors the existing global adoption of EIDR and ISAN for identification of long-form content. Expansion of the infrastructures that support these systems is underway. In the future, all mainstream advertisements will automatically be delivered with an Ad-ID identifier in the form of a SMPTE OBID audio watermark. Until that time, a prudent content delivery automation alternative is to employ SMPTE RP-2092 to extract the Ad-ID value from the MXF Ad-ID Digital Ad Slate.

9.4.3 AdscustomizedforIFEvs.othermediaCustomized infomercials, mid-program promotional consideration announcements, billboards and product placements are typically tracked by EIDR Manifestation IDs rather than by issuing multiple Ad-ID values. In a parallel manner, short-form commercial spots are commonly exchanged using MXF and DPP packages rather than IMF packages.

9.4.4 Anintroductiontocross-platformmarketingIn response to search engine-based advertising, Madison Avenue has established a number of new standards, specifications and spot advertising practices. Taken together, these published and pending initiatives describe an agile landscape where real-time bidding systems can dynamically determine the market value of this new cross-platform media currency.

The TAXI initiative of the Coalition for Innovative Media Measurement established the validity of coordinated advertising campaigns that combine Internet advertising with traditional broadcast ad placement. WideOrbit and ClusterTV are merely two examples of existing systems that provide coordinated cross-platform ad placement on a just-in-time basis.

9.4.5 TechnologyintransitionSMPTE OBID has passed the technology selection phase. While broadcasters await the firmware updates that add support for this newer content identification standard, some are already deploying cross-platform interactivity trials based on the ATSC’s VP1 watermark. The following table provides a brief comparison of the VP1 and OBID feature set. A historical survey of prior North American audience measurement practices was presented at the SMPTE 2016 fall conference.


9.4.5.1 TwoTypesofBroadcastWatermarksBoth of these inaudible audio watermarks can convey standardized content identifiers. Please note that the ATSC ecosystem depends upon Internet connectivity; SMPTE OBID does not.

9.5 CMAFNote that with regard to Manifests, CMAF supports two different Manifest formats that can be referenced: HLS m3u8 and DASH .mpd

9.6 IMF–APEXIMFOPLContent prepared for use in IFE that originates in IMF SHOULD include a Media Manifest that will support conversion from IMF to CMAF using appropriate IMF OPL. CMAF files produced in this manner SHALL support late binding. Guidance for producing updated files is included in [BP-META-MMMD].

Steps for converting from IMF to CMAF:

IMF Source format (Interoperable Master Format) CPL One or more playback sequences (IMF Composition Playlist, SMPTE ST 2067-3) CMAF Profile/Target

One or more desired playback profiles (SD, HD, UHD, etc.) and targets (streaming, download, etc.)

OPL One IMF output profile per CMAF Profile/Target (IMF Output Profile List, SMPTE ST 2067-100)

Transform/Output Process CPLs/OPLs to produce sets of single-track CMAF files (video, audio, subtitles) for each Profile/Target, plus ancillary files.

This step includes encryption, using CENC. See [BP-META-MMMD]. CM Produce a Common Manifest per CMAF Profile/Target.

Note: CMAM has the ability to reference IMF CPL/OPL tracks directly, per MovieLabs TR-META-MMIMF (Using Common Media Manifest with Interoperable Media Format [IMF]), but such CMs are not directly playable by consumer-oriented applications. CAFM files referencing IMF CPL/OPL may be useful input to the Transform/Output step. The CMs indicated here should reference CMAF files, which are directly playable by consumer-oriented applications.

CMP Collect files from Transform/Output process into CMP Distribution Distribute CMPs to storage/playback environments. (Separately distribute keys through

high-security channels.)


10 InformativeAnnex-AcronymsandAbbreviations

ACF APEX Content Format, any format specified in this document

AVC Advanced Video Codec, H.264, MPEG-4 Part 10

BITE built-in test equipment

CMAF Common Media Application Format as in ISO/IEC 23000 Part 19 (MPEG-A)

Constrained VBR VBR mode settings that approximate a constant bit rate data flow

CP Content Providers

CSP Content Service Provider

CRL certificate revocation list

DCMETA Movie Labs metadata specification

HEVC High Efficiency Video Codec, H.265, MPEG-H

HSD HEVC-encoded SD

IFEC Inflight Entertainment and Communications

IMF Interoperable Master Format, SMPTE ST 2067-2)

MP4RA MPEG4 Registration Authority

Pax passenger(s)

PDL Portable Data loader

PED Portable Electronic Device

PPL Post Production Labs

SD Standard definition video up to 576 vertical samples. Commonly 720 x 480 in NTSC

SEE Secure Execution Environment, also called a Trusted Execution Environment, is an isolated environment that runs in parallel with the operating system, providing confidentiality and integrity to application execution and data inside the SEE

4K 4096 x 2160

UHD Ultra-high definition, at least 3840 x 2160


11 InformativeAnnex-ListofParticipants

Seth Arnold Disney

Loren Bolstridge Delta Air Lines

Arthur Cuyugan Paramount Pictures

Eric Diehl Sony Pictures

Heather Field Fox

Victor Hernandez Thales InFlyt Experience

Johannes Jauch Axinom

Fereidoon Khosravi Venera Technologies

Peter Kocic Warner Brothers

Albert Koval DECE

John Lai Amazon Web Services

Jesse Leiva West Entertainment

Ryan Lewis Google

Cedric Le May Thales InFlyt Experience

Nicole Little Disney

Zizhou Lui Infligjht Dublin

Joshua Luckel Digecor

James Macrae Bluebox Avionics

Erin McIntyre Ideanova

Jared Mcphillen Disney

Steffen Mersch Lufthansa Technik

David Miller Inflight Dublin

Chris Odgers Warner Brothers

Toshiro Ozawa Thales InFlyt Experience

Andrew Popov BuyDRM

Steven Rines Zodiac Inflight Innovations


Andy Rosen DSR

Bryan Rusenko Consultant

Michael Sedlack Global Eagle

Juraj Siska Ideanova

Justin Smith Global Eagle

Michael Stattmann Castlabs

Arnaud Sumien Thales InFlyt Experience

Justin Smith Global Eagle Entertainment

Artjom Vinogradov Axinom

Tammy Wange Fox

Philip Watson Panasonic Avionics

Mrudula Yalamanchili Zodiac Inflight Innovations


12 InformativeAnnex-WidevineCross-ReferenceImplementing Google Widevine, which defines three different Levels of security from 1 (most) to 3 (least), can meet much of the requirements in §8.1. This table attempts to summarize minimum requirements each Widevine Level satisfies but should not be interpreted as an authoritative definition of Widevine levels. This is only informative and does not guarantee acceptance by content owners nor Widevine.

PlaybackDevice

EnhancedPremium

EnhancedNon-

Premium

Non-EnhancedPremium

Non-Enhanced

Non-Premium

Non-EnhancedSD

Non-premium

WiredorWirelessSeat

Devices(closednetwork)

L1 L2 L3 L3 L3

AirlineownedPortableElectronicDevices

L1 L1 L3 L3 L3

PAXownedPEDs

L1 L1 L3 L3 L3

apex specification 0415 media & device ife ecosystem … · 2019-05-06 · • enabling content...

Documents