Exposing all hls.js events as api events leads to memory leak

[phloxic]

Triggering player events whenever a hls.js event is fired increases private memory consumption steadily.

See: https://flowplayer.org/forum/#!/setup:buffering-preloader-always

[phloxic]

With the propagation of hls.js to be triggered as flowplayer events private memory in chrome://memory-redirect/ can exceed 1GB.
At least temporarily I will remove these triggers.
It needs investigation though: With the dashjs plugin we do something quite similar without problems: https://github.com/flowplayer/flowplayer-mpegdash/blob/master/flowplayer.dashjs.js#L255 or https://github.com/flowplayer/flowplayer-mpegdash/blob/master/flowplayer.dashjs.js#L207-L257

@nnarhinen, @mangui - thoughts?

[phloxic]

We still must expose hlsError because the earliest opportunity to set up a hls.js listener is ready, and by that time we are too late for a scenario like 'Simulate dummy stream' at http://demos.flowplayer.org/api/live-check.html

[phloxic]

To document this:

1,288,752k private memory with hls.js events (re-)triggered by player.

[phloxic]

For comparison with dashjs plugin:

740,636k private memory with dash.js events (re-)triggered by player.

[phloxic]

hls.js demo player:

581,840k private memory

[phloxic]

MP4 highest resolution of same movie: 277,144k in Flowplayer.

[denbald]

In our project we use flowplayer-hlsjs when streaming video. Recently we found memory leak bug, which is happened when stream is playing some amount of time. These leaks are happened only when Hls.Events.FRAG_PARSING_DATA event is exposed in listeners array of hlsjs configuration.

One of the workarounds, that eliminates these memory leaks, is to reset event data, before we triggering this event on flowplayer, but in this case we lost all data of FRAG_PARSING_DATA event.
Maybe you can suggest better sollution or pinpoint right direction for solving this problem?

P.S. It takes place in all web-browsers, except EDGE.

[phloxic]

@criozen can you try listening to the event directly and see whether that alleviates the problem, e.g.:

flowplayer(containter, {
  // player configuration goes here
  // do not register the hls.js event
}).on("ready", function (e, api) {
  if (api.engine.hlsjs) {
    api.engine.hlsjs.on(Hls.Events.FRAG_PARSING_DATA, function (e, data) {
      console.info(data);
    });
  }
});

Also make sure that you are using the latest version of the plugin.

[denbald]

@blacktrash Listening directly from hls.js eliminate this issue in Chrome and Internet Explorer, but not in Firefox.

[phloxic]

@criozen - without an actual sample page I can't know what you're actually doing in the event handler.
Things to try:

• does it happen as well with minimal functionality as above?
• does it happen in a pure hls.js setup as well?
• what are the actual symptoms of the memory leak bug?

[denbald]

Yes, it happen with minimal functionality as above as well. Main symptom is increasing of memory heap e.g. on this screenshot i compare memory snapshot that was made in the beginning of stream (heap size 35 mb) and that was made after 15 minutes of stream (heap size 235 mb)

After 60-70 minutes of streaming heap size reaches 1 GB and page with the stream will crash.

[phloxic]

And this does not happen in a pure hls.js setup w/o Flowplayer?

[denbald]

Turns out that problem was not only with FRAG_PARSING_DATA event, but also with FRAG_LOADED event. After i start to listen both of this events directly from hls.js, memory leaks in all browsers are gone.
In pure hls.js setup without Flowplayer this does not happen.

[phloxic]

@criozen - I have lost track now: when you listen to both events, the issue is gone, but if you listen to FRAG_PARSING_DATA alone it's still there?
Aside: I did run an almost 2 hour stream with hlsFragParsingData registered and got less than half of what's in your table, and certainly no crash.
It would really be helpful if you came up with a sample.

[josh-sachs]

Sorry about this, but I think they've removed the memory tab from chrome. Can you comment as to whether or not this issue may be responsible for memory behavior like this?

https://ibb.co/eqFiKk

Basically i see an acceptable Javascript heap but overall memory consumption balloons out of control. Specifically, i've got two players rendering the same live video on a page.

[phloxic]

@josh-sachs - chrome://system/
There is obviously a somewhat higher memory usage when running hls.js via the plugin, the core player also eats some CPU.
You can/should compare with running 2 hls.js plain video tag instances.
In the end both hls.js and dash.js are quite memory intensive, plus hls.js also has to remux constantly.
This issue is about incrementing local memory though.
Also take a look at video-dev/hls.js#1262 - note as well that having debugging tabs open increases memory consumption.