Opening IsoFile throws OutOfMemory Exception on Android

[thenotoriousrog]

Hello everyone. I was using this library for a project at work. I noticed that issue #284 was closed, but I wanted to submit another issue that's similar in nature.

The project is in Kotlin, but I can convert to Java if it helps with readability of this ticket.

Device: Google Pixel 2 XL Android Q Beta 2 On IsoParser version 1.9.38

I'm trying to open an IsoFile via like this: val isoFile = IsoFile(Channels.newChannel(ByteArrayInputStream(base64DecodedString)

The resulting StackTrace error is the following:

java.lang.OutOfMemoryError: Failed to allocate a 2064261160 byte allocation with 7167453 free bytes and 505MB until OOM, target footprint 14334909, growth limit 536870912 at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:54) at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:49) at java.nio.ByteBuffer.allocate(ByteBuffer.java:282) at org.mp4parser.support.AbstractBox.parse(AbstractBox.java:96) at org.mp4parser.AbstractBoxParser.parseBox(AbstractBoxParser.java:115) at org.mp4parser.BasicContainer.initContainer(BasicContainer.java:107) at org.mp4parser.IsoFile.<init>(IsoFile.java:57) at org.mp4parser.IsoFile.<init>(IsoFile.java:52) at com.realeyes.adinsertion.exoplayer.PsshParser$Companion.getWidevinePSSH(PsshParser.kt:69) at com.realeyes.adinsertion.components.ads.live.VodPlaylistAdStitcher.checkForDrmKey(VodPlaylistAdStitcher.java:250) at com.realeyes.adinsertion.components.ads.live.VodPlaylistAdStitcher.parseWithVmapPrerolls(VodPlaylistAdStitcher.java:205) at com.realeyes.adinsertion.components.ads.live.VodPlaylistAdStitcher.getPlaylist(VodPlaylistAdStitcher.java:103) at com.realeyes.adinsertion.components.ads.StitchingAdManager.parse(StitchingAdManager.java:68) at com.realeyes.adinsertion.components.ads.StitchingAdManager.parse(StitchingAdManager.java:24) at com.google.android.reexoplayer2.upstream.ParsingLoadable.load(ParsingLoadable.java:158) at com.google.android.reexoplayer2.upstream.Loader$LoadTask.run(Loader.java:389) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:919)

Would greatly appreciate any advice on the following. I can't seem to determine if it's a truly known bug or not, or if it's something I'm messing up. Let me know if I can give any more information on the issue I'm experiencing.

[HBiSoft]

I have this issue as well, so does many other people. This question has been asked many times. Have a look at all the questions about this - #139 #151 #284 #299

Apparently it was fixed in #288 , but I still get this error.

I'm not if this will ever be fixed. It's been 4 years since this issue has been reported.

I'm currently looking at other alternatives.

If you every get this error to go away, please let everyone know.

[thenotoriousrog]

Maybe I will try tracking down this issue and seeing if I can come up with anything.

[HBiSoft]

@thenotoriousrog a new release is available:

implementation 'org.mp4parser:isoparser:1.9.39'
implementation 'org.mp4parser:muxer:1.9.39'

Can you please test and confirm if you still get the OutOfMemoryError?

[thenotoriousrog]

@HBiSoft I'm currently instructed at work to not only test but also try to debug this issue and find a resolution as it's a blocker for our Sprint. I'll get back to you after updating!

[HBiSoft]

@thenotoriousrog the issue is that it creates a huge buffer inside AbstractBox line 96.

Smaller buffer = less memory = more time needed to read..

You can have a look at the changes made in this pull request - #205

[thenotoriousrog]

@HBiSoft thanks! So I tried out the newest version, but the problem still persists unfortunately. I'll take a look at the PR. So if the problem was addressed in this PR. Do you think the problem could be elsewhere? Do you recommend that I take a look at this AbstractBox class first or somewhere else?

[thenotoriousrog]

Also would anyone happen to know, how to properly get this repo cloned and running? Seems to be a maven based project, so perhaps my maven setup is incorrect.

[thenotoriousrog]

@HBiSoft So after careful tracking and debugging. It turns out that the base64 string I was passing into the IsoFile was not actually a Pssh box. It was some random base64 encrypted data that I assumed was a pssh box. This obviously freaked out the library and my guess is because it's not a pssh box, it doesn't know how big this data is and allocates memory indefinitely. Perhaps that's the root cause of all the related issues that I was happening. Perhaps not. But I will close my issue due to this sudden realization!

Thanks for trying to help me resolve it!

[HBiSoft]

@thenotoriousrog Thanks for letting me know. So what did you do to resolve the issue?

[thenotoriousrog]

@HBiSoft My boss saw the base64 string I was passing in and noticed that it didn't look right. We base64 decoded it and we saw that it was just a json response string that was base64 encrypted. When we passed in an actual base64 decrypted pssh box, we saw that the outofmemory exception no longer showed itself.

Not sure how helpful that is other then finding a bug, but it's good to know something is deeply broken. At least with this use case.

[HBiSoft]

@thenotoriousrog it would be great if you could provide more info on how exactly you resolved this, perhaps fixing it in the library by creating a pull request to help everyone that is experiencing this.

[thenotoriousrog]

@HBiSoft my apologies. I wasn't able to write any code that fixed this. Literally the issue I was experiencing was due to me passing the IsoFile library an incorrect value and the library choked up. I don't have a resolution for the outofmemory issue I'm sorry :(

[HBiSoft]

@thenotoriousrog I have created a new issue, I've added a project file and video to reproduce the issue, if you want to have a look.