search

airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
205 stars 11 forks source link

[Windows] Mem leak on looping video is still there [33.1.1.575] #1198

Open AnJ73 opened 3 years ago

AnJ73 commented 3 years ago

Hello guys,

I wanted to try something new as I stuck with 32.0.0.89 for years and I know it has some issues... so I downloaded 33.1.1.575 and I hit the problem that appeared a few threads w/ older '33' SDK versions.

Problem Description

The same code, playing the same h.264 video [4k, vertical, 18sec, no sound] in the loop. Compiled under IntelliJ as 64bit captive bundle for Win. [it is not 64bit exclusive issue - mem leaks in 32bit as well]

32.0.0.89 vidLoop_320089

33.1.1.575 vudLoop_3311575

Now imagine touch screen APP that users interact with from time to time, but for most of the day it plays idle state video loop... or even better: non-interactive APP that just plays scheduled vids all day long ;)

Correct me if I am wrong, but every '32' SDK after 32.0.0.89 had some video playback issues. Perhaps tracking changes made since then would be a good point to start. Also: use 4k videos for your test as problem is more visible w/ hi-res APPs.

Steps to Reproduce

Here is my code [as & xml APP descriptor]: isThereAMemLeakOnVideoLoop.zip

Known Workarounds

none

A little side note

Please do not focus on this a on the main issue ;)

here: https://github.com/airsdk/Adobe-Runtime-Support/issues/779#issuecomment-818588912 @ajwfrost said:

Without the dispose/close on the NetStream and NetConnection objects, then yes we'd expect a memory leak..

My experience is that video loop could reuse nc&ns for hours w/o any [noticeable] mem leaks [just a reminder: 32.0.0.89]. Of course is is not a big deal for me to dispose/create new instances... it just looks like a step in opposite direction from the 'seamless video loop feature' which was requested by the flash community since good old Macromedia times ;]

ajwfrost commented 3 years ago

Hi

So we've been reviewing this code again and doing some further profiling, there was a significant memory leak happening with certain configurations of StageVideo which is what I think you're seeing there. There are a couple of more minor leaks that we've also just cleaned up. Below is an updated screenshot, not the latest version but I think we will still be seeing some memory usage creep up due to fragmentation caused by object churn... but hopefully this will be better!

Thanks for sending in the details and a great test case!

FYI, the video handling code was basically re-written following that version 32 of the AIR SDK, due to the removal of some code that was subject to patent restrictions. So it's more a case of shaking out the bugs in this new implementation, rather than comparing this vs the earlier code..

thanks

image

AnJ73 commented 3 years ago

Hi Andrew, Thanks for your response - your screen grab looks just great I am waiting [impatiently ;)] to play w/ new SDK release.

ajwfrost commented 3 years ago

Thanks - although the changes won't be in the next SDK I'm afraid as this was already built, these will be in the one after that... But we will be looking to put up a "work in progress" aka beta release that you could use.

2jfw commented 3 years ago

Not sure if there is a demand and/or this makes sense but what about Nightly Builds of the AIR SDK?

ajwfrost commented 3 years ago

Yes we had wondered about this; the only issue would be the amount of data that this then means we're shipping all around the place; the vast majority of stuff doesn't change much.. Plus our build process currently uses four different machines and requires the various build outputs to be merged into a single location and then zipped up .. it would be better if we could "component-ise" it all and just allow you to take the relevant components e.g. if we change something in the Android Java classes then you just get a new jar file, etc.

We had considered creating an "SDK Manager" that could monitor and pull down updates/patches individually like this, rather than it needing to grab a whole SDK (which should then simplify the update process for everyone) - might be something that we build into the APM perhaps, as it can already pull down the latest and beta releases I believe... https://github.com/airsdk/apm/wiki/Usage-AIRSDK

simon-lucas commented 2 years ago

I have this problem. It is using 33.1.1.575. The memory leak is there on MacOS and Windows. I played a number of videos and ended up with a 10Gb memory footprint. I tested my project on an old Flash CS6 install with SDK 28.x.x and there is no leak.

Is there any prospect of a solution for this? I'd be happy to wind back to SDK 30 or 31 for the time being, but Adobe have pulled all AIR archives (SDKs and Air Installers) from their site.

ajwfrost commented 2 years ago

The leak demonstrated in the above test - which was present in 33.1.1.575 - was fixed in 33.1.1.674 last November. So are you able to try again using that or the latest SDK? and if there's still an issue, please let us know (preferably with a simple test case including a video that demonstrates the problem)..

thanks

simon-lucas commented 2 years ago

The leak demonstrated in the above test - which was present in 33.1.1.575 - was fixed in 33.1.1.674 last November. So are you able to try again using that or the latest SDK? and if there's still an issue, please let us know (preferably with a simple test case including a video that demonstrates the problem)..

thanks

Yes - thank-you. I tried 33.1.1.743. It fixed the problem on Mac OS. I will try it on a Windows machine as soon as I can.