DOCSEARCHbyAlgolia
Submit Docs

RxPlayer Documentation

repository·dev·Indexed 21 days ago

https://github.com/canalplus/rx-player

RxPlayer is a high-performance, highly configurable HTML5 media player engine for browsers, specializing in DASH and Microsoft Smooth Streaming. It features a multi-threaded architecture, robust adaptive bitrate heuristics (including BOLA), and complex DRM handling via EME. The engine focuses on streaming logic rather than UI, providing tools for adaptive representation selection, manifest fetching, and segment queue management across diverse environments including smart TVs and game consoles.

Tokens
144.3K
Snippets
374
Records
624
Agent score
75%

What's inside rx-player

  1. Overview of RxPlayer Main Thread modules

    dev

    The main_thread directory is composed of several specialized modules that manage the high-level orchestration of playback:

    • API (./api): Defines the public API and provides abstractions for implementation.
    • ContentInitializer (./init): Handles playback initialization and connects various modules.
    • ContentDecryptor (./decrypt): Manages content decryption negotiation for DRM-protected content.
    • CoreInterface (./core_interface): Provides a communication interface to the core logic (which may reside in a separate thread). Its behavior adapts based on whether the environment is mono-threaded or multi-threaded.
    • TracksStore (./tracks_store): Provides a simplified API for switching text, audio, and video tracks.
      • For contents played directly by the browser (via src on a media element), use the sister block MediaElementTracksStore (./tracks_store/media_element_tracks_store.ts).
    • TextDisplayer (./text_displayer): Manages subtitle rendering, supporting either HTML elements or native HTMLTrackElement (<track>) methods.

  2. Use standalone tools from the rx-player library

    dev
    The rx-player library exports various functions and classes as standalone tools that are not part of the main RxPlayer class. These tools are intended for use outside of the primary player instance for specific utility tasks.

  3. Explore RxPlayer documentation categories

    dev

    The RxPlayer documentation is organized into several categories to help you find specific information:

    • API Documentation: Detailed information about the available interfaces and methods located in the api/ directory.
    • Getting Started: Tutorials and essential resources for new users located in the Getting_Started/ directory.
    • API Reference: A consolidated single-page list of all available APIs located in the reference/ directory.
    • Static Resources: Images and other assets used within the documentation located in the static/ directory.

  4. Overview of the Tracks Store module

    dev
    The Tracks Store module is designed to facilitate selecting specific Adaptations/tracks and Representations/qualities via the RxPlayer API. It provides a simplified API that allows developers to make track selections using IDs, while the module handles the underlying technical complexities and specificities of the streaming logic.

  5. What is the StreamOrchestrator?

    dev

    The StreamOrchestrator is the central entry point in RxPlayer responsible for managing media playback data. Its primary responsibilities include:

    • Dynamic SegmentSink Creation: It creates various SegmentSinks (media buffers) based on the specific requirements of the content being played.
    • Orchestration: It manages the downloading and "pushing" of media segments to these sinks to ensure optimal playback conditions.

    In a multi-threaded environment, the StreamOrchestrator is designed to be runnable within a WebWorker.

  6. What is a MetaPlaylist transport

    dev

    A MetaPlaylist is a specialized transport type in RxPlayer that functions as a playlist of multiple Manifests. It allows the player to treat a sequence of different streaming manifests (such as DASH or Smooth Streaming) as a single continuous stream.

    How it works:

    • Manifest Merging: Each manifest in the playlist is downloaded and parsed using its native logic (e.g., MPD via DASH logic or Smooth Manifest via Smooth logic). These are then merged into a single unified Manifest object.
    • Period Mapping: To maintain the structure, each original manifest is treated as one or more Periods. If an original DASH manifest already contains multiple Periods, each of those is also converted into individual RxPlayer Periods to ensure no content features are lost.
    • Concatenation: The periods are concatenated sequentially based on the timing information provided within the MetaPlaylist JSON file.

  7. What is a MetaPlaylist?

    dev

    A MetaPlaylist (MPL) is a JSON-based format that allows you to define a content stream composed of multiple DASH or Smooth Streaming contents played sequentially.

    It is primarily used for:

    • Creating linear (live) content from VOD assets: Concatenating multiple non-linear contents to simulate a live stream without modifying the original files.
    • Binge-watching/Smooth transitions: Constructing a new non-linear sequence by concatenating multiple VOD contents for seamless playback between programs.

    Key advantages include support for multiple protocols (DASH/HSS) in one manifest, lazy-loading of original manifests, and simplified DRM management (e.g., different license servers per segment).

  8. Manifest Loader and Parser

    dev

    The manifest lifecycle involves two distinct steps:

    1. Manifest Loader: Downloads the Manifest/MPD file from a URL. It returns a Promise resolving to the raw loaded content (e.g., a string or a DOM Document).
    2. Manifest Parser: Converts the raw loaded content into the rx-player internal Manifest structure.

    Note on supplementary requests: The Manifest Parser can receive a scheduleRequest function. This allows the parser to perform additional asynchronous requests (like fetching the current time or sub-parts of a manifest) while benefiting from the player's error-handling and retry logic.

  9. How the Stream architecture works

    dev

    The Stream component is responsible for selecting the correct media segments to download and pushing them into SegmentSinks (media buffers) for decoding. It operates by monitoring playback conditions, current buffering levels, and requested track qualities to decide which segments to load.

    The architecture follows a hierarchical structure:

    1. StreamOrchestrator: The top-level entry point that manages the entire content by orchestrating multiple PeriodStreams.
    2. PeriodStream: Manages a single Manifest Period and a specific buffer type (e.g., 'audio', 'video', 'text'). It creates and destroys AdaptationStreams based on callbacks that determine which Adaptation to use.
    3. AdaptationStream: Manages a single Adaptation (e.g., a specific audio language or video track). It creates and destroys RepresentationStreams based on environmental factors like network bandwidth.
    4. RepresentationStream: The lowest level that performs the actual segment downloading, monitoring the buffer to deduce which segments are needed, and commanding the push to the SegmentSink.

  10. Understand time groups in RxPlayer

    dev

    RxPlayer manages various time-related values by categorizing them into two distinct groups based on whether they use the offset or not:

    1. The manifest group (Non-offset)

    Uses the raw mediaTime from the manifest. This group is primarily used by the transports code for segment requests.

    • mediaTime: The time defined in the segment.
    • manifestTime: The time as announced in the manifest.
    • requestSegmentTime: The time specified in the segment request.

    2. The real time group (Offset)

    Uses the presentationTime (the time including the offset). This group is used by almost all other parts of the player.

    • presentationTime: The time displayed in the HTMLMediaElement.
    • playerTime: The time used in the RxPlayer Segment Object.
    • bufferedTime: The time used in the buffered APIs of an HTMLMediaElement or SourceBuffer.

  11. Support DRM in local manifests

    dev
    Content with DRMs can be supported in local manifests as long as the encryption information is included in the corresponding containers (for example, PSSH boxes in mp4 or other ISOBMFF containers). Supplementary encryption information in the local manifest format is currently under development and not yet available.

  12. Understand the Core Entry modes: Monothreading vs. Multithreading

    dev

    The core entry point supports two operational modes that dictate how you should import and use the library:

    1. Monothreading mode: You can directly import files from the core directory to establish a link with the core code. This is useful for tasks like loading and pushing segments directly.
    2. Multithreading mode: The core is designed to be runnable entirely within a WebWorker. In this mode, external code should not import files from the core directory directly. Instead, you should only interact with the CoreEntry to generate the worker bundle.