RxPlayer Architecture documentation

Overview

The files in this directory and subdirectories establish a documentation about the RxPlayer’s architecture.

They are here to help you understand the way the player works, by describing the different bricks and algorithms that come into play.

Note: As some terms used here might be too foreign or slightly different than the one you’re used to, we also wrote a list of terms and definitions used by the RxPlayer here.

Organization of the documentation

The RxPlayer is heavily modularized.

This helps us maintaining the code and providing evolutions more quickly, as the various modules use few well-defined interfaces with the rest of the code. As such, the impact an evolution on a particular module has on the rest of the code is controlled and limited to these interfaces.

Like the code, the documentation is also divided in multiple parts, which link one by one to a module in the code.

Such modules are (with link to their respective documentation, if one):

• the API

  Defines the public API of the RxPlayer and provides abstractions to help implementing it.

• the Stream

  starts playing a content and connects the different modules between one another to allow continuous playback.

  Various files documenting the Stream architecture should be available in the doc/architecture/stream directory.

• the EMEManager

  Allows to handle contents with DRM (Digital Right Management).

• the ABRManager

  Helps to choose the best quality in the current content by analyzing the current network, user settings and viewing conditions.

• the Buffer

  Choose which segments to download and push them to the corresponding SourceBuffer.

  Various files documenting the Stream architecture should be available in the doc/architecture/buffer directory.

• the Source Buffers

  Provides abstractions on top of the SourceBuffers, which are used to push media segments. These files help to handle “native” SourceBuffers already defined by the browser (for audio and video segments), but also define custom ones for media managed entirely by the RxPlayer (example: subtitles and thumbnails).

• the Networking code

  Perform manifest/segment requests, and parse them. “net” in essence abstracts the transport protocol used (example: HSS/DASH) to provide an unified definition of a segment or manifest to the other modules. In theory, it should be the only directory to update when adding / modifying / deleting a transport protocol

  Various files documenting the Net architecture should be available in the doc/architecture/net directory.

• the Pipelines

  Link the Net module with the rest of the code, to download segments, download/refresh the manifest and collect data (such as the user’s bandwidth) for the other modules.

  Various files documenting the Stream architecture should be available in the doc/architecture/pipelines directory.

The RxPlayer also has multiple isolated helpers (for manifest management, segment parsing, browser compatibility) which are used by these different modules.

A documentation about the file organization of the project is also available here.