NaCl Player Introduction

An introduction to NaCl Player, including architecture overview and playback scenarios.

Architecture Overview

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

Usage of NaCl Player API and Native Client offers multiple benefits to the application:

  • possibility to create a custom media playback application when it is not possible to use Javascript APIs (e.g. AVPlay, MSE and EME);
  • ability to use a custom content downloader and demuxer, enabling support of any multimedia format used by content providers;
  • access to the platform-supported DRMs, as well as an ability to provide custom DRMs implemented by the application;
  • access to fast C/C++ code and an ability to reuse existing native codebase.
    The NaCl Player articles present how to use the NaCl Player API and provide a detailed use cases description and usage examples of the API. The guide is based on the reference application - Native Player.

To get basic information about NaCl and creating a basic NaCl application from scratch, please refer to the Getting Started with NaCl and How to Create a NaCl App articles. It is also suggested to see the Hello World in C++ article.

The NaCl Player Terminology page contains a description of the terminology used in the article and can be used as a reference.

The diagram below shows a high level structure of an application that uses NaCl Player:

The diagram is composed of the 3 main layers:

  • External Data - A place where media content is held (e.g. application storage, external storage, UDP or HTTP server).
  • Application - A Tizen widget which is run by end-user.
  • Native Client - A NaCl module which uses NaCl Player. Native Client can control multimedia playback, provide data downloading and demuxing functionality, etc.
    • HTML5 - Responsible for a user interaction. Its basic role is to communicate with NaCl module.
  • Platform - Contains the player implementation.
    • NaCl Player - Responsible for performing functions called by NaCl Module. NaCl Player is responsible for decoding packets, audio playback and video rendering.

Playback Scenarios

Two playback scenarios can be highlighted in NaCl Player, basing on the way a multimedia content is handled:

  • Elementary Stream (ES) data source scenario - a playback of the multimedia content is done using a custom, application-defined demuxer. Elementary Stream packets are passed to NaCl Player.
  • URL data source scenario - a playback of the multimedia content is done by passing a URL address of the content to NaCl Player.

A high level application structure and simplified data flow in both scenarios is presented and described below.

ES Data Source Scenario

In this scenario Native Client is responsible for downloading and demuxing content. Demuxed content is sent as elementary stream packets to Platform for a playback.

URL Data Source Scenario

In this scenario the whole playback-related logic is done by Platform. Platform is responsible for downloading and demuxing content. The only task of the application is to set a URL address to content and control the playback.

Reference Application Code

A code of the Native Player, the NaCl Player reference application, can be downloaded from here or found on GitHub.

The GitHub repository contains the newest version of the reference application code, however it is not guaranteed to accurately reflect code snippets presented in the Native Player Reference Application article. The version attached to this page is guaranteed to be compatible with them.

The reference application is available under a permissive MIT license and can be freely adapted to the user's need. It is designed to use a modular approach, so that various components (like a data demuxer) can be easily changed or replaced. More details regarding the reference application architecture is available on the Native Player Reference Application article.