Video Stopping a VideoPlayer takes a very long time (on Android)

Hello,

I am currently working on a project where we would like to play multiple videos (three max at the same time).

Inside a scrollable list, each item includes two or three videos playing.
We can go from an item to another by swiping, and the currently focused item plays its videos. Items are recycled while the user is scrolling.
In total, around 10 VideoPlayers are created, ready-to-go and preparing videos as needed.

However, when stopping a VideoPlayer or switching clips, we are encountering big framerate hitches. When looking at the profiler, stopping a VideoPlayer seems pretty expensive (VideoPlayer.DestroyPlayback takes more than 40 ms on the main thread to execute - for each VideoPlayer).



Test device : Samsung Galaxy S7 SM-G930F - Android 8

Is it normal ? Am I missing something ?
If it is normal, what would be the recommended way to reuse/recycle VideoPlayers for this use case ?


Thanks

 

We're seeing a similar issue. Did you find anything?

 

I have stopped working on video features but at the time I was still at it, we began switching to AVPro Video.

 

Thanks for the reply Dominique.

One thing I tried to avoid calls to DestroyPlayback, is to use a VideoPlayer per VideoClip we want to play, and call Pause() instead of Stop() on the running player. Changing .clip on the VideoPlayer seemed to result in calls to DestroyPlayback, so this approach also avoids that. (This also has a potential added benefit of being able to do some clip pre-preparation - though I have no idea if this is helping at all) We generally only have up to two Players playing at any given time. I'm still seeing a call to DestroyPlayback here and there, and am not really sure what's causing it. Based on what you said, it sounds like that could be forced by Android and there may be no way around it?

I'd also like some clarification on "2-3 video players" - does this mean 2-3 total VideoPlayer components in the scene, or 2-3 VideoPlayer components playing (while there may be more in the scene not playing)?

In the past I've also seen a few spikes due to DecodeNextFrame.

 

@DominiqueLrx just a small update - we created a build with only a single video player, and cycled the .clip value. In the profiler, I'm seeing a pretty big cpu spike every time the clip changes, with DestroyPlayback being the culprit. We're working on the Oculus Quest 2. We may be able to work on a repro build in the near future, but I suspect it wouldn't be hard to reproduce on your end.