shaka-player: Memory leaks in Tizen OS
Have you read the FAQ and checked for duplicate open issues? - yes
What version of Shaka Player are you using? - 2.4.6 and 2.5.3
Can you reproduce the issue with our latest release version? - checking the changelog for 2.5.4 highly likely it will have the same issues.
Can you reproduce the issue with the latest code from master? - did not try
Are you using the demo app or your own custom app? - Custom Application
If custom app, can you reproduce the issue using our demo app? - did not try
What browser and OS are you using? - Chromium / Samsung Tizen TV
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
- 32" Class N5300 Smart Full HD TV (2018)
- 40" Class NU7100 Smart 4K UHD TV (2018)
- 49" Class NU8000 Premium Smart 4K UHD TV (2018)
- 43" Class Q60R QLED Smart 4K UHD TV (2019)
- 43" NU6900 Smart 4K UHD TV (2018)
What are the manifest and license server URIs? - private information. We can explore the possibility to have public URLs and share with you.
What did you do?
- Start playback of HLS Live Broadcast with 4-second segments and play it as long as possible
What did you expect to happen?
- We expect that that Tizen TV device can play Live broadcast for at least 4 hours, ideally 24 hours
What actually happened?
We see that low-end and high-end devices crash after some time. The low-end devices can even freeze. We see a bit better results with 2.4.6, where 2.5.3 - could fail even for Premium devices.
For 2.4.6 - we do not see anything useful in the application logs, mostly last logs an about of playing segment successfully.
For 2.5.3 - we see Error: 3016 for Premium devices after playing for 2+ hours. In the cases when device freeze, we do not see any error in the persisted application logs.
Test Results for 2.5.3 (In Progress)
Test Results for 2.4.6
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 47 (20 by maintainers)
In 3.x I see memory growing continuously in chrome as well as on WebOS ( I assume Tizen as well since playback stops working after about 20 minutes but I didn’t profile this ) but in 2.5.17 it is stable playing live DASH + Widevine DRM, seems there is some difference there between the versions. I haven’t managed to track down the difference yet though.
Hi @leszek-syroka
The memory issue I encountered has already been resolved in shaka 😃
I am Samsung engineer, so I can provide some insight from the platform point of view. I am asking about specific content and player, because I have already tried using DASH-IF test vectors in order to reproduce the issue https://testassets.dashif.org/. I did not observe memory leaks that stopped playback.
@OrenMe with the player paused the memory changes are small, so I could use chrome dev tools memory “allocation instrumentation on timeline”. With that I could see some data being allocated every time there’s a new manifest loaded. With “record allocation stack” enabled and the debug build of shaka player instead of the production build, I could understand which variables are holding the memory. Technically speaking this is not a memory leak, since the memory is actually freed when the player is closed and the data structures are cleaned, it just uses more memory than necessary.
I wish I knew that @NicolasSiver, would have saved me some time and nerves:-) I will continue checking the stability so if we encounter same things I’ll update here. @kevinscroggins-youi thanks for the input! Will definitely use that for stability checks.
@OrenMe, that’s a great idea. Please let us know how it turns out! We don’t have access to Tizen right now while we’re in quarantine.
@joeyparrish @NicolasSiver we re also experiencing similar issues although we are failing much faster then the times you describe here with TV getting totaly stuck and needing to reset the device. We will conduct some profiling tests as much as we can, s the profiler in the IDE gets stuck. Maybe a good experiment is to measure even on chrome with the two mentioned versions - if there is more memory usage in newer version it might point to something as chrome vs TV memory makes a difference. It seems that using DRM protected streams makes the issue even more apparent and happen faster.