shaka-player: High memory pressure with live dash playback

Have you read the FAQ and checked for duplicate open issues? Yes

If the problem is related to FairPlay, have you read the tutorial? Not applicable

What version of Shaka Player are you using? 4.7.0

Can you reproduce the issue with our latest release version? Not tested, but compared the branch against 4.7.0

Can you reproduce the issue with the latest code from main? Not tested, but compared the branch against main

Are you using the demo app or your own custom app? Custom app (just a page with shaka player)

If custom app, can you reproduce the issue using our demo app? Not tried

What browser and OS are you using? Web: Windows Chrome 120.0.6099.199 (Official Build) (64-bit) webos 4,6: chromium 53 and 79 respectively tizen 4: chromium 56

For embedded devices (smart TVs, etc.), what model and firmware version are you using? webos 4: 43UM7300PLB (2019) webos 6: 43UP81006LA (2021) tizen 4: UE43NU7400U (2018)

What are the manifest and license server URIs? I will send you the URL via email.

What configuration are you using? What is the output of player.getConfiguration()? Player configuration is attached. player_config_web.txt

What did you do? Started playback of identical live dash stream with 4.3.0 and 4.7.0 shaka versions and kept it up to 2 hours. I monitored memory with distinct tools (depending on the platform), but namely on web I made heapdumps every 10-30 minutes.

What did you expect to happen? Memory footprint should not be growing after buffer filling for 4.7.0 (as it is true for 4.3.0). Also, memory allocation rate should be smaller for 4.7.0 similar to 4.3.0 (tested on smart tv devices with webos 4/6 and tizen 4).

What actually happened? Shaka 4.7.0 memory footprint grew over time during live playback (no interaction with the custom demo app, tested on web and webos 4/6). Allegedly, memory growth depends on DVR window size since it stabilized after 60 minutes of test on web (timeShiftBufferDepth is 1 hour). During two tests I observed heap reaching 39 and 68 MB respectively whereas with shaka 4.3.0 playback its size was around 11-12 MB. shaka-smtvweb-heapdumps Another one issue - memory allocation/clean up magnitude is much higher for 4.7.0 in comparison to 4.3.0 under the same testing conditions (tested on webos 4/6 and tizen 4 with 1h DVR). The consequence of high memory pressure on low-end smart tv devices is UI freezing during interaction with the app: OS and browser are busy with memory housekeeping tasks like swapping, GC, OS level memory allocation delays etc. Mere live playback with our own app started to freeze on webos 4 2019 device after ~15 minutes without any UI interaction. webos6_shaka_470_memory webos6_shaka_430_memory

Heapdumps comparison refers to memory kept by SegmentIndex/XML DOM data structures. As for high memory allocation rate, I am pondering about evict() changes in TimelineSegmentIndex class: slice() was added to timeline and references objects, which is about shallow copies of arrays (relevant changes may be in https://github.com/shaka-project/shaka-player/pull/5061).

About this issue

Original URL
State: open
Created 6 months ago
Reactions: 1
Comments: 36 (25 by maintainers)

Commits related to this issue

fix(DASH): decrease memory preasure on manifest with SegmentReference by updating old initSegmentReference (#6499) Helps on #6070 — committed to shaka-project/shaka-player by cdatehortuab 2 months ago
fix(DASH): decrease memory preasure on manifest with SegmentReference by updating old initSegmentReference (#6499) Helps on #6070 — committed to shaka-project/shaka-player by cdatehortuab 2 months ago

Most upvoted comments

I have conducted some memory tests on webos 6 2021 device with beanviser. The purpose was to compare distinct shaka versions and seek for any difference in terms of memory allocation during live dash playback. The results are the following: I am thinking of #5061 added in 4.4 being a culprit for the memory usage growth: it may be improving manifest parsing time at the cost of excessive memory pressure, which in turn is the most costly resource on low-end smart tv devices (on par with main thread availability). The memory pressure presumably became even worse with shaka 4.6.1 #5899 - the PR introduced the ticket subject memory leak through addition of initSegmentReference parameter to appendTemplateInfo().

Illmatikx on Mar 19, 2024

I think I’ve found one of the issues – the initSegmentReference sticks around forever. When all references have been evicted from the TimelineSegmentIndex, we should be freeing everything we can so it can be garbage collected.

At that point, the TimelineSegmentIndex really only exists as a shell to keep track of numEvicted.

nrcrast on Jan 19, 2024

Hi @avelad l’ll be back from holiday tomorrow and check if we can do a quick test

OrenMe on Apr 29, 2024

PR submitted #6499

cristian-atehortua on Apr 29, 2024

Some more interesting info!

Here is a comparison of my fork of v3.3.10 on the left and current shaka main on the right. Both contain the Timeline Segment Index, but my fork does not contain #5762 or any other changes that happened since my initial contribution.

Going to play the “binary search” game and see if I can reproduce similar results using official shaka releases and not my own fork.

nrcrast on Jan 30, 2024

It cannot be released in the release method, as the init segment reference can only be released once it’s guaranteed that the SegmentIndex has evicted all of its entries.

The issue with releasing everything in the overridden release method is that release is called also when you switch variants. When you switch variant, the segment index for Variant A is closed and then re-opened if you then switch back to that variant. At that time, all information needed to re-create the segment index must still exist somewhere in memory.

I am still chasing down the issue here – it seems that for some reason even though I’m setting initSegmentReference to null in the TimelineSegmentIndex, something is still holding onto it preventing it from being garbage collected.

I’ve just made a branch with this change in it as well as using splice if you also want to do some testing: https://github.com/nrcrast/shaka-player/tree/timeline-segment-index-free-all

nrcrast on Jan 26, 2024