rx-player 4.5.0-dev.2026033100 → 4.5.0-dev.2026041501

package/src/compat/__tests__/can_patch_out_pssh.test.ts

@@ -0,0 +1,40 @@
+import { describe, beforeEach, it, expect, vi, afterEach } from "vitest";
+import configHandler from "../../config";
+import canPatchOutPssh from "../can_patch_out_pssh";
+import EnvDetector, { mockEnvironment, resetEnvironment } from "../env_detector";
+
+describe("compat - canPatchOutPssh", () => {
+  beforeEach(() => {
+    vi.resetModules();
+  });
+  afterEach(() => {
+    vi.resetAllMocks();
+    resetEnvironment();
+  });
+
+  it("should return true if we are not on the DSTV Streama MDP 1001s STB", () => {
+    mockEnvironment(EnvDetector.BROWSERS.Other, EnvDetector.DEVICES.Tizen, false);
+    expect(canPatchOutPssh()).toBe(true);
+  });
+
+  it("should return false if we force it through the config", () => {
+    const oldConfig = configHandler.getCurrent();
+    vi.spyOn(configHandler, "getCurrent").mockImplementation(() => {
+      return {
+        ...oldConfig,
+        PREVENT_PSSH_PATCHING: true,
+      };
+    });
+    mockEnvironment(EnvDetector.BROWSERS.Other, EnvDetector.DEVICES.Tizen, false);
+    expect(canPatchOutPssh()).toBe(false);
+  });
+
+  it("should return false if we are on the DSTV Streama MDP 1001s STB", () => {
+    mockEnvironment(
+      EnvDetector.BROWSERS.Other,
+      EnvDetector.DEVICES.StreamaMdp1001S,
+      false,
+    );
+    expect(canPatchOutPssh()).toBe(false);
+  });
+});

package/src/compat/can_patch_out_pssh.ts

@@ -0,0 +1,53 @@
+import config from "../config";
+import EnvDetector from "./env_detector";
+
+/**
+ * When talking about `ISOBMFF`/.mp4 metadata, the `pssh` is a box (a subpart of
+ * that file) containing protection-related metadata that is then used to
+ * interact with EME APIs.
+ *
+ * The idea in EME scenarios is that the EME player (here the RxPlayer) will
+ * take that data and communicate it to the browser's CDM (Content Decryption
+ * Module) through an EME API (generally `generateRequest`).
+ *
+ * There is a mechanism in place in browsers, presumably to facilitate that work
+ * which is that when the browser sees a `pssh` box in media data (either linked
+ * directly through a media element's `src` attribute or one communicated
+ * through MSE API) it can send an `encrypted` event so a JS player can then
+ * communicate it to the right EME API.
+ *
+ * However, in an MSE/EME player, we often are distrustful of letting the browser
+ * do work that can without issue be already done on our side (due to being
+ * burned too much time on some weird environment, where the spec isn't respected
+ * to the letter). So instead historically in MSE scenarios, the RxPlayer read the
+ * `pssh` itself, and then "patched it out" (replaced it with a `free` box,
+ * effectively a no-op for ISOBMFF metadata) from the segment before giving it to
+ * the browser's buffer so that we skip that now unnecessary browser round-trip
+ * (the `encrypted` event) and supplementary API surface that could be broken.
+ *
+ * Several years pass without issue, but in early 2026, we found out that one
+ * device, a "Streama" STB from DStv (owned by Multichoice) refuse to bufferise
+ * segments which had this "optimization" performed.
+ * We have no idea why, from our POV it's an issue on the browser integration side.
+ * They don't disagree but they cannot update that part of their device easily.
+ *
+ * So we decided to fix it player-side. When discussing about it, we hesitated
+ * between removing that "optimization" altogether or only for the specific device
+ * where we identified the issue. I chose (though far from everyone agreed!) the
+ * second solution (only for problematic device) because I feared changing
+ * behavior too much compared to most of our previous versions could break
+ * other devices, even if we saw that some other players such as the
+ * shaka-player did not do that same optimization.
+ *
+ * @returns {boolean}
+ */
+export default function canPatchOutPsshBox(): boolean {
+  const { PREVENT_PSSH_PATCHING } = config.getCurrent();
+  if (
+    PREVENT_PSSH_PATCHING ||
+    EnvDetector.device === EnvDetector.DEVICES.StreamaMdp1001S
+  ) {
+    return false;
+  }
+  return true;
+}

package/src/compat/env_detector.ts

@@ -80,6 +80,8 @@ const DEVICES = {
   Xbox: 109,
   /** Another device that does not match with the others defined here. */
   Other: 110,
+  /** DSTtv's Streama STB MPD1001S, which is known to have some quirks. */
+  StreamaMdp1001S: 111,
 } as const;
 
 /** Interface giving information on the current environment where the RxPlayer runs. */
@@ -200,6 +202,8 @@ function resetEnvironment(): void {
     EnvDetector.device = DEVICES.PlayStation4;
   } else if (navigator.userAgent.indexOf("PlayStation 5") !== -1) {
     EnvDetector.device = DEVICES.PlayStation5;
+  } else if (navigator.userAgent.indexOf("DStv Streama, MDMP1001S") !== -1) {
+    EnvDetector.device = DEVICES.StreamaMdp1001S;
   } else if (/Tizen/.test(navigator.userAgent)) {
     EnvDetector.device = DEVICES.Tizen;
 

package/src/core/README.md

@@ -16,7 +16,7 @@ can optionally run in a WebWorker environment.
 
 Those modules are:
 
-- **the `Core Main` (\_./main)**
+- **the `Core Entry` (\_./entry)**
 
   Make the link between the "main thread" part of the code and the core.
 

package/src/core/adaptive/README.md

@@ -139,8 +139,8 @@ Bitrates (kb/s) |
 [2] The BOLA estimation is computed each time a segment is appended (thus buffer gap is
 updated).
 
-The RxPlayer has a mecanism that allows to replace low-quality buffered segments by higher
-quality ones if the current conditions improve. That leads to the buffer gap not
+The RxPlayer has a mechanism that allows it to replace low-quality buffered segments by
+higher quality ones if the current conditions improve. That leads to the buffer gap not
 increasing when a chunk is added. That could mislead BOLA, and cause oscillations between
 chosen qualities.
 
@@ -151,4 +151,4 @@ between segment duration and segment download time. If the score points that a q
 pick an upper quality. Conversely, when a quality may not be downloadable fast enough, the
 BOLA is "allowed" to decrease the estimated quality, and shall not decide to increase it.
 
-If no maintanaibility score is computed, then BOLA works the regular way.
+If no maintainability score is computed, then BOLA works the regular way.