The fix we have found is to put in:
mVideoPlayer.Deinit();
mIsInited = false;
mIsPrepared = false;
inside a VideoPlaybackBehaviour's OnDisable function to launch when tracking is lost.
It seems the native video player is getting overloaded somehow with over 3 video planes active in the scene. Android has a much worse problem with this than iOS. The above code solves the issue on iOS for the most part, but Android (4.0) will run out of memory and crash the app after a a handful of movie viewings (either full screen, or video on texture) We've tried on a wide range of Android devices.
We're still looking for ways to optimize how the native video player handles new video instances. One thing we may try is just having one video instance in the scene at a time and switching out the video playing on it during runtime as needed. It would be a lot of re-writing to work with our set up, but if it ends up solving the issue, it would be worth it.
Another angle we tried was having a new scene load for the 4th video plane, but it looks clunky to have the arcamera freeze, go black, and then reload to find the tracking target and continue on. But, it does solve the issues we've seen. If we could get the arcamera to persist across scene files, that may be something to look at as well.
Thanks for any ideas,
-p
I've developed a workaround for this issue. I am now listening for the OnTrackingFound() and OnTrackingLost() events and creating the video instances dynamically. This allowed me to play a video from 14 different trackables through instantiation at runtime.
Previously, I could play up to 4 and then the rest would either display an "X" and force fullscreen when tapped. Now, all videos play on texture and i am able to view the video as many times as I'd like.
You could also extend on this solution using the method described by DavidBeard in this thread:
For now, this type of solution has solved my problem.