Introduction

This topic describes the NaCl Player, including its architecture overview and playback scenarios.

Related Info

The NaCl (Native Client) Player API allows you to build a fully-featured VOD or multimedia player. You can use the API for multimedia playback control and handling low-level media stream operations.

By using the NaCl technology and the NaCl Player API, you can take advantage of the following features:

  • You can create a custom media playback application in situations where it is not possible to use JavaScript APIs, such as the AVPlay API, Media Source Extensions, or Encrypted Media Extensions.
  • You can use custom content downloaders and demuxers, allowing you to support a variety of multimedia formats.
  • You can implement custom DRM systems in addition to accessing platform-supported DRM systems.
  • You can access fast C/C++ code and reuse existing native codebases.

The following figure shows the high-level structure layers of an application that uses the NaCl Player, and the relevant components within each layer:

  • The external data can be located in application storage, external storage, or a UDP or HTTP server.
  • The application has 2 components:
    • The Native Client module component uses the NaCl Player API to control multimedia playback.
    • The HTML5 component is responsible for user interaction. Its basic role is to communicate with the NaCl module.
  • The platform contains the player implementation:
    • The NaCl Player is called by the Native Client module. It is responsible for decoding packets, playing audio, and rendering video.

      Figure 1. High-level structure of a playback application

Playback Scenarios

The NaCl Player can handle playback in 2 ways, depending on the multimedia data source. For more information on the application logic for each scenario, see the Main Use Cases. You can also study how the common playback scenarios are implemented in Developing Playback Applications.

URL Source

In this scenario, the platform handles all the playback-related logic, including downloading and demuxing content. The application's role is to set the content URL and control playback.

The following figure shows the control and data flow for URL source playback using the NaCl Player.

Figure 2. URL source scenario

Implementing URL source playback requires the following steps:

  1. Create a media player and custom event listener objects.
  2. Create a URLDataSource object and configure it for a specific content URL.
  3. When the NaCl Player notifies that buffering is complete, start playback.

Elementary Stream Source

In this scenario, the Native Client application is responsible for downloading and demuxing content. The demuxed content is sent as elementary stream packets to the platform for playback. You can also implement platform-supported or custom DRM decryption, and external subtitles.

The following figure shows the control and data flow for elementary stream source playback using the NaCl Player.

Figure 3. Elementary stream source scenario

Implementing elementary stream source playback requires the following steps:

  1. Create the media player and custom event listener objects.
  2. Create an ESDataSource object and configure it to handle multiple elementary streams.
  3. Optionally, configure the platform-supported DRM.
  4. Send demuxed elementary stream packets to the NaCl Player.
  5. When the NaCl Player notifies that buffering is complete, start playback.
  6. To continue playback, continue sending elementary stream packets for buffering.

Playback Terminology

Familiarize yourself with the following playback-related terminology before working with the NaCl Player API.

Term Definition
Adaptive streaming A streaming technology that adapts to changing network connection conditions between the server serving content and the client consuming the content. Adaptive streaming can be divided into 2 types:
  • Client-side, where the server provides multiple representations for the same track (video or audio), usually differing by resolution or sampling and encoding quality. The client selects the content representation most suitable for the current network conditions. Examples of client-side adaptive streaming protocols are HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (DASH).
  • Server-side, where the server monitors the network conditions and provides the most suitable content representation to the client. An example of a server-side adaptive streaming protocol is the Real Time Streaming Protocol (RTSP).
Codec A scheme describing the transformations used to compress and decompress video or audio data. Compression is usually lossy. Examples of codecs are AVC (H.264/MPEG4) and HEVC (H.264) for video, and AAC and MP3 for audio.
Container (or media container) An entity containing interleaved (multiplexed) encoded multimedia data and metadata describing the media streams and how to access them. An example of a container is ISO BMFF, described in the ISO 14496-12 standard and often called "MP4".

A container consists of:
  • Metadata describing the container itself, and the number and types of elementary streams it contains
  • 1 or more elementary streams, each containing:
    • Metadata describing the stream, such as video resolution and frame rate, audio sampling rate and number of channels, and other codec-specific data needed to decode the content
    • Packets containing synchronization information (such as PTS, DTS, and duration), optional decryption information, and frame or sample data (clear or encrypted)

DTS (decode timestamp) A relative timestamp specifying when the packet must be decoded in order to present the decoded output on time.
DRM (digital rights management) A technology protecting content from being copied and redistributed without authorization. It often involves encrypting the encoded multimedia data and an infrastructure that securely delivers the decryption key to the authenticated and authorized user. An example of DRM technology is Microsoft PlayReady.
Elementary stream An entity that contains only 1 type of encoded multimedia data.
Encoded data Audio or video data that has been compressed using a codec.
Frame Raw video data which can be rendered on the screen.
Key (or cryptographic key) A cryptographic entity which can be used to decrypt data.
License A set of keys associated with multimedia content, containing policies regulating its use. The license structure and details are DRM-specific.
Packet An encoded data block forming a single frame or sample with timing information, such as the PTS and DTS. The packet can also contain information necessary to decrypt it, such as the key.
PTS (presentation timestamp) A relative timestamp specifying when the decoded data is to be presented during playback.
Sample Raw audio data which can be played on the speakers.
Track/stream representation A sequence of encoded data with timing information for a specific elementary stream, such as an English or Spanish audio track.

Table 1. Playback terminology