Bug Video Player on Android

Hi!

One part of the error message is telling you what's happening:

AndroidVideoMedia::OpenExtractor could not translate archive:/CAB-numbers and letters/CAB-numbers and letters. resource to a local file. Make sure the file exists, is on disk (not in memory), and not compressed.

So the resource or asset bundle you are using for reading the video appears to be in memory and/or compressed. You should make sure you create these without compression or else they won't work on Android. There are no size advantages to compressing video assets so you'd be saving some processing (although I understand this may be an annoyance if a video is included in an asset bundle with other assets that would benefit from compression). This is a limitation of the Android implementation of the VideoPlayer, which we've mitigated in Unity 2020.2.

Now, the expected behaviour is not to crash, but just to not proceed with the playback, so it's obviously a bug... sorry about that: you may want to file a bug report for this. But if you re-arrange your resources or asset bundle creation/loading, you should get the playback working correctly. It behaves differently on iOS because it's an entirely different implementation, which doesn't have this limitation.

You're mentioning that this sometimes works: are you saying this is sometimes actually working on Android? This would be surprising but worth investigating if you can include more details about this behaviour in your bug report.

Thanks for letting us know about this issue, and hope the workaround is working for you!

Dominique Leroux
A/V developer at Unity

 

Hi again,

Thanks for the additional information. I've looked at the 2019.4 release history: it currently stands at 2019.4.33f1, whereas the version you are using is 2019.4.8f1. There are many fixes that went in since your version was released, so one thing to try would be to update to the latest 2019.4 if possible. Also (and I do understand it's not always feasible), it would be good to know if this same problem exists in the 2020.x or 2021.x releases. If not, then maybe we can isolate what the fix was in these releases and backport it.

At this point however, it would be useful for us to have a repro project to work with so please let us know how the version upgrade experiments go. And if you find you have to file a bug, please report the id over here so we can immediately assist our QA team in identifying and directing the report to the right group.

Dominique

 

Hi!

Thanks for going through all these tests methodically, you've eliminated a lot of the possible culprits.

Are are a few other things that could be tried:

• Try with a 2020.x or 2021.x version.
• Observe whether the Unity process memory usage is close to the physical limit; maybe some decompression that's supposed to happen ahead of time is unable to proceed due to exhausted resources (admittedly a relatively wild guess, here). To this end, you could try replacing the videos you are using with versions that are noticeably shorter, or with lower resolution.
  
• I'll see if we can get to the source line that your crash report points to, though even if we know what causes the crash, this is just a consequence of an earlier problem (the fact that the file being read is compressed or in-memory).
• One fact that your crash dump reveals is that this is running from a 32-bits build. How workable would it be for you to build for arm64 instead? A colleague pointed out (from seeing the "lib/arm/libunity.so" in the report) that the crash originates from a 32-bits build. If address space is getting tight, then this would substantiate my guess about memory resources getting tight. I've also been told that 64-bits builds often give better stack traces so even if you still get the problem, maybe the crash report will be more informative.
• I'm also told that the Bluestacks may not be well supported, so it'd be useful to try and get a crash dump from an actual device.

This is all I can think of for now: let us know if this helps.

Dominique