Certification Requirements

1 General runtime

Cobalt Runtime

1.1 The target device MUST use the Cobalt runtime as the underlying Browser engine for all YouTube applications and the version for that runtime MUST be equal to or greater than 23.lts.stable (LTS = Long-Term Support).
- 1.1.1 A toolchain capable of supporting C++17 is REQUIRED to build Cobalt.
- 1.1.2 The target device MUST be able to mark memory as being executable at runtime.
1.2 The target device MUST NOT use an embedded YouTube player-based implementation via the YouTube IFrame player API to show or play any YouTube content; however, this requirement does not prevent one or more browsers from being available on the target device, and a user may use such browsers to select "www.youtube.com" manually.

Starboard APIs

1.3 The version of Cobalt Starboard used in the target device MUST be the latest stable Starboard version that is included with the latest Cobalt LTS release.
- 1.3.1 The target device MUST properly implement all Starboard APIs.
- 1.3.2 The target device MUST pass all Cobalt tests, including Starboard NPLB tests.
- 1.3.3 The target device MUST pass all items of the Cobalt Evergreen test suite corresponding to the type of Evergreen configuration (Lite or Full) that the partner selected; the test suite ensures that the device can support required Cobalt Evergreen features.

Cobalt Configuration

1.4 The integration of Cobalt with the target device operating system / software environment, achieved through the Starboard (Sb) interfaces MUST be configured to use the Cobalt Evergreen-Lite or Evergreen-Full software architecture, which requires the use of separate binaries as enumerated below:
- 1.4.1 A Google-built Evergreen Cobalt Core binary (available on GitHub)
  - The Evergreen binary version MUST match the corresponding Cobalt 23.lts.stable version in manifest.json.
- 1.4.2 A Partner-built Starboard layer (loader_app)
  - Configurations use Evergreen-Full by default; as such, configurations that use Evergreen-Lite MUST use the --evergreen_lite command line flag to launch in Evergreen-Lite mode.
- 1.4.3 A Crashpad implementation, which is included in Cobalt's open source code, that the target device can use to record dumps of process states at the time of a crash.
1.5 The resources referenced in the Cobalt configuration files—such as the default splash screen in the configuration_defaults.cc file—MUST NOT be changed.

2 Loading and Unloading the YouTube Application

Loading the application

2.1.1 YouTube applications MUST be loaded using the following URLs, with any URL parameters appended as required:
- YouTube Main App: https://www.youtube.com/tv
- YouTube Kids: https://www.youtube.com/tv/kids
- YouTube TV: https://www.youtube.com/tv/upg

Unloading the application

2.2.1 When the YouTube application exits, all states MUST be reset, except for persistent local storage data and cookies.

3 Application lifecycle management

3.1 The device MUST fully implement Starboard lifecycle event generation (see lifecycle.md and event.h).
- 3.1.1 When the device unloads or releases the YouTube application and its resources—that is, when the application exits—the device MUST dispatch a 'Stop' Starboard event to switch the YouTube application to the Stopped state.
- 3.1.2 When the YouTube application becomes non-interactive, the device MUST dispatch a 'Blur' Starboard event to switch the YouTube application to the Blurred state.
- 3.1.3 When the device changes the YouTube application from a non-interactive state to an interactive state, the implementation MUST dispatch a 'Focus' Starboard event to switch the YouTube application to the Started state.
- 3.1.4 When the device makes the YouTube application invisible, the device MUST dispatch a 'Conceal' Starboard event to switch the YouTube application to the Concealed state.
- 3.1.5 When the device makes the YouTube application visible, the device MUST dispatch a 'Reveal' Starboard event to switch the YouTube application to the Blurred state.
  - Note: When the application is switched to interactive state, requirement 3.1.3 also applies.
- 3.1.6 When the YouTube application reaches the frozen state—that is, when the application remains in memory but process execution is stopped—the device MUST dispatch a 'Freeze' Starboard event to switch the YouTube application to the Frozen state. Cobalt can be terminated after sending the suspend signal.
- 3.1.7 If (i) the target device is connected to an external display via an HDMI connection, as signaled by HDMI Hot Plug Detect or HDMI CEC messages, and (ii) the YouTube application transitions to a state where it is not the application that is currently visible on the display, including cases where the target device stops being the visible device on the display or goes into standby mode, the target device MUST dispatch a 'Freeze' Starboard event to switch the YouTube application to the Frozen state.
  - 3.1.7.1 The target device MAY send the "Freeze" Starboard event after 30 seconds of HDMI Hot Plug Event to improve reliability.
- 3.1.8 If (i) the target device is connected to an external display via an HDMI connection, and (ii) the target device becomes the visible device—signaled by HDMI Hot Plug Detect or HDMI CEC messages—and (iii) the YouTube application is visible, the target device MUST either dispatch a 'Focus' Starboard event to change the YouTube application to the Started state if the YouTube application has focus, or dispatch a 'Reveal' Starboard event to change the YouTube application to the Blurred state if the YouTube application does not have focus.

4 Device Identification and Configuration

Certification and device verification mechanisms

4.1.1 The partner MUST implement one of the following device verification mechanisms:
- If the partner’s target device:
  - has a proprietary, owned and operated device verification mechanism, AND
  - that mechanism is deployed on the partner’s proprietary, owned and operated operating system, AND
  - that mechanism will reliably identify authenticated devices, AND
  - that mechanism is deployed on 1 Billion or more devices
  THEN the target device MAY use that mechanism to satisfy the device verification requirements for using YouTube applications on the device (Option A).
- If the conditions for using a proprietary, owned and operated device verification mechanism are not met, then the target device MUST include a Security Hardware or Trusted Execution Environment to hold the value of a secret_key field (Option B). All subsequent requirements in section 4.1 apply only to the use of Option B.

4.1.2 If the device does not use a proprietary, owned and operated device verification mechanism—it implements 4.1.1, option B—the target device MUST use the secret_key to sign a message when Cobalt calls Starboard's SbSystemSignWithCertificationSecretKey function.
4.1.3 The device MUST configure three distinct secret key values, in case the first secret key has been leaked.
4.1.4 If the current secret_key is leaked, the device MUST, within a reasonable time, activate a different secret_key in the Security Hardware or Trusted Execution Environment. In the event that all keys on the device are leaked, the device MUST, within a reasonable time, use firmware or software updates, to deploy a new secret_key. Failing to update the secret_key might lead to a degraded YouTube experience.
4.1.5 secret_key values MUST be treated as confidential. To avoid accidental leakage, communication of secret_key values MUST be encrypted and distribution MUST be limited to and within the partner organization.
4.1.6 The target device MUST publish the YouTube certification scope for the device as part of the Widevine license request. When making the request, the device MUST use the key value youtube_cert_scope to communicate that value.
- 4.1.6.1 The value of the certification_scope field MAY be stored in a non-secure storage.

Device Characterization through User-Agent Properties

4.2.1 The User-Agent string MUST uniquely identify the brand and model for the given device. The fields defined in the table in the implementation details for requirement 4.2.1 MUST be included in the User-Agent string and MUST be set in accordance with the instructions in the field descriptions.
4.2.2 The characters used to represent the User-Agent fields MUST be from the printable US-ASCII character set. Cobalt Core filters out characters that interfere with the User-Agent string format.

Identifier for Advertisers

4.3.1 If the target device has implemented application support for an Identifier for Advertising (IFA), the device MUST make this IFA available to YouTube, along with the associated limited ad tracking bit, through the integration mechanism provided by YouTube.

Language and territory

4.4.1 The target device MUST set the Language and Territory using the Starboard System module's SbSystemGetLocaleId() function.
4.4.2 The language and region set through the Starboard System module for querying the device's locale MUST match the language setting on the device and MUST change when the user changes the device language.

5 Cookies and local storage

5.1 Devices MUST provide persistent storage for cookies, local data, and cache.
- 5.1.1 The storage MUST remain intact after the device is powered on and off at least 200 times or after the YouTube application is launched and exited at least 200 times with those launches and exits spread uniformly over a 24-hour period.
5.2 Data MUST be stored locally on the device.
5.3 All locally stored data MUST be persisted unless
- Manually cleared by a user, OR
- Exclusively manufactured and distributed for use in a hotel setting
This requirement includes, but is not limited to, preserving data between YouTube application sessions, during firmware and similar software updates, and after hard or soft power cycles.
5.4 The target device MAY duplicate locally stored data across an additional one or two internal physical memory banks. In that case, the firmware in the target device MUST reference the secondary or tertiary local storage if the primary or secondary unit, respectively, fails.

6 Networking

6.1 The target device MUST support HTTPS/SSL.
6.2 The target device MUST include the roots.pem certificate file available at http://pki.google.com/roots.pem and MUST have the ability to update trusted Roots.

7 Connected devices

7.1 The target device MUST implement one of the following Connected Device solutions:
- If the target device:
  - has a proprietary Connected Device solution, AND
  - that solution is deployed on the partner’s proprietary operating system, AND
  - that solution has been approved by YouTube, AND
  - that solution is deployed on 1 Billion or more devices (across mobile and Living Room devices)
  THEN YouTube will consider the target device's alternative Connected Device solution.
- If the conditions for using a proprietary Connected Device solution are not met, then the target device MUST implement DIAL protocol version 2.2.1 in production and enable it by default in the field, unless device is
  - Exclusively manufactured and distributed for use in a hotel setting, AND does not support any other connected device protocols, OR
  - Technically incapable (i.e. Pay TV device running on a dedicated, secure network) of supporting DIAL or any other connected device protocols
  In either case, the device MUST implement DIAL for testing and certification purposes, but MAY disable DIAL in the field.

7.2 The target device MUST be able to parse arbitrary and multiple parameter values posted to the DIAL server's additionalDataUrl structure.

Wake-on-LAN

7.3 The target device MUST NOT advertise availability of DIAL Wake-On-LAN functionality if either of the following conditions are true:
- The target device does not have a display, OR
- The target device is always on.
7.4 The target device MUST implement the DIAL Wake-On-LAN functionality described in Section 7 of the DIAL protocol version 2.2.1 if all of the following conditions are true:
- The device features a display; that is, it is not connected to a display via an HDMI or other wired connection, AND
- The device is intermittently active; that is, it is not always on, AND
- DIAL is the primary Connected Device protocol required on the device
7.5 The WAKEUP SSDP header in the M-SEARCH response to the DIAL client(s) MUST include a Timeout parameter as defined in section 5.2.1 of the DIAL protocol version 2.2.1.
7.6 The target device MAY disable Wake-On-LAN if located in a market region where regulations for power management for devices on standby apply.
- 7.6.1 If Wake-Up is disabled by default in a regulated market, the target device MUST provide the user with an option to enable this functionality during the setup flow and subsequently in the device settings.

Wake-up loading time

7.7 The target device MUST be able to load the application in 25 seconds, measured from the time the user initiates Wake-up to the time the video content begins playback.
7.8 The target device MUST implement the out-of-box experience requirements described in Section 9 of the DIAL 2.2.1 protocol.
7.9 The target device MUST have a default configuration that enables discovery of its DIAL server by other devices.
7.10 The target device MUST be discoverable via DIAL—that is, the DIAL server MUST be active—by the time the target device is in its active and ready-to-use state.
- 7.10.1 The Device Description included in the SSDP response MUST include the friendlyName, manufacturer and modelName fields.
- 7.10.2 The manufacturer and modelName fields in the Device Description MUST match the Brand and Model fields specified in Section 4.2.1 of this specification.
- 7.10.3 A 200 OK HTTP response from the target device to a DIAL client discovering information about an application MUST include the state element.
  - 7.10.3.1 If the DIAL server hosted by the target device returns a state value equal to installable, the URL parameter MUST be a valid reference to a location where the YouTube application can be retrieved.
7.11 The target device MAY provide the user with an option to disable the DIAL server on the device.
7.12 The target device’s DIAL server MUST NOT accept connections from the Default Gateway on the local subnet.
7.13 The target device MAY support the system application defined in Section 8 of the DIAL 2.2.1 protocol specification.
7.14 The target device MUST support CORS as outlined in Section 6.6 of the DIAL 2.2.1 protocol specification, with the additional requirement that the target device MUST reject all requests to the DIAL server where the ORIGIN header is not present.
- 7.14.1 If the user is using DIAL to launch a YouTube application, the ORIGIN header MUST match https://*.youtube.com or package:*.

8 Remote Keys and Key Events

Remote keys

8.1.1 The target device MUST support the following functionality and events for remote control buttons:
- 8.1.1.1 The target device MUST support six-point navigation at a minimum, which includes the keys identified in the remote keys table as part of 8.1.1.1. The platform MUST generate the appropriate kSbEventTypeInput events for key presses and releases.
- 8.1.1.2 The target device MUST support the keys indicated in the remote keys table as part of 8.1.1.2 if the keys exist on the device remote. The platform MUST generate the appropriate kSbEventTypeInput events for key presses and releases.
- 8.1.1.3 The target device MUST support the keys indicated in the remote keys table as part of 8.1.1.3 if the keys (i) exist on the device remote, and (ii) are not reserved for device or system functions. The platform MUST generate the appropriate kSbEventTypeInput events for key presses and releases.
8.1.2 Device remote keys not implemented by the YouTube application or reserved for device system functions MUST NOT dispatch any key event or key code.
8.1.3 Devices that implement a system-wide "exit" key MUST use that key to gracefully exit the YouTube application.
8.1.4 Devices MUST implement the Cobalt Application Lifecycle APIs (https://cobalt.googlesource.com/cobalt/+/refs/heads/master/cobalt/doc/lifecycle.md).
8.1.5 The target device MUST inform the app when a key is held down:
- 8.1.5.1 A Window.keydown event MUST be sent after a key is held down for 500ms, and a subsequent Window.keydown event MUST be sent every 50ms until the user stops holding the key.
- 8.1.5.2 A Window.keyup event MUST be sent after a key is released.
- 8.1.5.3 The target device MUST send the key-held-down interaction (repeated keydown event) if the app is in the foreground and MUST NOT use it to initiate a different action on the device.
8.1.6 The device MAY dispatch the following key events, as appropriate:
- Window.keypress
8.1.7 If the target device features a touch screen display, the device MAY implement the tap action corresponding to any of the key events listed in section 8.1, but it MUST NOT implement other custom events (e.g., swipe actions).

IR code for launching application

8.2.1 The target device MAY register and respond to an IR code dedicated to launching each YouTube application available on the device.
- 8.2.1.1 If this functionality is supported, a separate IR code MUST be assigned to each YouTube application, and the IR code MUST be supported regardless of whether the remote control distributed with the device at point-of-sale features a dedicated YouTube application hardware button.
- 8.2.1.2 If this functionality is supported, the IR code when received MUST directly launch the corresponding YouTube application and bring it to the foreground, including taking any necessary steps to achieve this, such as powering on the device or issuing a command to switch input over CEC.
- 8.2.1.3 If this functionality is supported, when the app is launched using this IR code, the deep link query parameter launch=remote MUST be included in the URL. See the URL query parameter table for more details.

9 Rendering

Rendering Requirements for YouTube Application rendered in Full Screen and Partial Screen

Devices must comply with all of the following requirements any time a YouTube application is in the foreground. For clarity, these requirements apply regardless of whether the YouTube application is in fullscreen mode or if it is sharing the screen with other applications, system notifications, or other content.

9.1.1 The target device MUST always render and composite all YouTube application elements correctly.
9.1.2 The target device MUST always display the YouTube application in fullscreen mode when it is started from any of the launch points on the device—for example, App icon, voice, remote button, search, etc.

9.1.3 The target device MUST be capable of rendering the YouTube application interface at one of the following supported resolutions:

Target Device is <= FHD		Target Device is > FHD
Video Resolution (Horizontal x Vertical dimension)	Minimum Render and Display resolution (Horizontal x Vertical dimension)	Video Resolution (Horizontal x Vertical dimension)	Minimum Render and Display resolution (Horizontal x Vertical dimension)
Up to 1280x720	At least 1280x720	Up to 1920x1080	At least 1280x720
		Greater than 1920x1080 and Up to 2560x1440	At least 1920x1080
		Greater than 2560x1440 and Up to 7680x4320	At least 1920x1080

9.1.4 If the target device is set to operate in HDR mode, it MUST be capable of rendering the YouTube application interface correctly, independent from the color primaries and transfer function of the HDR video being played. More specifically, any SDR UI element needs to be converted to the corresponding luminance and chrominance values in the new extended luma and color system used by the display. The resulting sample values are rendered into an HDR surface that is compatible with the HDR display mode currently selected on the target device.
9.1.5 The target device MUST implement the following property:
- window.devicePixelRatio, including the following configuration requirements:
  - 9.1.5.1 If the target device’s video decode capability is less than or equal to 1920x1080, the value of this property MUST be one of the following:
    - 1
    - 1.5
  - 9.1.5.2 If the target device’s video decode capability is greater than 1920x1080 and less than or equal to 3840x2160, the value of this property MUST be one of the following:
    - 1
    - 1.5
    - 2
  - 9.1.5.3 If the target device’s video decode capability is greater than 3840x2160, the value of this property MUST be one of the following:
    - 1
    - 2
    - 4
9.1.6 The target device MUST implement the Starboard API that provides full physical screen diagonal in inches. If the display is connected via HDMI, the display physical dimensions should be determined from EDID data.
- 9.1.6.1 If the device does not have a display panel and is not connected to a display panel such as a projector, the device must report the most common or optimal screen diagonal value in inches.

Rendering Requirements for YouTube applications rendered in Partial Screen

9.2.1 Partial screen rendering: General requirements

Devices must additionally comply with all of the following requirements any time that a YouTube application appears on the screen but is not in fullscreen mode:

9.2.1.1 Even if YouTube does not occupy the full screen—for example, settings or notifications are displayed on the screen—the target device MUST still meet all requirements that apply when YouTube does occupy the full screen. For example, DRM requirements still apply in all of the scenarios described in this section (9.2).
- 9.2.1.1.1 If the YouTube application is rendered in Non-overlapping window mode then the following exceptions apply:
  - The target device MAY support concurrent video playback.
9.2.1.2 The target device MUST NOT change the original aspect ratio of the video playback.
9.2.1.3 When the YouTube application is in the foreground and an overlay is on the screen, the target device SHOULD provide a way for users to dismiss the overlay window with a single-tap action.
9.2.1.4 The target device MUST NOT pause YouTube playback unless windows are being moved or resized.
- 9.2.1.4.1 The target device MUST resume YouTube playback automatically once the windows have been resized or moved.
9.2.1.5 If the target device implements any of the capabilities (except for critical system updates, system components) described in section 9.2, the device SHOULD provide a mechanism for YouTube to trigger the capabilities or notifications for testing purposes.

9.2.2 Partial screen rendering: Reporting capabilities

9.2.2.1 The target device SHOULD report Max Decode Resolution, Max Decode Frame Rate and DRM capabilities when the YouTube App is running, regardless of whether the video is playing in partial screen mode or full screen mode.
9.2.2.2 As described in 3.1.3, if the visual focus changes from the YouTube application to an overlay then the target device MUST send the focus on/off signal; this applies to all overlays.
9.2.2.3 The target device SHOULD inform YouTube of the status of audio on the device (i.e. YouTube audio playing, audio muted, YouTube audio mixed with other audio) with relevant Starboard APIs (when available).
9.2.2.4 If the target device supports Picture-in-Picture, Non-overlapping windows, Healths stats panel or Other notifications then MUST comply with one of the following options:
- 9.2.2.4.1 The target device SHOULD provide an API and integrate with relevant Starboard APIs (when available) to enable YouTube to retrieve the values for various properties of the window in which the YouTube application is rendered and of any components overlaid on top of the YouTube application; those properties are listed in the implementation details for this section. OR
- 9.2.2.4.2 If the overlay on top of the YouTube application is less than 12% of the screen size then the target device SHOULD instead provide an API and integrate with the relevant Starboard API (when available) to enable YouTube to mark regions in the screen where the platform MUST NOT show an overlay. The target device MUST also inform YouTube of the presence of an overlay.

9.2.3 Partial screen rendering: Picture-in-picture

The following requirements apply if the device supports Picture-in-picture functionality:

9.2.3.1 The target device MUST NOT launch an overlay except in response to an express user action that justifies or requires that overlay.
9.2.3.2 The target device MAY overlay a single video playback source in a small window over the YouTube application.
9.2.3.3 The target device MAY overlay YouTube in a small window when another source is running in fullscreen mode.

9.2.4 Partial screen rendering: System components and critical system notifications

The following requirements apply if the target device supports overlaying system components, such as a settings menu, or critical system notifications, such as system updates:

9.2.4.1 Critical system notifications MUST only include notifications that require user attention such as system updates or system error messages.
9.2.4.2 The target device MUST automatically dismiss critical system notification overlay windows after a short duration of time.
9.2.4.3 The user MUST explicitly initiate System Component overlay windows.
9.2.4.4 System component and critical system notification overlay windows MUST NOT contain any form of advertisements, content recommendations, or promotions.
9.2.4.5 System component and critical system notification overlay windows MUST NOT take the user outside of the YouTube application unless explicitly requested by the user.

9.2.5 Partial screen rendering: Other notifications

The following requirements apply if the target device supports notification overlay windows from non-media services—for example, baby cameras or smart doorbells:

9.2.5.1 The notification MUST NOT contain any form of advertisements, content recommendations, or promotions.
9.2.5.2 The user MUST be able to disable such notifications.

9.2.6 Partial screen rendering: Health Stats Panel

The following requirements apply if the target device supports a health stats panel:

9.2.6.1 The target device MAY overlay a Health stats panel over the YouTube application when the YouTube application is running in fullscreen mode.
- 9.2.6.1.1 If the device overlays a Health stats Panel, that panel MUST only contain health-based data such as:
  - Heart rate
  - Steps
  - Oxygen level
  - Calories burned
  - Water consumption
- 9.2.6.1.2 The Health Stats overlay window MUST NOT contain any form of advertisements, content recommendations, or promotions.
- 9.2.6.1.3 The Health Stats overlay window MUST NOT take the user outside of the YouTube application.

9.2.7 Partial screen rendering: Non-overlapping windows

The following requirements apply if the target device supports non-overlapping windows:

9.2.7.1 The target device MUST limit the windows for media sources to a maximum of 5.
9.2.7.2 The user MUST explicitly initiate non-overlapping window mode and configure the source of each of the windows.

Ambient mode and Screensaver

The following requirements apply if the device supports ambient mode or screensaver:

9.3.1 The target device MAY show system screensavers or ambient mode on top of the YouTube application screen AND/OR enter a power down or power savings mode when the application is inactive for the system-wide timeout duration.
- 9.3.1.1 YouTube MUST be considered active if the media player is in active use (e.g. video, audio, gameplay, screensaver, metaverse), or if the user is interacting with YouTube.
- 9.3.1.2 If a user does not interact with the device for a system-wide, extended duration of inactivity, AND the device uses this extended period of inactivity to enter power savings or power down mode, then the target device MAY show a prompt to the user to interact (e.g press a remote button) with the target device. If the user does not interact with the device then the device MAY enter a power down or power savings mode; the device MUST NOT enter screensaver mode. However if the user interacts with the device then the device MUST NOT enter a power down or power savings mode.
9.3.2 If the device enters ambient or screensaver mode when the YouTube application is in the foreground then the Device MUST return YouTube to the foreground after exiting any ambient or screensaver mode.

10 High Dynamic Range

10.1 The device MUST indicate that it supports the eotf additional mime type parameter with all of the following values:
- bt709: indicates ITU-R BT.1886 support
- smpte2084: indicates SMPTE 2084 EOTF support
- arib-std-b67: indicates ARIB STD-B67 support
10.2 The device MUST correctly display content for the following EOTF values:
- kSbMediaTransferIdBt709
- kSbMediaTransferIdSmpteSt2084
- kSbMediaTransferIdAribStdB67
10.3 The device MUST accurately support the Rec. 601, Rec. 709, and Rec. 2020 color spaces.
10.4 The device MUST produce subjectively acceptable visual behavior across input covering the full gamut of Rec. 2020.
10.5 The device MUST respect and properly decode explicitly-signaled color spaces; if no color space is signaled, the device MUST default to Rec. 709.
10.6 If the device has an HDMI output, the device MUST propagate the HDR metadata for the YouTube video into HDMI infoFrames.

Post-Processing

10.7 Any post-processing technologies MUST NOT produce noticeable artifacts.

11 Concurrent video playback

11.1 The target device MUST support concurrent playbacks of two video elements while meeting the following conditions on video decoding capabilities:
- 11.1.1 The target device MUST be able to decode two video streams concurrently:
  - 11.1.1.1 One video stream MUST be decoded at the maximum decoding resolution associated with the category to which the target device belongs.
  - 11.1.1.2 The second video stream MUST be decoded through H.264 Main Profile, 240p @ 15 frames/sec video bitstreams.
  - 11.1.1.3 The second video stream SHOULD be decoded through H.264 Main Profile , 480p @ 30 frames/sec video bitstreams with software-based DRM (at minimum) or hardware-based DRM (preferred) on the second stream. The DRM protocol MUST follow the guidelines listed in section 15 (Media Source and Encrypted Media Extensions) of this document.
  - 11.1.1.4 If the device supports concurrent video streams that play in non-overlapping windows—that is, multiple windows can concurrently play streams on the device—then the device SHOULD be capable of decoding all video streams with H.264 High Profile at 720p @ 30 frames/sec video bitstreams using hardware-based DRM on all streams. The DRM protocol MUST follow the guidelines listed in section 15 (Media Source and Encrypted Media Extensions) of this document.
11.2 When the target device is playing multiple streams concurrently, the display mode MAY be set to SDR so that all concurrent video streams share the same chromaticity and luminance transfer function.

12 Video Resizing

12.1 The target device MUST be able to dynamically resize all video layers to arbitrary sizes.
12.2 The video and UI MUST be synchronized within the following margins:
- The maximum lag/advance MUST be less than 100ms.
12.3 The video playback MUST continue playing at 30fps or more for at least 75% of the transition time and the UI frame rate MUST remain above 27fps.

13 HTMLMediaElement properties

13.1 The target device MUST implement the following HTMLMediaElement properties for the main video playback:
- HTMLMediaElement.currentTime, including the following configuration requirements, which are applicable whether the video features a standard frame rate or a high frame rate:
  - 13.1.1 The value of currentTime MUST be accurate to within 250 milliseconds during active playback.
  - 13.1.2 The value of currentTime MUST be accurate to within 100 milliseconds when content is paused.
- HTMLMediaElement.playbackRate
  - 13.1.3 The target device MUST support the following property values: 0.25, 0.50, 0.75, 1.00, 1.25, 1.50, 1.75, 2.00.
  - 13.1.4 Audio MAY be muted when this property's value is 0.25.

14 App and Playback Performance

General performance requirements

14.1.1 The target device MUST be able to correctly parse, decode, and display video content at arbitrary aspect ratios, variable bit rates, and variable frame rates up to a maximum of 120 frames per second for all output resolutions that the device supports.
- 14.1.1.1 If the target device supports Picture in Picture as per Requirement 9.2.3.3 then it MAY reduce the output resolution of the smaller window to a minimum of 480p.
- 14.1.1.2 If the target device supports Non-overlapping window as per Requirement 9.2.7 then it MAY reduce the output resolution to a minimum 1080p.
14.1.2 The UI frame rate MUST be equal to or greater than 30fps for 95% of the time.
14.1.3 The target device MUST be able to synchronize audio and video content at all times. Specifically, audio rendering MUST remain within a [-125ms , 45ms] range of the corresponding rendered video frame.
14.1.4 Subject to the conditions laid out in section 15.1 (DRM), the target device MUST implement the Widevine CDM getMetrics() API and forward all data retrieved with that API to the Cobalt Starboard API through the SbDrmGetMetrics() function in the Starboard DRM module.
14.1.5 The target device MUST support audio-only playbacks in both AAC and Opus stereo under the video element.
14.1.6 If the target device supports 360 video transform, then the target device MUST implement the CSS Spherical Filter Extension for hardware-accelerated rendering of spherical videos.

Multi-app environment

14.2.1 The target device MUST be able to maintain YouTube application responsiveness as required in Section 14 when device system functions are used over or alongside the YouTube application.
14.2.2 The performance of the target device MUST meet all the performance criteria specified in Section 14 upon resuming or re-launching the YouTube Application after running other applications during a user session.

Loading and App start time

14.3.1 If the YouTube app is pre-loaded in the target device, the target device MUST be able to resume (aka warm start) the YouTube application within 5 seconds, measuring the 95th-percentile duration value.
14.3.2 If the YouTube app is not pre-loaded in the target device, the target device MUST be able to load (aka cold start) the YouTube application within 9 seconds, measuring the 95th-percentile duration value.

Latency on User Input

14.4.1 Remote latency MUST NOT exceed 150 milliseconds.
14.4.2 Event Handling and Initial Animation latency MUST NOT exceed 200 milliseconds.

Transition times

14.5.1 The target device MUST be able to complete a browse-to-watch transition in the YouTube application within 1.5 seconds, including a nominal network transfer time of 0.3 seconds. The measurement represents the median value resulting from at least 150 runs of measuring the duration from the time the Browser receives the event that corresponds to a video or channel selection to the time that the selected video content begins playback.

Connectivity

14.6.1 The target device MUST be able to maintain video playback continuously for 12 hours without network disconnections or interruptions on all network interfaces, including Wi-Fi wireless networks.

Overall endurance

14.7.1 The target device MUST be able to endure 12 hours of key input stress test.

15 Media Source and Encrypted Media Extensions

15.1 The target device MUST implement one of the following DRM mechanisms:
- If the target device:
  - has a proprietary DRM mechanism, AND
  - that mechanism is deployed on the partner's proprietary hardware, AND
  - that mechanism is studio approved, AND
  - that mechanism is available on 1 Billion or more devices (across mobile, PC, and Living Room devices)
  THEN YouTube will consider supporting the target device's alternative DRM mechanism (Option A).
- If the conditions for using a proprietary DRM mechanism are not met, then the target device MUST implement Encrypted Media Extensions W3C Candidate Recommendation 18 September 2017 for the com.widevine.alpha key system CE CDM 16.3 or greater and OEMCrypto version 16.3 or greater (Option B). All subsequent requirements in section 15.1 apply only to the use of Option B.
Note: All subsequent requirements in section 15.1 apply only to the use of Option B in requirement 15.1.
- 15.1.1 The key system(s) implemented by the target device MUST support key rotation such that the key system(s) supports a minimum of sixteen (16) MediaKeySession objects, and each MediaKeySession object supports a minimum of sixteen (16) keys.
- 15.1.2 Devices that implement Widevine MUST support subsample encrypted block format for all encrypted WebM VP9 streams.
- 15.1.3 The isTypeSupported method MUST support the cryptoblockformat mime-type parameter, and MUST support subsample as a parameter value.
- 15.1.4 The MediaKeySystemMediaCapability dictionary passed to the navigator.requestMediaKeySystemAccess method MUST support the encryptionScheme key being set to cbcs.
- 15.1.5 The value of the Widevine company_name field provided by the device’s key system(s) MUST match either the value of the Brand or the System Integrator field defined in Section 4 (Device Identification and Configuration) of this specification.
- 15.1.6 The value of the Widevine model_name field provided by the target device's key system(s) MUST match either (i) the value of the model field defined in Section 4 (Device Identification and Configuration) of this specification OR (ii) the model name assigned by the Corporate entity responsible for submitting the device to YouTube certification and maintaining and updating the device.
- 15.1.7 The values of the company_name and model_name fields assigned to target devices that share the same device series name MUST correspond to a unique youtube_cert_scope value as defined in Section 4 (Device Identification and Configuration) of this specification.
- 15.1.8 Devices that implement Widevine MUST implement Widevine Level 1 content protection with secure hardware decode.
- 15.1.9 The key system(s) implemented by the target device MUST support decoding of all content resolutions, bitrates, codecs, and container formats that the device supports.
15.2 The target device MUST properly implement Media Source Extensions W3C Candidate Recommendation 17 February 2022 (or latest version), including the following configuration requirements:
- 15.2.1 SourceBuffers MUST be able to hold three media segments.
- 15.2.2 Media playback MUST begin if at least 0.5 seconds of media has been appended.
- 15.2.3 Media playback MUST begin within 0.5 seconds of sufficient data for playback being appended.
- 15.2.4 Before the end of stream is signaled, media playback MUST continue until no more than 0.5 second of the appended media remains unpresented.
- 15.2.5 After the end of stream is reached, media playback MUST continue until all media is presented.
- 15.2.6 The isTypeSupported method MUST support the VP9 Codecs Parameter String as specified at https://www.webmproject.org/vp9/mp4/#codecs-parameter-string.
- 15.2.7 The isTypeSupported method MUST support the AV1 Codecs Parameter String as specified at https://aomediacodec.github.io/av1-isobmff/#codecsparam.
- 15.2.8 The isTypeSupported method MUST accept and return correct values for the following additional parameters:
  - width: The decoded video resolution of the x axis in pixels.
  - height: The decoded video resolution of the y axis in pixels.
  - framerate: The decoded video frame rate in frames per second.
  - bitrate: The encoded video bitrate in bits per second.
  - channels: The number of absolute audio channels.
  - cryptoblockformat: The supported encrypted block format.
  - decode-to-texture: The target device uses this parameter to report about its capability to decode a video into a texture that will subsequently be processed by the target device’s Graphic Processing Unit(s) - GPU—for example, to perform spherical or 3D-to-rectangular projections.
    - The parameter value MUST either be true or false, and the default value is false.
      - When the parameter is set to true, the value of the other parameters in the method are scoped to the capability of the GPU and graphics library.
      - When the parameter is set to false, the value of all other parameters in the method reference the capability of the conventional rectangular display unit.
    - The method MUST trivially return false whenever the parameter value is not equal to true or false—for example, the method MUST return false if the parameter value is set to invalid.
    - When the parameter is not present, its value MUST be assumed to be equal to false.
- 15.2.9 If the target device supports HDR, it MUST implement the eotf parameter, which specifies the supported electro-optic transfer function, as defined in Section 10 (High Dynamic Range) of this document.
- 15.2.10 The values that the isTypeSupported method reports MUST represent the maximum capability that the combined video decoding, rendering, and display system can deliver.
- 15.2.11 YouTube EXPECTS the 2024 Software Certification Documentation to require that the target device MUST properly implement any Media Source Extensions W3C working draft or final specification that is current at the time of release. YouTube EXPECTS to require that the changeType() support MUST be supported for all formats on non-encrypted playbacks. For clarity, the target device MAY follow this requirement in 2023.
15.3 The target device MUST properly implement the Media Playback Quality APIs defined at https://wicg.github.io/media-playback-quality/; playback accuracy MUST NOT drop below 99% accuracy for any 5-second period of the playback.

16 Voice

General voice requirements

16.1.1 If the target device supports any form of microphone – for example, near field microphone, far field microphone – the target device MUST comply with the requirements defined in this section, and MUST comply with the requirements laid out in Section 6 of the Hardware Voice Capture Requirements section.
- 16.1.1.1 The device MUST support voice commands using at least one of the methods—device assistant support or direct microphone access support—described in sections 16.2 and 16.3.
- 16.1.1.2 Devices MAY implement both methods for supporting voice commands, using different methods for handling those commands in different use cases.
- 16.1.1.3 Devices SHOULD support direct microphone access when (i) the user is on the YouTube search page, and (ii) the user initiates a voice command using a remote control button (hard mic).

Device assistant requirements

16.2.1 All voice assistant systems MUST comply with the requirements in 16.2 Device Assistants.

16.2.2 Any time a device routes a voice command to a YouTube application, it MUST open a YouTube URL in Cobalt.
- 16.2.2.1 The URL MUST contain URL parameters and values, defined in the implementation details section, that are set based on the content of the user's voice command.

Explicit User Intent

16.2.3 For voice commands that explicitly mention "YouTube", the device MUST
- Launch the specified YouTube app.
- Pass YouTube the user’s voice command for fulfillment.

YouTube Application in Foreground

The following requirements apply when (i) a device assistant handles and routes voice commands, and (ii) the YouTube application is in the foreground:

16.2.4 The device MUST pass to YouTube all music-related and video-related voice queries without any disambiguation. The following are the exceptions:
- 16.2.4.1 If the voice command matches an Exclusive TV Show or Movie AND the user has Paid Entitlement to the Exclusive TV Show or Movie then the device MAY route the user to the app.
- 16.2.4.2 If the voice command matches a TV show or movie (as defined in Voice Terminology section) AND the user has a Paid Entitlement to the TV show or movie then the device MUST route the voice command to YouTube for fulfillment, and the device MAY also display an overlay to allow the user to disambiguate the request.
- 16.2.4.3 If the voice command matches a Live TV channel AND the user has Paid Entitlement to the Live TV channel then Device MAY route the user to the Live TV channel.
- 16.2.4.4 If the voice command contains an app name, the query MAY be routed to that app if the users clearly indicates they intend to switch to another app; otherwise, the query MUST be passed to YouTube and MAY be disambiguated.
16.2.5 The device MUST support the following functionality and events for Voice Actions; refer to the table in the Implementation Details section for more information.
- 16.2.5.1 The device MUST route these Voice Actions to YouTube.
- 16.2.5.2 The device MUST route these media controls actions, and SHOULD use the respective Voice Action to pass the intent to YouTube, but MAY use the same methods used for passing non-voice media control actions, such as SbKeyMedia key-presses or MediaSession actions.
- 16.2.5.3 The device SHOULD route these Voice Actions to YouTube.
16.2.6 If the user is on the YouTube search page, the device SHOULD support direct microphone access and pass the raw audio stream of the user's voice command directly to YouTube as described in section 16.3.
- 16.2.6.1 If the device does not support softmic, all media-related queries while the user is on the search page MUST come to YouTube and MUST NOT be disambiguated.
16.2.7 Even though YouTube is in the foreground, the device assistant SHOULD continue to directly handle and fulfill non-media queries (as defined in the Voice Terminology section).

Direct microphone access requirements

16.3.1 The device MUST follow the requirements in this section (16.3 Direct Microphone Access) when the device sends voice queries to YouTube via direct microphone access.
16.3.2 The device MUST use YouTube’s mic permissions flow OR provide a one-tap, one-time flow to collect consent.
16.3.3 The device MUST fully implement the complete Starboard Microphone API (SbMicrophone API) (https://cobalt.dev/reference/starboard/modules/microphone.html), which means:
- 16.3.3.1 The API MUST be able to retrieve a list of available audio input devices, and each device that the API returns MUST support direct microphone access speech functionality without the need for additional hardware.
  - 16.3.3.1.1 The device MUST return the same list of available audio input devices on all pages of the YouTube application.
- 16.3.3.2 The device MUST support microphone input detection by Cobalt Core through the Starboard Microphone API.
- 16.3.3.3 The device MUST pass the raw audio stream of the user’s voice command to YouTube via the Starboard Microphone API (SbMicrophone API).
16.3.4 After initial consent is provided as described in 16.3.2, audio capture for every subsequent voice command MUST begin, without the user having to take additional action, as soon as the user presses the hard mic button or the software microphone icon in the YouTube application.
16.3.5 The device MUST NOT create persistent data storage for any of the microphone inputs available through the Starboard Microphone API.

17 Universal / Device Search

17.1 If the device renders device-level search results from one or more video-related or music-related content partners, the device MUST include YouTube as part of those results, in accordance with EITHER 17.3 OR 17.4.
17.2 If YouTube is the only app with results that are relevant to a device-level search, the device SHOULD route the search action directly to the YouTube app using appropriate deeplink query parameters.
17.3 If the device renders individual YouTube search results—for example, a shelf of YouTube search results—it MUST retrieve results from the YouTube Data API and display all results exactly as they are returned.
- 17.3.1 The device MUST display results in an accessible and dedicated YouTube container—such as a row, shelf, column, or section—as part of the main UI that the target device uses to present media results to the user.
- 17.3.2 The partner implementation MUST rank the container of YouTube results fairly—for example, based on popularity, user preferences, or frequency of use.
- 17.3.3 The search implementation MUST comply with the YouTube API Services Terms of Service.
17.4 If the device displays a YouTube app tile in device-level search results, the tile, when clicked or selected, MUST open a YouTube URL in Cobalt.
- 17.4.1 The URL MUST contain URL parameters and values that are set based on the content of the user's search query. Refer to the URL query parameters section for an example deep link.

18 URL query parameters

18.1 Any time a device loads a YouTube URL in Cobalt—for example, when launching a YouTube application or responding to a voice command—the launch parameter MUST be included in the URL, and the parameter value MUST be set to one of the values defined in the parameter table in the implementation details for this section.
18.2 Depending on the specific use case, YouTube URLs MUST include additional parameters to instruct the YouTube Main App to take a particular action once launched. The parameter table in the implementation details section defines additional URL parameters that YouTube supports and indicates when they are required or optional.

19 On-Screen Keyboard Support

19.1 The platform MUST NOT render any on-screen keyboard, unless YouTube triggers the keyboard.

20 Fonts

20.1 The device MUST be able to render normal weight, normal style, sans-serif fonts in languages that YouTube supports.
20.2 If the target device supports system languages with characters that are not included in the fonts that the YouTube application serves, the device MUST provide the YouTube application with system fonts containing those characters.
20.3 If the device does not provide a bold font for a requested language, then, when the YouTube application requests a bold font, the device MAY apply faux bold if it produces legible results. Otherwise, the device MUST NOT apply faux bold.

21 Accessibility

Support of Visual Impairment

21.1.1 If the target device supports high contrast settings, it MUST notify the YouTube application of any changes in the settings.
21.1.2 If the target device supports speech synthesis, such as Text-to-speech or other screen reader capabilities, then the target device MUST support platform-level settings to enable and disable that functionality and MUST notify the YouTube application of any changes in the settings.
21.1.3 If the target device supports audio description settings it SHOULD notify the YouTube application of any changes in the settings.
- Note: YouTube EXPECTS this to be a MUST requirement in SW 2025 requirements.

Support of Auditory Impairment

21.2.1 If the target device supports closed captions system settings, it MUST notify the YouTube application of any changes in the settings.

22 Device Maintenance

22.1 The target device MUST be able to receive and install firmware or similar software updates over a network connection automatically, and be configured to do so by default.

22.2 The target device MUST remain in compliance with subsequent Long-Term Support (LTS) versions of Cobalt as follows:

22.2.1 If the device is part of a Device Series in which one or more Derivative Models are Launched after 30 June 2024, then the device MUST be updated to the latest Cobalt LTS version at least once per year for a period of five calendar years, starting from and including the Certification Year.

22.2.1.1 Devices that must comply with requirement 22.2.1 MUST update their Starboard implementation at least once every other year for a period of five calendar years, starting from and including the Certification Year.

The following table identifies the requirements for updating Cobalt and Starboard on devices that must comply with requirements 22.2.1 and 22.2.1.1:

Deadline	Cobalt Version	Starboard Version
31 December 2023 (Certification Year)	Cobalt 23	Starboard 14
31 December 2024	Cobalt 24	Starboard 14 or 15
31 December 2025	Cobalt 25	Starboard 16
31 December 2026	Cobalt 26	Starboard 16 or 17
31 December 2027	Cobalt 27	Starboard 18

22.2.2 If the device is part of a Device Series in which all Derivative Models are Launched no later than 30 June 2024, then the device MUST be updated to the latest Cobalt LTS version at least once per year for a period of three calendar years, starting from and including the Certification Year.

22.2.2.1 Devices that must comply with requirement 22.2.2 MAY also update their Starboard implementation.

The following table identifies the requirements for updating Cobalt and Starboard on devices that must comply with requirements 22.2.2 and 22.2.2.1:

Deadline	Cobalt Version	Starboard Version
31 December 2023 (Certification Year)	Cobalt 23	Starboard 14
31 December 2024	Cobalt 24	Starboard 14 or 15
31 December 2025	Cobalt 25	Starboard 14 or 15 or 16

22.3 The requirements for the original device Certification Year MUST continue being met after the Cobalt runtime has been updated to the latest LTS version.

23 End-User Privacy

Confidentiality of User Data

23.1.1 The Partner MUST comply with all privacy laws and regulations, including as applied to Google's user data (e.g. end-user login information).
23.1.2 The Partner MUST NOT collect, use, maintain, or distribute any Google user data—for example, through Automated Content Recognition (ACR)—unless otherwise authorized in writing by Google.

Logging of Cobalt Data

23.2.1 Target device MUST log only Cobalt data to solve a user- initiated issue.
23.2.2 Target device MUST allow user to opt in to share this data.
23.2.3 Assuming requirements 23.2.1 and 23.2.2 are met, the target device MUST log only items that the Cobalt browser enables for logging.
23.2.4 In compliance with end-user privacy guidelines, partners MUST NOT retain these logs for a period longer than 30 days. For clarity, logs may still exist on a user's device after 30 days, but MUST be deleted from partners’ servers.

24 Testing

24.1 Devices SHOULD support the latest version of the Device Automation Bus (DAB) testing framework 1.0 or greater as defined at https://getdab.org. Note that YouTube EXPECTS this to become a MUST for 2024 SW requirements.

MAY to MUST requirements