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.
- The NaCl Player is called by the Native Client module. It is responsible for decoding packets, playing audio, and rendering video.
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.
Implementing URL source playback requires the following steps:
- Create a media player and custom event listener objects.
- Create a URLDataSource object and configure it for a specific content URL.
- 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.
Implementing elementary stream source playback requires the following steps:
- Create the media player and custom event listener objects.
- Create an ESDataSource object and configure it to handle multiple elementary streams.
- Optionally, configure the platform-supported DRM.
- Send demuxed elementary stream packets to the NaCl Player.
- When the NaCl Player notifies that buffering is complete, start playback.
- 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:
|
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:
|
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