Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

HideElements
metastrue
commentstrue
childpagestrue
toolstrue
labelstrue
likestrue

Specification for Devices 2018

Version: 4.11

Date: 2017-09-15

CONTENTS

Table of Contents
include^[0-9].*
excludezzzzz(^Apps.Req|^CONTENTS)

1. REVISION HISTORY

 

Version Number

Chromium

Date

Comment

4.9.0

53.0

2016-08-18

Publication release

4.9.0-r1

53.0

2016-11-04

Changes:

  • Default background/text color: section 3.12.3

  • Key Back is remapped to JavaScript VK_BACK, not VK_BACK_SPACE: section 3.7.1

  • The default behavior of Back key: section 3.7.1.2

  • OPR/ component added to the UserAgent String: section 3.8

  • Device screen resolution: section 2.4.1.4 and 3.9

  • Optional feature ‘persistent licences’ for Widevine was removed: section 3.5.1.3

4.10

56.0

2017-03-16

Changes:

  • Added a few MPEG-DASH MIME types profiles to be recognized by MPEG-DASH client: section 3.2.3.2

  • Clarified <SegmentList> support as optional: section 3.2.3.2

  • Clarified scope of h.264 and h.265 video codec support: section 3.6.2

  • EME is only available via https protocol: section 3.5.2.2

  • EME updated to spec July 2016: section 3.5.2.2

  • Dropped support of progressive VP9 Profile 2 streaming: section 3.6.2

4.1159.02017-09-15

Changes:

  • Rebranded to a new company entity
  • Media Source Extensions is required in newer revision - W3C Candidate Recommendation 05 July 2016: section REFERENCES

  • Added performance requirements for CSS Transforms: section 3.11

  • Clarified requirements regarding no Internet connection: section 3.12.7

  • Clarify HDR support for specific codecs and streaming protocols: section 3.6.2

 

2. INTRODUCTION

2.1. Scope

This document specifies the requirements that must be met by devices in order to be part of the Vewd Certify Program.

The Certify for Devices defines a complete OTT platform suitable for any OTT content globally, with rich features for media streaming, content protection, and security. As the document is based on feedback from content owners and app developers worldwide, failure to support the features specified below will place limits on the apps and OTT content that a device will be able to support.

Note that requirements for specific apps (such as YouTube TV) or regional standards (such as HbbTV or Freeview Play) are out of the scope of this document.

2.2. Versions for requirements and software

For each update of the Vewd Core, the version number of this specification and the Specification for Devices [1] are also updated to match.

2.2.1. Backward compatibility

New versions of these requirements may not be backward compatible with previous versions. Changes are planned to be introduced in two phases which both last approximately 6 months.

...

  • After a deprecation period, [DEPRECATED] items will be removed in later versions of the specification.

  • Items that are introduced in later versions of the specification will be marked as [INTRODUCED in <version>].

  • The Specification revision history table will be updated accordingly.

2.3. Definitions

Chromium and Google Chrome - Chromium is the open-source project that forms the basis of the Google Chrome browser.

Certify for Devices - A program run by Vewd Software AS to certify platforms according to this specification. The goal of the program is to ensure that a platform can run all OTT apps that are certified for Vewd.

...

Vewd Specification for Devices or Specification for Devices - This document, which specifies the platform requirements that Vewd Devices must meet to be officially certified, and the features that an app can expect to have available when running on a Vewd Device.

See also: 4. Abbreviations

2.4. Compliance terminology used in this document

The following keywords used in this specification to indicate the level of compliance needed for the requirements are sourced from RFC2119 [30]. In essence:

  • MUST, REQUIRE or SHALL indicates that you need to comply with the requirement absolutely.

  • SHOULD or RECOMMENDED indicates that while sometimes there could be valid reasons to ignore the requirement, you need to fully understand and accept the implications and risks to optimal end-user experience.

  • MAY or OPTIONAL indicates that you can decide to implement an item at your discretion.

2.4.1. REQUIRED and CONDITIONALLY REQUIRED features

We also use an additional compliance term not described in RFC2119:

...

Below is an overview of requirements that are dependent on underlying platform capabilities. For more information about each item see the corresponding sections in this document.

2.4.1.1. DRM

Support for content protection with Microsoft PlayReady is mandatory for Vewd Devices, while content protection with Google's Widevine is mandatory only if the device has Widevine installed.

2.4.1.2. Codecs and media formats

Support for video codecs and media formats is only mandatory if the codecs or formats are supported by the underlying platform, as these are dependent on the chipset powering the device, and on external licenses. some codecs.

...

  • WebM (Only required when VP8 and / or VP9 is supported)

2.4.1.3. Keys on the remote control

The design of the remote control is up to each manufacturer, and may vary in size and functionality. Some keys are marked as mandatory (such as. 4-way navigation keys), while others are marked as mandatory only for devices where there is such a key on the remote control.

2.4.1.4. Resolution

The maximum resolution of a device is defined by the manufacturer. All devices must support either HD (720p) or Full HD (1080p), but some features may be mandatory if the device supports Full HD (1080p) or Ultra HD/4K (2160p) resolutions.

3. TECHNICAL REQUIREMENTS

3.1. HTML5 <video> and <audio>

Vewd Devices MUST support HTML5 <video> and <audio> elements according to the HTML 5.1 specification [9].

3.1.1. Media element

3.1.1.1. Requirements for video and audio media elements

All devices MUST support the following requirements for the handling of <video> and <audio> media elements:

...

  • Handling of error states during playback (4.7.14.1)

  • Audio and video elements MUST be able to play both types of sources (4.7.14)

  • Proper handling of events during the playback (4.7.14.84.7.14.94.7.14.15)

  • Proper handling of playbackRate and defaultPlaybackRate (4.7.14.8)

  • The resource selection algorithm MUST work properly in the case of multiple source elements (4.7.14.5)

  • The preload attribute of the media element MUST be respected (4.7.14.5)

3.1.1.2. Requirements for video media elements

All devices MUST pass the following requirements for the handling of <video> media elements:

  • Handling the poster attribute (4.7.10)

  • Proper aspect ratio MUST be preserved during resizing of the containing element of the video (4.7.20)

  • Video elements MUST be able to play a stream containing only audio and text tracks (4.7.10)

  • Proper rendering of video sources

  • Transition between two video streams, one playing, and one preloaded, must be seamless (within 2s)
    PLANNED INTRODUCTION: Future versions of this document will require three video streams: one currently playing and two pre-loaded.

3.1.1.3. Codec support

All devices MUST respond truthfully to codec support inquiries:

  • canPlayType response for specified video and audio codecs (4.7.14.3)

3.1.2. Track element

Devices MUST support rendering of subtitles and closed captions as specified in HTML 5.1, "The track element" (4.7.13). Supported track formats are specified in the  Subtitles and Closed Captioning section.

3.1.2.1. Requirements for all track elements

A device MUST meet the following requirements for the handling of track elements:

3.1.2.2. Requirements for text track elements

  • Devices MUST support the synchronization of the text track and the audio track.

  • Text tracks MUST be rendered properly on video media elements.

3.2. Media streaming

3.2.1. Transport protocols

  • The device MUST support the retrieval of any media content either by HTTP or HTTPS using HTTP protocol v1.1 and Range requests.

  • The device MUST support Transport Layer Security (TLS) version 1.2 with forward security.

  • TLS key sizes MUST be at least 2048 bits for RSA and 256 bits for EC.

  • TLS MUST NOT use any known insecure cryptographic primitives (e.g., RC4 encryption, SHA-1 certificate signatures).

3.2.2. Progressive download

The device MUST support the following combinations:

 

Container

Audio codecs

Video codecs

DRM

DRM trigger

In-band subtitles

ISO BMFF

AAC-LC

HE-AAC v1

HE-AAC v2

MP3

Dolby AC3

Dolby E-AC-3

H.264

H.265

None

None

Not supported

MPEG2-TS

AAC-LC

HE-AAC v1

HE-AAC v2

MP3

Dolby AC3

Dolby E-AC-3

H.264

None

None

Not supported

WebM

Opus

VP8

VP9

None

None

Not supported

ADTS / AAC

MP3



AAC-LC

HE-AAC v1

HE-AAC v2

MP3

None

None

None

Not supported

Info

Note 1: All rules and restrictions for the support of media formats and codecs applies as outlined in the Video and audio formats section.

 

3.2.3. Adaptive Bitrate streaming protocols

The following Adaptive Bitrate (ABR) streaming protocols MUST be supported:

 

Streaming Type

MIME-Types

Notes

Apple HTTP Live Streaming (HLS)

application/vnd.apple.mpegurl

application/x-mpegURL

VoD (append-mode window) and Event (sliding window)

MPEG-DASH

application/dash+xml

Main and Live profiles of MPEG-DASH

Microsoft Smooth Streaming (MSS)

application/vnd.ms-sstr+xml

application/vnd.ms-playready.initiator+xml

 

 

3.2.3.1. Apple HTTP Live Streaming (HLS)

The device MUST support HTTP Live Streaming Protocol version 3, as defined in [2]. It MUST support both Live and On-Demand streams. Support for the following M3U8 playlist tags is REQUIRED:

 

 

Container

Audio codecs

Video codecs

Encryption

Decryption trigger

In-band subtitles

MIME type

MPEG2-TS

AAC-LC

HE-AAC v1

HE-AAC v2

MP3

Dolby AC3

Dolby E-AC-3

H.264

H.265

None

 

Not supported

application/vnd.apple.mpegurl

application/x-mpegURL

MPEG2-TS

AAC-LC

HE-AAC v1

HE-AAC v2

MP3

Dolby AC3

Dolby E-AC-3

H.264

H.265

AES-128

Manifest

Not supported

application/vnd.apple.mpegurl

application/x-mpegURL

ADTS

AAC-LC

HE-AAC v1

HE-AAC v2

None

None

 

Not supported

application/vnd.apple.mpegurl

application/x-mpegURL

ADTS

AAC-LC

HE-AAC v1

HE-AAC v2

None

AES-128

Manifest

Not supported

application/vnd.apple.mpegurl

application/x-mpegURL

MP3

MP3

None

None

 

Not supported

application/vnd.apple.mpegurl

application/x-mpegURL

MP3

MP3

None

AES-128

Manifest

Not supported

application/vnd.apple.mpegurl

application/x-mpegURL

Info

Note 1: All rules and restrictions for the support of media formats and codecs applies as outlined in the Video and audio formats section.

 

3.2.3.1.1. Restrictions for HLS content

A device MUST be able to handle streams with the following limitations:

...

  1. Audio/video encoding

    1. The same codec MUST be used across all variant streams (all quality levels).

    2. Audio parameters (number of channels and sample rates) MUST be the same across all variant streams.

  2. Media segments

    1. All media segments MUST be independently decodable. Consequently, the first video frame in every segment that contains video MUST be an IDR frame.

    2. Discontinuities in timestamps, frame rate, encoding profiles, or audio/video parameters MUST NOT occur within segments.

  3. Playlist files (M3U8)

    1. Audio and video playlists MUST use the same target duration, and MUST contain the same duration of content.

    2. A playlist MUST NOT contain invalid URLs.

    3. Media sequence numbers MUST be aligned across all variant streams (quality levels), so that media sequence numbers can be used to identify matching content.

    4. For live streams, media segments MUST remain available on the server for at least one target duration after the segment disappears from the playlist.

    5. Playlists MUST use sufficiently accurate segment durations to ensure that the sum of the #EXTINF durations of any contiguous group of segments is within one video frame duration of the actual duration.

    6. Playlists MUST provide at least 6 segments in live/linear streams.

    7. Discontinuities in timestamps, frame rate, encoding profiles, or audio/video parameters MAY occur between segments, but such discontinuities MUST be indicated using the #EXT-X-DISCONTINUITY tag.

    8. EXT-X-STREAM-INF tags MUST always provide CODECS and RESOLUTION attributes.

  4. Subtitles

    1. The device MUST support subtitles that conform to the Subtitles and Closed Captions section.

  5. DRM

    1. The decryption key MUST be directly downloadable via an HTTP or HTTPS URLs

    2. Note that with AES-128 encrypted HLS, segments are completely encrypted.

3.2.3.2. MPEG-DASH

The device MUST support the following MPEG-DASH profiles:

 

Profile

Identifier

Reference

ISO Base Media File Format Live

urn:mpeg:dash:profile:isoff-live:2011

[3], section 8.4

ISO Base Media File Format Main

urn:mpeg:dash:profile:isoff-main:2011

[3], section 8.5

DASH-AVC/264

http://dashif.org/guidelines/dash264

urn:com:dashif:dash264

[29], section 6.3

DASH-AVC/264 SD

http://dashif.org/guidelines/dash264#sd

[29], section 7.3

DASH-AVC/264 HD

http://dashif.org/guidelines/dash264#hd

[29], section 8.3

DASH-AVC/264 main

http://dashif.org/guidelines/dash264main

[5], section 8.2

DASH-AVC/264 high

http://dashif.org/guidelines/dash264high

[5], section 8.3

Info

Note that the DVB Profile of MPEG-DASH ([4]section 4.1), identified as “urn:dvb:dash:profile:dvb-dash:2014”, is required by HbbTV 2.x and Freeview Play (UK), and that support for this profile is planned to become mandatory in a later version of this specification.

 

...

 

Container

Audio codecs

Video codecs

DRM

DRM Trigger

In-band subtitle

MIME type

ISO BMFF

AAC-LC

HE-AAC v1

HE-AAC v2

MP3

Dolby AC3

Dolby E-AC-3

H.264

H.265

None

None

Supported

application/dash+xml

ISO BMFF

AAC-LC

HE-AAC v1

HE-AAC v2

MP3

Dolby AC3

Dolby E-AC-3

H.264

H.265

ClearKey

PlayReady

Widevine

EME

Supported

application/dash+xml

Info

Note 1: All rules and restrictions to the support of media formats and codecs applies as outlined in the Video and audio formats section.
Note 2: All rules and restrictions for the support of DRM applies as outlined in the DRM and EME sections.

 

3.2.3.2.1. Restrictions for MPEG-DASH content

A device MUST be able to handle streams, with the following limitations:

...

Clients may fail gracefully on streams that do not abide by the following restrictions and are not compliant with the [5] DASH-IF Interoperability Points documentation:

  • The media segment container format MUST be the ISO Base Media File Format (aka MP4).

  • All media segments MUST be independently decodable. Consequently, the first video frame in every segment that contains video MUST be an IDR frame.

  • Manifest URLs MAY include the MPD anchor, but MUST NOT use any other than the ‘t’ parameter ([3] section C.4)

  • The device MUST support multiple audio tracks associated with multiple Adaptation Sets defined in an MPD of MPEG-DASH.

  • Each audio track MUST be a separate media stream.

  • Support for the <SegmentList> element is NOT REQUIRED

3.2.3.3. Microsoft Smooth Streaming (MSSS)

Devices MUST support Microsoft Smooth Streaming Transport Protocol v2.2 as defined in [2], and MUST support both Live and On-Demand streams.

NOTE: The version number refers to the MajorVersion and MinorVersion attributes in the manifest, not the Smooth Streaming Protocol Specification version. As of revision 6.0 of the specification, the only valid values are 2.0 and 2.2 (see section 2.2.2.1 in [3]).

 

 

Container

Audio codecs

Video codecs

DRM

DRM Trigger

In-band subtitle

MIME type

PIFF v1.1 [13]

AAC-LC

HE-AAC v1

HE-AAC v2

H.264

None

None

Supported

application/vnd.ms-sstr+xml

PIFF v1.1 [13]

AAC-LC

HE-AAC v1

HE-AAC v2

H.264

PlayReady

Manifest

Supported

application/vnd.ms-sstr+xml

PIFF v1.1 [13]

AAC-LC

HE-AAC v1

HE-AAC v2

H.264

PlayReady

WebInitiator

Supported

application/vnd.ms-playready.initiator+xml

Info

Note 1: all rules and restrictions to the support of media formats and codecs applies as outlined in the Video and audio formats section.

Note 2: All rules and restrictions to the support of DRM applies according to the DRM and WebInitiator sections.

 

3.2.3.3.1. Restrictions for Smooth Streaming content

A device MUST be able to handle streams within the following limitations:

...

  • All media segments MUST be independently decodable. Consequently, the first video frame in every segment that contains video MUST be an IDR frame.

  • For live streams that use FragmentLookahead, segments MUST remain available on the server for one DVRWindowLength after they disappear from the Manifest file.

3.3. Media Source Extensions (MSE)

Media Source Extensions MUST be supported according to the MSE specification [7]. The following combinations of containers and codecs MUST be supported:

...

Note: All rules and restrictions to the support of media formats and codecs in MSE applies as outlined in the Video and audio formats section.

3.4. Subtitles and Closed Captioning

To display subtitles or Closed Captions, the device MUST support WebVTT according to [15] to the extent that it is supported by the Chromium engine, and MUST support the EBU-TT-D text track profile, as specified in [17], which is a subset of the TTML text track format.

...

 

Media delivery method

In-band subtitles

Out-of-band subtitles

Progressive playback

Not supported

Mandatory

HLS

Not supported

Mandatory

MPEG-DASH

Mandatory

Mandatory

Smooth Streaming

Mandatory

Mandatory

MSE

Not supported

Mandatory

 

3.5. DRM

3.5.1. Content Decryption Modules (CDMs)

3.5.1.1. ClearKey

  • MUST be supported with EME

3.5.1.2. PlayReady

  • MUST be supported with EME

  • MUST be supported with WebInitiator

  • PlayReady Header Object v4.0.0.0 MUST be supported [8]

  • PlayReady Header Object v4.1.0.0 SHOULD be supported [8]

  • MUST be supported with security level “2000” or higher

3.5.1.3. Widevine

  • Widevine is CONDITIONALLY REQUIRED if the platform has Widevine DRM installed

  • MUST be supported with EME

  • MUST be supported with security level “L1”

  • SHOULD support ”server certificate” and “privacy mode” features

3.5.1.4. AES-128 encryption

  • MUST be supported for Apple HLS streams

3.5.2. DRM Invocation Methods

3.5.2.1. WebInitiator

PlayReady MUST be supported with the features below:

...

  • Available only together with Microsoft Smooth Streaming (MSSS) content

  • Mime type: "application/vnd.ms-playready.initiator+xml"

3.5.2.2. Encrypted Media Extensions (EME)

Encrypted Media Extensions (EME) MUST be supported un-prefixed according to the W3C Working Draft 05 July 2016 [6].

Note: EME MUST only be used on secure contexts, it can not be used on any pages served over HTTP.

...

  • ClearKey according to EME specification “9.1 Clear Key”

    • MUST support key system ID: “org.w3.clearkey”

    • MUST support initialization data types: CENC [10], WEBM [11], KEYIDS [12]

  • Widevine (CONDITIONALLY REQUIRED)

    • Widevine MUST be supported when available on the device

    • MUST support key system ID: “com.widevine.alpha”

    • MUST support initialization data type: CENC [10], KEYIDS [12]

    • Robustness “HW_SECURE_DECODE” MUST be supported for video

    • Minimal robustness “SW_SECURE_CRYPTO” MUST be supported for audio

    • Features ”server certificate” and “privacy mode” SHOULD be supported

  • PlayReady

    • MUST support key system ID “com.microsoft.playready”

    • MUST support initialization data type: CENC [10]

EME MUST work with MSE and adaptive streaming.

...

  • Manifest - DRM initialization data are stored in an adaptive streaming manifest

  • Media container - DRM initialization data are stored in a video container (CENC [14] or PIFF [13])

Not all DRM invocation methods and DRM systems are available with all transfer protocols. This is specified in detail in the section for each protocol. Every CDM MUST be supported with all combinations of MSE-supported formats and codecs.

NOTE: Either Widevine or PlayReady is required to play encrypted content on YouTube TV. Widevine is required in order to support Ultra HD/4K resolution videos on YouTube TV.

3.6. Video and audio formats

3.6.1. Media container formats

The following media container formats MUST be supported:

  • ISO Base Media File Format ISO/IEC 14496-12:2012

    • Streaming-optimized MP4 (moov box before the mdat box)

    • Unoptimized MP4 (mdat box before the moov box)

  • WebM (CONDITIONALLY REQUIRED)

    • MUST be supported when VP8 or VP9 video codecs are available on the device

  • MPEG2-TS ISO/IEC 13818-1:2000

  • ADTS / AAC (audio elementary stream)

  • MPEG-1 Layer III (audio elementary stream)

3.6.2. Video codecs

The following video codecs formats MUST be supported:

  • H.264 as specified in [20]

    • The device MUST support all profile/level configurations up to High Profile Level 4.1 included.

  • H.265 as specified in [19] (CONDITIONALLY REQUIRED)

    • H.265/HEVC MUST be supported when the codec is available on the device

    • The device MUST support all profile/level configurations up to High Profile Level 4.1 included.

    • HEVC Main Level 5 and 5.1 (CONDITIONALLY REQUIRED)

      • These two levels MUST be supported when the device supports Ultra HD/4K resolution (2160p)

    • HEVC Main 10 Level 4.1 and 5.1 (CONDITIONALLY REQUIRED)

      • These two levels MUST be supported when the device supports HDR, either HDR10 or HLG10

      • It is ONLY required in the case of MPEG-DASH streaming use-case
  • VP8 as specified in [21] (CONDITIONALLY  REQUIRED)

    • VP8 MUST be supported when the codec is available on the device

  • VP9 as specified in [22] (CONDITIONALLY REQUIRED)

    • VP9 MUST be supported when the codec is available on the device

    • Profile 0 (CONDITIONALLY REQUIRED)

      • When device supports VP9 then VP9 profile 0 MUST be supported

      • The following VP9 levels MUST be supported (described in [18]): 1, 1.1, 2.1, 3, 3.1, 4, 4.1

      • When the device supports video in Ultra HD/4K resolution (2160p) then it MUST support the VP9 levels (described in [18]): 5, 5.1

    • Profile 2 (CONDITIONALLY REQUIRED)

      • When the device supports HDR, either HDR10 or HLG10, then VP9 profile 2 MUST be supported

      • The device MUST support the VP9 levels (described in [18]): 1, 1.1, 2.1, 3, 3.1, 4, 4.1

      • When the device supports video in Ultra HD/4K resolution (2160p), it MUST support the VP9 levels (described in [18]): 5, 5.1

Info

VP9 Profile 2 is ONLY required in the case of Media Source Extension(MSE) streaming use-case.

HEVC Main 10 is ONLY required in the case of MPEG-DASH streaming use-case

3.6.3. Audio codecs

The following audio codecs MUST be supported:

  • HE-AAC v1

  • HE-AAC v2

  • LC-AAC

  • MP3

  • Opus (CONDITIONALLY REQUIRED)

    • Opus MUST be supported when the codec is available on the device

  • Dolby AC3/E-AC3 (CONDITIONALLY REQUIRED)

    • Dolby AC3/E-AC3 MUST be supported when the codecs are available on the device

Annex A specifies the mime-types for audio and video encoding schemes.

3.7. Input handling

3.7.1. Key mappings

The device MUST provide standardized key codes which are mapped from a remote control input to a platform key which MUST be sent to the Vewd Core. All “JavaScript key code” constants MUST be available to the web apps in the global JavaScript context.

...

Info

CONDITIONALLY REQUIRED* - MUST be supported if this particular key is available on the remote control.


3.7.1.1. Navigation and Select keys

Navigation and Select keys MUST result in sending corresponding key codes with key events into the web app according to the DOM Level 3 Events specification ([23]).

3.7.1.2. Back key

The Back/Return button is a mandatory button on the remote control to go back or close the app. The JavaScript window.VK_BACK is passed to the app, so it can be handled by JavaScript. The caption for this button should be "Back" or "Return" or similar, as long as it remains clear to the end user. The caption should also be consistent with the entire device UI.

3.7.1.3. Exit/Close key

The Exit/Close button is an optional but recommended key on the remote control. The device firmware handles the key, and it should close the app immediately with no event exposed to the app. Its caption should be clear so the end-user understands what they are pressing (example: Exit/Close), and it should be on par with how other use-cases and device functionality is closed.

3.7.1.4. window.close()

When a web app calls window.close() in JavaScript, the device MUST handle the call by closing the specific window (app) immediately.

3.7.1.5. Entering text

The device MUST provide a method to input characters into edit or password fields on web pages, either via an on-screen keyboard, or a hardware device (keyboard) that supports entering text.

3.8. User Agent string

The User Agent string MUST contain the following components:

...

 

Component

Comment

Mozilla/5.0 (<OS> <Architecture>)

  • The browser states it’s “Mozilla-compatible”

  • OS - operating system, e.g. Linux or Android

  • Architecture - CPU architecture, e.g. MIPS or ARM

AppleWebKit/537.36 (KHTML, like Gecko)

WebKit version

Chrome/53.0.*

The Chrome version

Safari/537.36

Safari version

OPR/40.0.2207.0

Opera Desktop version

OMI/4.9.0.*

The Vewd Core version

Model/<CustomerName>-<DeviceModel>

  • “CustomerName” MUST represent the name of the OEM company

  • “DeviceModel” MUST represent generalized or particular model name of the OEM device

Info

Note that minor versions of Chrome/ and OMI/ components MAY differ between devices, as it depends on number of builds and fixes delivered in particular project.

 

The entire User Agent string MAY resemble the following example:

Mozilla/5.0 (Linux MIPS) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2774.3 Safari/537.36 OPR/40.0.2207.0 OMI/4.9.0.41.E107811.5 Model/MyManufacturerName-MyModelName

 

3.9. Screen resolution

The target device MUST be capable of rendering at one of the following resolutions:

...

Depending on the resolution of the graphics plane, logical resolution and CSS pixel resolutions ([28]) WILL be supported as outlined in the following table:

...

 

Application window type

Resolution

Generic

According to the table above

TV Store

Always 1280 x 720

HbbTV

Always 1280 x 720

TV Browser UI

According to the table above

 

3.10. Security

3.10.1. Same-Origin policy

The device MUST apply Same-Origin policy with no exceptions.

3.10.2. Mixed content

The device MUST NOT allow any active mixed content in:

...

  • <img> (src attribute)

  • <audio> (src attribute)

  • <video> (src attribute)

  • <object> subresources (when an <object> performs HTTP requests)

3.10.3. Root certificates

On Linux, the device MUST provide all root certificates vetted according to the Mozilla Root Certificate Program [24] as included by default in Mozilla Network Security Services (NSS) library. The device MAY include additional trusted root certificates according to customer-specific certificate programs.

...

On Android, by default, the System Credentials Storage is used to validate server certificates during SSL handshakes. The device MUST provide a reliable implementation of the storage in order to trust given servers.

3.11. Performance

Vewd Software AS reserves the right to review the performance of the Vewd integration running on the target device, including how quickly and smoothly the device handles animations, transitions (scale, rotate, skew, 2d, 3d), rendering full-screen images (jpg, png), 2d/3d canvas, remote control input latency, and video playback response (play, seek, pause).

  • The device is RECOMMENDED to maintain at least 48fps animating one object using CSS transforms.
  • The device is RECOMMENDED to maintain at least 26fps animating 20 objects using CSS transforms.

3.12. Settings

3.12.1. Fonts and languages

The device MUST provide a Sans Serif font containing all the characters required to properly render the text in the languages available on the device. Web Fonts in WOFF / WOFF2 (Web Open Font Format) and TTF (TrueType Font) file format MUST be supported. Right-to-left rendering MUST be supported if required by any language available on the device.

...

  • The window.navigator.language JavaScript object MUST be set according to specification [9], section “7.1.6.2 Language preferences”.

  • Accept languages MUST be consistent between HTTP Accept-Language header and the window.navigator.languages JavaScript object and SHOULD include the current locale.

3.12.2. Date and time

The device MUST provide the current date and time, either set automatically, or set manually by the end user, for example, via the Settings menu, in order to successfully open secure web pages.

3.12.3. Default colors

The device MUST open web pages using the following default colors:

 

Property

Default color

Background color

White

Font color

Black

 

3.12.4. Memory

The target device MUST enable and define a browser memory limit of at least 200MB. This includes memory available to the browser to render an app and to allocate the memory the application requests.

3.12.4.1. Out of memory

The device MUST handle out-of-memory situations gracefully by releasing unused memory to make it available to the browser engine. If no memory can be released, then the device MUST show a warning message that there is insufficient memory on the device.

3.12.5. Storage

The device MUST ensure that the following minimum storage is available for apps:

  • 64MB for localStorage ([26])

  • 16MB for Temporary Storage ([26])

  • 32MB for HTTP cache

The memory for the localStorage SHOULD be shared between all apps, and each app MAY use up to 10MB. The localStorage and sessionStorage SHOULD have a limit of 5MB per origin.

...

The device is NOT REQUIRED to support persistent storage from the Quota Management API ([27]).

The in-memory backend for the HTTP cache SHOULD be used if the access time to the file system on the device introduces the measurable performance penalty.

3.12.6. Cookies

The device MUST provide the possibility of storing at least 2000 cookies,; at least 180 cookies per domain, with at least 4096 bytes (for example, a total of 8MB cookie storage). The device MUST NOT remove any persistent cookies that have been accessed within the last 30 days.

3.12.7. Disconnect from network

The device MUST present a user-friendly message when an internet connection is not available. The network connection should be working again after the connection is restored (cable plugged-in or WiFi network available).

3.12.8. Cannot open URL

The device MUST present a user-friendly message when a URL is unreachable. 

4. ABBREVIATIONS

 

AAC

Advanced Audio Coding

AC-3

(Dolby Digital) Audio Compression 3

ADTS

Audio Data Transport Stream

CENC

Common Encryption

CDM

Content Decryption Module

DASH

Dynamic Adaptive Streaming over HTTP

DASH-IF

DASH Industry Forum

DRM

Digital Rights Management

E-AC-3

(Dolby Digital) Enhanced Audio Compression 3

EBU-TT-D

EBU Timed Text format, part D - the format for the distribution of subtitles over IP

EME

Encrypted Media Extensions

HbbTV

Hybrid Broadcast Broadband TV

HDR

High Dynamic Range

HE-AAC

High-Efficiency Advanced Audio Coding

HLS

HTTP Live Streaming

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext Transfer Protocol Secure

IDR

Instantaneous Decoder Refresh

ISO BMFF

ISO base media file format

KEYIDS

Stream-independent format for specifying a list of key ID(s) for DRM initialization

LC-AAC

Low-Complexity Advanced Audio Coding

LFE

Low Frequency Effects

MPD

DASH Media Presentation Description

MPEG

Moving Picture Experts Group

MPEG2-TS

MPEG-2 Transport Stream

MSS

Microsoft Smooth Streaming

PIFF

Protected Interoperable File Format

SHA

Secure Hash Algorithm

TLS

Transport Layer Security

TTF

TrueType Font

TTML

Timed Text Markup Language

WebM

WebM Stream Format

WebVTT

Web Video Text Tracks format

WOFF

Web Open File Format

WOFF2

WOFF File Format 2.0

 

5. REFERENCES

Anchor
1
1
[1] HLS, HTTP Live Streaming v6 October 02, 2011: https://tools.ietf.org/html/draft-pantos-http-live-streaming-06

...

Anchor
30
30
[30] Key words for use in RFCs to Indicate Requirement Levels - https://www.ietf.org/rfc/rfc2119.txt

 

6. ANNEX A (informative). Media type strings for video and audio codecs

This section specifies codecs and media identifiers for audio and video codecs that MUST be supported with the HTML5 <video> tag. It also provides identifiers for some examples of combinations of those codecs and media containers. The Codec ID strings’ list is not comprehensive, because not all the rules from section 3.6. Video and audio formats are shown below.

6.1. MP4 video and audio

6.1.1. H.264 profiles

 

Profile

Level

Codec ID string [rfc6381]

Baseline

3.1

avc1.42E01F

avc3.42E01F

Main

3.1

avc1.4D401F

avc3.4D401F

Main

4

avc1.4D4028

avc3.4D4028

High

4

avc1.640028

avc3.640028

 

6.1.2. H.265/HEVC profiles

 

ProfileLevelConstraintsCodec ID string
Main3.1Nonehev1.1.6.L93.00
hvc1.1.6.L93.00
4Nonehev1.1.6.L120.00
hvc1.1.6.L120.00
4.1Nonehev1.1.6.L123.00
hvc1.1.6.L123.00
5.1Nonehev1.1.6.L153.00
hvc1.1.6.L153.00
Main 104.1Nonehev1.2.4.L123.00
hvc1.2.4.L123.00
5.1Nonehev1.2.4.L153.00
hvc1.2.4.L153.00

 

6.1.3. AAC profiles

 

Profile name

Codec ID string

AAC-LC

mp4a.40.2

HE-AAC v1 (SBR)

mp4a.40.5

HE-AAC v2 (SBR+PS)

mp4a.40.29

 

6.1.4. MP3 (MPEG-1 Layer III) profiles

 

Codec ID string

mp4a.69

mp4a.6B

 

6.1.5. Dolby profiles

 

Profile name

Codec ID string

AC-3

ac-3

 

mp4a.a5

E-AC-3

ec-3

 

mp4a.a6

 

6.1.6. Combination examples of media type strings

 

Video codec

Video profile

Audio codec

Audio profile

Media type string

H.264 level 3.1

baseline

AAC

aac_he

video/mp4; codecs="avc1.42E01F, mp4a.40.5"

   

aac_lc

video/mp4; codecs="avc1.42E01F, mp4a.40.2"

  

MP3

 

video/mp4; codecs="avc1.42E01F, mp4a.69"

    

video/mp4; codecs="avc1.42E01F, mp4a.6B"

H.264 level 3.1

main

AAC

aac_he

video/mp4; codecs="avc1.4D401F, mp4a.40.5"

aac_lc

video/mp4; codecs="avc1.4D401F, mp4a.40.2"

MP3

video/mp4; codecs="avc1.4D401F, mp4a.69"

video/mp4; codecs="avc1.4D401F, mp4a.6B"

H.264 level 4.0

main

AAC

aac_he

video/mp4; codecs="avc1.4D4028, mp4a.40.5"

   

aac_lc

video/mp4; codecs="avc1.4D4028, mp4a.40.2"

  

MP3

 

video/mp4; codecs="avc1.4D4028, mp4a.69"

    

video/mp4; codecs="avc1.4D4028, mp4a.6B"

H.264 level 4.0

high

AAC

aac_he

video/mp4; codecs="avc1.640028, mp4a.40.5"

   

aac_lc

video/mp4; codecs="avc1.640028, mp4a.40.2"

  

MP3

 

video/mp4; codecs="avc1.640028, mp4a.69"

    

video/mp4; codecs="avc1.640028, mp4a.6B"

 

6.2. WebM video and audio

 

Video format

Video codec

Audio codec

Media type string

WebM

VP8

Opus

video/webm; codecs="vp8, opus"

  

video/webm; codecs="vp8.0, opus"

VP9 profile 0

Opus

video/webm; codecs="vp9, opus"

  

video/webm; codecs="vp9.0, opus"

VP9 profile 2

Opus

video/webm; codecs="vp9.2, opus"

 

6.3. Audio only

 

Audio codec

Audio profile

Media type string

AAC

aac_he

audio/mp4; codecs="mp4a.40.5"

aac_lc

audio/mp4; codecs="mp4a.40.2"

MP3

 

audio/mp4; codecs="mp4a.69"

audio/mp4; codecs="mp4a.6B"

 


Printable versions of specifications

Current version:

Specification for Devices 2018

Version: 4.11

Date: 2017-09-15

View file
nameVewd Certify Devices 4.11.pdf
height250

Older versions:

Specification for Devices 2017

Version: 4.10

Date: 2017-03-16

View file
nameVewd Certify Devices 4.10.pdf
height250

Specification for Devices 2017

Version: 4.9.0-r1

Date:  2016-11-04

View file
nameVewd Certify Devices 4.9.0-r1.pdf
height250