Specification for Devices 2024

Version: 4.24.0

Date: 2022-06-07

CONTENTS

1. REVISION HISTORY

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.

Features that are planned to be removed will be marked as [DEPRECATED] in this specification.

• 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 Core - An embeddable browser and streaming engine with an extensible API, based on the Chromium open-source project, which implements a set of international and industry standards to download and render webpages, execute web apps, and stream video and audio content.

Vewd - A set of products and solutions developed by Vewd Software AS for TV and Set-Top Box (STB) manufacturers to enable HTML5 rendering and adaptive streaming in their devices. 
(Also used as a short form for the company Vewd Software AS)

Vewd Application - a Vewd-compliant web app that is certified to run on Vewd Devices. Also referred to as App or Application in this document.

Vewd Device - A TV or STB device running software based on the Vewd Core, and certified to meet the requirements defined in the Vewd Specification for Devices.

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:

• CONDITIONALLY REQUIRED - an item or a feature that must be supported in the browser if the underlying platform supports this capability. Examples could include a specific audio or video codec, or support for Ultra HD/4K resolution.

This specification defines one platform, and care has been taken to ensure that there are no choices or variants of this platform. However, there are a few features where the functionality available to an app is directly dependent on the capabilities of the device. These features are marked as CONDITIONALLY REQUIRED in this specification.

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.

Audio:

• Opus

• Dolby AC3/E-AC3

• Dolby ATMOS
• Dolby AC4
• Ogg Vorbis

Video:

• H.265

• VP9

• AV1

Container:

• WebM (Only required when 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:

• Initial state of the object’s attributes (4.7.14.2, 4.7.14.6, 4.7.14.8, 4.7.14.9)

• 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.8, 4.7.14.9, 4.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:

• Initial state values of media tracks and text tracks (4.7.14.10.1, 4.7.14.11)

• readyState attribute handling for out-of-band text tracks (4.7.14.11.3)

• Proper handling of enabling and disabling audio tracks (4.7.14.10.2)

• Switching of video and text tracks (4.7.14.10.2, 4.7.14.11)

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:

3.2.3. Adaptive Bitrate streaming protocols

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

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:

• #EXTM3U (section 3.1 in [2])

• #EXTINF (section 3.1 in [2])

• #EXT-X-TARGETDURATION (section 3.3.1 in [2])

• #EXT-X-MEDIA-SEQUENCE (section 3.3.2 in [2])

• #EXT-X-KEY (section 3.3.3 in [2])

• #EXT-X-ENDLIST (section 3.3.7 in [2])

• #EXT-X-STREAM-INF (section 3.3.8 in [2])

• #EXT-X-DISCONTINUITY (section 3.3.9 in [2])

• #EXT-X-VERSION (section 3.3.10 in [2])

3.2.3.1.1. Restrictions for HLS content

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

Devices MAY fail gracefully on streams that do not abide by the following restrictions:

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:

The following combinations MUST be supported by the device:

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.

• The device MUST support multiple Periods defined in an MPD of MPEG-DASH.

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]).

3.2.3.3.1. Restrictions for Smooth Streaming content

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

Clients MAY fail gracefully on streams that do not abide by the following restrictions:

• 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.

Support for in-band and out-of-band text tracks is REQUIRED according to the table below:

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 “3000” on devices supporting Ultra HD/4K (2160p) resolution
• Devices with lower resolution MUST support security level “2000” or higher

3.5.1.2.1. Play Ready - License Acquisition

• Device MUST support automatic license acquisition, supporting the following:

• License Acquisition URLs provided in the manifest MUST override those provided in the PSSH boxes

• License Acquisition URL provided in the WebInitiator MUST override those provided in the manifest and the PSSH boxes

• Reactive License Acquisition (Post-delivery) MAY support CustomData and License Acquisition override mechanism using LA_URL and drm_custom_data variables passed as GET parameters of video source URL to override global settings

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” on devices supporting Ultra HD/4K (2160p) resolution
• Devices with lower resolution MUST support at least security level “L2”
• MUST be supported with automatic license acquisition

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

3.5.1.4. AES-128 encryption

• MUST be supported for Apple HLS streams

• At least one of the following encryption algorithms must be supported:
• AES 128 bit keys in CENC mode: Counter Mode (AES-CTR) and Full-Sample encryption
• AES 128 bit keys in CBCS mode: Cipher Block Chaining mode (AES-CBC) and Sub-Sample encryption

3.5.1.5. Marlin

• Marlin DRM is CONDITIONALLY REQUIRED if the platform has Marlin DRM installed
• MUST support content license acquisition using MS3 tokens as well as Marlin Broadband (BB) tokens.
• MUST be supported using MPEG-DASH media format

3.5.2. DRM Invocation Methods

3.5.2.1. WebInitiator

PlayReady MUST be supported with the features below:

• Licence Pre-Acquisition for PlayReady

• 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.

The following EME features MUST be supported for the CDMs:

• 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.

• The HTMLMediaElement.onencrypted event MUST be triggered if encrypted content has been detected.

• After a successful call to HTMLMediaElement.setMediaKeys() with valid MediaKeys, content MUST be fully playable.

Detecting encrypted content and triggering licence acquisition MUST be supported from:

• 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 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)

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

  • 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

• 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)

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

• VP9 as specified in [22] (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

  • 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

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

• Profile 0 (CONDITIONALLY REQUIRED)

• Profile 2 (CONDITIONALLY REQUIRED)

• AV1 as specified in [21] (CONDITIONALLY REQUIRED)

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

  • Profile 0 (CONDITIONALLY REQUIRED)

  • When device supports AV1 then AV1 profile 0 (MAIN) MUST be supported.

  • The following AV1 levels MUST be supported (described in [21]): 2.0, 2.1, 3.0, 3.1, 4.0, 4.1

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 / AC4 (CONDITIONALLY REQUIRED)

  • Dolby AC3/E-AC3 / AC4 MUST be supported when the codecs are available on the device
• Dolby ATMOS (CONDITIONALLY REQUIRED)
  • Dolby ATMOS is not a codec, but a technology embedded inside E-AC3 and AC4 streams.

• Ogg Vorbis (CONDITIONALLY REQUIRED)

  • Ogg Vorbis be supported when the codecs are available on the device

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

3.6.4 CMAF multimedia format

Common Media Application Format (CMAF) [36] combines and constrains several MPEG specifications to define a multimedia format optimized for delivery of a single adaptive multimedia presentation to a variety of devices, using various adaptive streaming formats, broadcast, download, and storage methods. The device MUST support this standard.

3.6.4.1 AAC audio CMAF tracks

List of allowed AAC profiles [36], section 10.3 AAC audio CMAF tracks

3.6.4.2 Subtitles and captions

CMAF defines the following formats for carrying subtitles and captions [36], section 11.1 Subtitles and captions overview:

• WebVTT subtitle CMAF tracks (in-band, out-of-band)
• IMSC1 subtitle CMAF tracks - (EBU-TT-D conforms to IMSC text profile). IMSC1 is an application of the Timed Text Markup Language (TTML) for subtitle and caption delivery (in-band, out-of-band)
• CTA-608/CTA-708 captions embedded in video CMAF tracks (in-band)

3.6.4.3 AVC video CMAF media profiles and brands

AVC video CMAF media profile shall comply to one of the media profiles in table above [36], annex A.2:

3.6.4.4 HEVC video CMAF media profiles and brands

HEVC video CMAF media profile shall comply to one of the media profiles in table above [36], annex B.5:

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.

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:

3.9. Screen resolution

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

• 1280 x 720
• 1920 x 1080

  • CONDITIONALLY REQUIRED if the device hardware and platform is capable of Full HD (1080p) or higher rendering

  • CONDITIONALLY REQUIRED if the video plane has Ultra HD/4K (2160p) or better resolution

When a generic browser window is opened, the graphics plane MUST be set up so that the browser can see the best resolution the device is capable of rendering. Note that this MAY be lower than the actual number of pixels in the physical display due to limitations in rendering capabilities or performance.

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

Note that the resolution seen in a generic browser window, and specified in this document, may differ from the resolution seen by apps running in a HbbTV Window or under control of the Vewd App Store, as follows:

3.10. Security

3.10.1. Same-Origin policy

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

The device MUST allow Cross-Origin requests, if the application's URL is allowed by request header. Otherwise all Cross-Origin requests MUST be blocked.

3.10.2. Mixed content

The device MUST NOT allow any active mixed content in:

• <script> (src attribute)
• <link> (href attribute) (this includes CSS stylesheets)
• <iframe> (src attribute)
• XMLHttpRequest requests
• All cases in CSS where a URL value is used (@font-face, cursor, background-image, and so on)
• <object> (data attribute)

 
Passive/Display mixed content MUST be allowed on the device but the browser engine SHOULD send a warning to the developer console about mixed content usage. 

Passive/Display mixed content types:

• <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.

The Online Certificate Status Protocol (OCSP) for checking the revocation status of X.509 digital certificates MUST be enabled on the device.

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.10.4 Cipher suites

 The cipher suite requirements are specified in table below and are aligned with HbbTV technical specification [31]. The cipher suites are defined in IETF RFC 5246 ([32]) and IETF RFC 5289 ([33]). Devices should prioritize these cipher suites in the order shown. The device shall implement all cipher suites marked mandatory and shall not implement any cipher suites marked forbidden.

3.10.5 Debugging tools

 Vewd Core supports the development debugging tool (Chrome DevTools) as specified in [25]. This tool can be used only in the development phase and MUST be disabled in the final version of the Vewd Integration. The status of the debugging tool in the Vewd Integration can be checked by visiting “chrome://about” URL.

3.11. Performance

3.11.1. General 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.11.2. Video transition (Advert insertion) performance

 The device SHOULD provide support for dynamic insertion of advertising using two HTML5 media elements (<video> or <audio>) as specified in [34] Annex J (informative): Advert insertion guidance for content providers. This requirement will probably be made MANDATORY in the future versions of this specification.

 At any given time only one HTML media element can be playing. The other element intended for dynamic insertion should be explicitly hidden using CSS property and should start prefetching the media data. Once enough data has been loaded, the second media element should appear and play whereas the first one should be hidden and paused. The delay between the end of the presentation of an HTML5 media element and starting presentation of another HTML5 media element is RECOMMENDED to be less than 250 ms. This time requirement is applicable if the first media element refers to either MPEG DASH content or ISOBMFF (MP4) content and the second media element refers to either MPEG DASH content or ISOBMFF (MP4) content. Advert insertion SHOULD work with two encrypted streams; the 250ms performance, however, is required only in cases of one encrypted stream and one unencrypted stream or two unencrypted streams. The transition between two video streams, one playing, and one preloaded, for any other content than aforementioned, SHOULD be seamless (within 2s).

3.11.3. Image rendering performance

• The terminal MUST be capable of decoding and rendering full screen JPEG / PNGs to screen in < 200 ms.

The terminal SHOULD be capable of smoothly translating a full-screen image, or a half-screen image over background video, across the screen at 25 frames per
second.

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.

Whenever a language is specified by 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:

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 memory for temporary storage SHOULD be shared between all apps, and each app MAY use up to 20% of the shared pool (3.2MB).

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. 

3.13. Accessibility

3.13.1 Text-to-speech

Text-to-Speech (TTS) is an accessibility feature enabling audible spoken words of the text strings shown in an application. Users with impaired vision disability benefit from using Text-to-Speech. Devices MAY choose to support TTS using WAI-ARIA web standards [35]. WAI-ARIA is a set of standards specifying how web applications can define the semantics of a web page, e.g. define that a link is a command, that an area is content, and navigation sequences between areas.
The hints provided by WAI-ARIA are used by the screen reader to enrich the experience and work accordingly to the expectations of web page authors building accessibility-enabled pages.

3.14. WebRTC

The WebRTC is a set of ECMAScript APIs in WebIDL to allow media and generic application data to be sent to and received from another browser or device implementing the appropriate set of real-time protocols.

Vewd Devices MUST support WebRTC APIs according to the W3C Recommendation of the WebRTC 1.0: Real-Time Communication Between Browsers ([37]).

3.14.1 Peer-to-peer Data API

The Peer-to-peer Data API lets a web application send and receive generic application data peer-to-peer. The API for sending and receiving data uses Web Sockets.

The following interfaces and extensions MUST be supported:

• RTCPeerConnection Interface Extensions
• RTCDataChannel
• RTCDataChannelEvent

The following parts of the WebRTC 1.0 specification MUST be supported over a peer-to-peer connection:

• RTP media API
• Peer-to-peer Data API 
• Media Stream API Extensions for Network Use

3.14.2 Media Capture and Streams

The Media Capture and Streams defines a set of JavaScript APIs that allow local media, including audio and video, to be requested from a platform [38]

Vewd Devices MUST support the MediaDevices object, which is the entry point to the API used to examine and get access to media devices available to the browser.

Access to the sources:

• Access to the Network resources MUST be assured.
• Access to the Physical webcam and Microphone MUST be assured if device capabilities support it.

4. ABBREVIATIONS

5. REFERENCES

 [1] HLS, HTTP Live Streaming, RFC 8216 August 2017 - https://tools.ietf.org/html/rfc8216

[2] Smooth Streaming Protocol - https://msdn.microsoft.com/en-us/library/ff469518.aspx

[3] DASH, Information technology — Dynamic adaptive streaming over HTTP (DASH): ISO/IEC 23009-1:2014

[4] DVB MPEG-DASH Profile for Transport of ISO BMFF - https://www.dvb.org/resources/public/standards/a168_dvb-dash.pdf

[5] DASH-IF Guidelines for Implementation - Interoperability Points v3.2 - http://dashif.org/wp-content/uploads/2015/12/DASH-IF-IOP-v3.2.pdf

[6] Encrypted Media Extensions - W3C Candidate Recommendation 05 July 2016 - https://www.w3.org/TR/2016/CR-encrypted-media-20160705

[7] Media Source Extensions - W3C Candidate Recommendation 05 July 2016 - https://www.w3.org/TR/2016/CR-media-source-20160705

[8] PlayReady documents - https://www.microsoft.com/playready/documents/

[9] HTML 5.1 W3C Working Draft, 2 June 2016 - https://www.w3.org/TR/html51/

[10] "cenc" DRM Initialization Data Format - https://www.w3.org/TR/eme-initdata-cenc/

[11] "webm" DRM Initialization Data Format - https://www.w3.org/TR/eme-initdata-webm/

[12] "keyids" DRM Initialization Data Format - https://www.w3.org/TR/eme-initdata-keyids/

[13] Protected Interoperable File Format - http://www.iis.net/learn/media/smooth-streaming/protected-interoperable-file-format

[14] Common Encryption Scheme - ISO/IEC 23001-7

[15] Web Video Text Tracks Format (WebVTT) - https://w3c.github.io/webvtt/

[16] TTML text track format - https://www.w3.org/TR/ttml-imsc1/ 

[17] EBU-TT-D text track format - https://tech.ebu.ch/docs/tech/tech3380.pdf

[18] Definition of video VP9 levels - http://www.webmproject.org/vp9/levels 

[19] High efficiency video coding - International Telecommunication Union (ITU-T) Recommendation for h.265 - https://www.itu.int/rec/T-REC-H.265

[20] Advanced video coding for generic audiovisual services - International Telecommunication Union (ITU-T) Recommendation for h.264 - https://www.itu.int/rec/T-REC-H.264

[21] AV1 Bitstream & Decoding Process Specification - https://aomediacodec.github.io/av1-spec/av1-spec.pdf 

[22] (Draft) VP9 Bitstream and Decoding Process Specification - http://www.webmproject.org/vp9/

[23] DOM Level 3 Events specifcation - https://www.w3.org/TR/DOM-Level-3-Events/

[24] Mozilla CA Certificate Policy - https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy

[25] Chromium Remote Debugging protocol (DevTools) - https://developer.chrome.com/devtools/docs/debugger-protocol

[26] Web Storage API - https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

[27] HTML5 Persistant Storage - https://developer.chrome.com/apps/offline_storage#persistent

[28] CSS Values and Units Module Level 3, Chapter 6.4: Resolution units 
- https://www.w3.org/TR/2016/CR-css-values-3-20160929/#resolution

[29] Guidelines for Implementation: DASH-AVC/264 Interoperability Points - http://dashif.org/wp-content/uploads/2015/04/DASH-AVC-264-v2.00-hd-mca.pdf

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

[31] ETSI TS 102 796 V1.4.1 Hybrid Broadcast Broadband TV Technical Specification - http://www.etsi.org/deliver/etsi_ts/102700_102799/102796/01.04.01_60/ts_102796v010401p.pdf

[32] IETF RFC 5246 - https://tools.ietf.org/html/rfc5246

[33] IETF RFC 5289 - https://tools.ietf.org/html/rfc5289

[34] HbbTV 2.0.1 Specification with Errata #2 Integrated and Changes Marked - https://www.hbbtv.org/wp-content/uploads/2018/02/HbbTV-SPEC20-00061-000-HbbTV_201_with_errata_2_integrated.pdf

[35] Accessible Rich Internet Applications (WAI-ARIA) 1.1 - https://www.w3.org/TR/wai-aria/

[36] ISO/IEC 23000-19:2018 Information technology — Multimedia application format (MPEG-A) — Part 19: Common media application format (CMAF) for segmented media https://www.iso.org/standard/71975.html

[37] WebRTC 1.0: Real-Time Communication Between Browsers https://www.w3.org/TR/webrtc/

[38] Media Capture and Streams: https://www.w3.org/TR/mediacapture-streams/

6. ANNEX

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

6.1.2. H.265/HEVC profiles

6.1.3. AV1 profiles

6.1.4. AAC profiles

6.1.5. MP3 (MPEG-1 Layer III) profiles

6.1.6. Dolby profiles

6.1.7. Combination examples of media type strings

6.2. WebM video and audio

6.3. Audio only

Printable versions of specifications

Current version:

Specification for Devices 2023

Version: 4.23.0

Date: 2022-09-16

Older versions:

Specification for Devices 2022

Version: 4.22-r1

Date: 2022-02-06

Specification for Devices 2022

Version: 4.22

Date: 2021-09-02

Specification for Devices 2021

Version: 4.21

Date: 2020-07-24

Specification for Devices 2020

Version: 4.20-r1

Data: 2019-12-19

Specification for Devices 2020

Version: 4.20

Data: 2019-09-20

Specification for Devices 2019

Version: 4.13-r1

Data: 2019-02-07

Specification for Devices 2018

Version: 4.11