Can we get a post from a Dev on this?
Our use case: We have upwards of 100 256x256 short videos right now used for tutorials in a VR experience, and the entire app hitches down to about 10fps when the video prepares. There’s no way we can launch with this as is. So either this gets fixed, or we ditch the video player on Android. Unfortunately, we already made a lot of the videos and set up the game to use them, because we never imagined this would have launched with such a glaring issue … but what can we do.
Considering this issue is basically a show-stopper unless we don’t mind the app hitching over and over … could we get an official word on if using the VideoPlayer in Android is something that should be avoided for the foreseeable future? Can you guys flag which operating systems are multithreaded and which aren’t so we can at least understand its status on different platforms?
This issue is bad enough that I don’t understand how the VideoPlayer is considered actually production ready for any platform that has it unless its being used extremely sparsely.
Just to note: it was already mentioned by a dev that this is in the works, but that was about half a year ago already.
From VideoPlayer.setUrl() and VideoPlayer.Prepare very expensive ?
"Hi ahmidou!
Prepare() is indeed not free. Many of the implementations are currently running in the calling thread although some are asynchronous (iOS / OSX comes to mind). In the long run, they will all become asynchronous.
But independently of this, preparing all players like you are doing does not scale. What Prepare() does behind the scene is create one codec instance per track (video, audio) and allocates textures so everything is ready for playback.
Doing this, you may run into platform limitations: one cannot instantiate an infinite number of codecs, as these are tied to hardware resources.
As for Prepare() getting called even if you already did, please note that Stop() will undo the preparation. So assuming you stay with your current implementation (because you can prove to yourself that you don’t exceed platform limits), then I suggest using Pause() instead, which will preserve the preparation. Please let us know if this was the issue because preparation should not be redone once it has succeeded.
Hope this helps, and thanks for letting us know that Prepare() time is important to you; a fix to make preparation in another thread is ongoing, we’ll make it available as soon as possible.[Bolded for emphasis by me]
Have a good week-end,
Dominique
A/V developer at Unity"