Samsung Tizen - Performance degradation when initiating long streams

What version of Hls.js are you using?

1.5.20

What browser (including version) are you using?

Chromium v56/63 (Tizen fork)

What OS (including version) are you using?

Tizen

Test stream

No response

Configuration

{
  backBufferLength: 30,
  enableWorker: true,
  highBufferWatchdogPeriod: 5,
  liveSyncDurationCount: 5,
  maxBufferLength: 30,
  maxMaxBufferLength: 60,
  nudgeMaxRetry: 10,
  workerPath: 'path/to/hls.worker.js'
}

Additional player setup steps

NOTE: I originally posted this issue on the video-dev/hlsjs Slack channel. I am copying a summary here for posterity, in the event others come across this problem.

Original Slack message (edited for clarity)

We maintain an application that runs on various devices, including Samsung Tizen TV's and other Smart TV's/STB's. After recently updating the HLS.js player from 1.1.5 to 1.5.x, I'm noticing a very long stream startup delay on 2018/19 devices (which use Chrome v56/63 respectively) as a result of the application being entirely locked up during this time, indicating an apparent cpu bottleneck.

The issue seems to be exacerbated when playing longer streams (~3-4 hours).

I've been able to narrow this issue down to the player getting bottlenecked when:

• Parsing a variant playlist and subtitle (VTT) manifest concurrently, or
• Parsing a variant playlist, then immediately ramping to a different variant and parsing a new playlist

It seems that the m3u8-parser is blocking the main thread whenever the player needs to parse multiple variants in sequence/concurrently.

Thread summary

• The issue occurs on all versions from 1.4.0 and higher.
• I've been able to pinpoint the bottleneck to the Fragment object creation in the level parsing block. The loop continues to execute, but becomes progressively slower during each iteration. This behavior, combined with all of the conditions seems to indicate a possible V8 optimization problem on these older devices.

Findings/solution

This issue occurs due to a combination of how Vite is bundling our client application, and older versions of the V8 engine having sub-optimal memory management and function de-optimizations when using the ESM version of this library. The solution in this case was to alias the UMD/ES5 version of the library in our Vite config:

resolve: {
  alias: {
    'hls.js': 'node_modules/hls.js/dist/hls.js'
  }
}

Checklist

• The issue observed is not already reported by searching on Github under https://github.com/video-dev/hls.js/issues
• The issue occurs in the stable client (latest release) on https://hlsjs.video-dev.org/demo and not just on my page
• The issue occurs in the latest client (main branch) on https://hlsjs-dev.video-dev.org/demo and not just on my page
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream

Steps to reproduce

1. Start playing a stream with a length of over ~3 hours. Streams that have sidecar subtitle files (i.e. VTT) are more likely to exhibit this issue.

Expected behaviour

Stream starts and plays within ~10 seconds

What actually happened?

Observe startup delay along with an unresponsive UI, indicating a possible thread starvation. Custom log output shows that the fragment creation latency gets progressively worse over time (note the subtitle loop takes ~48 seconds to complete)

Console output

n/a

Chrome media internals output

n/a

Start by reviewing the m3u8-parser level parsing path, especially Fragment object creation, and the Vite resolve configuration described in the issue. Reproduce with a stream longer than three hours and sidecar VTT subtitles on the affected Tizen devices; done means confirming whether startup delay and UI blocking remain and documenting the applicable configuration or project change.