Search Unity

Video Is VideoPlayer.Prepare() multithreading getting implemented on Android soon?

Discussion in 'Audio & Video' started by DGordon, Sep 27, 2017.

  1. DGordon

    DGordon

    Joined:
    Dec 8, 2013
    Posts:
    649
    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 https://forum.unity.com/threads/videoplayer-seturl-and-videoplayer-prepare-very-expensive.465128/
    "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"
     
    Last edited: Sep 27, 2017
    electroid, t-schulz and Prodigga like this.
  2. DGordon

    DGordon

    Joined:
    Dec 8, 2013
    Posts:
    649
    Sigh. Three different threads of multiple people who have been blocked by this issue, one thread where a Dev officially stated that a fix was already in the works and then disappeared, and still no response by anyone except more and more people who are being burned by this.

    I'll just bump this thread as well in hopes that someone at Unity actually reads the forums once in a while and decides to maybe respond.

    From a different thread I posted on:
    We completely removed any trace of the VideoPlayer from our Android app for this reason. Its absolutely ridiculous that Unity has not given any form of response to this issue. There are three threads that were opened on this. One of them directly tagged a Unity developer who had responded previously in the same thread, saying they were addressing the Android issue (half a year ago). And then neither he, nor anyone else, ever responded again.

    To be honest, this shows a tremendous lack of respect to any customer who ran into this issue. Not only did we spend time and money using a feature that was supposedly finished only to have to rip it out and implement a new system, but they have not even bothered to respond.

    I'm pretty amazed, to be honest. Usually they're pretty good about eventually responding to something that requires it, but this has been completely ignored after it was already stated they're aware of the issue, know what it is, and actively fixing it.

    Seriously ... did you really release the new VideoPlayer, only to have your customers have to rip it out due to a bug after spending time and money using it without being aware of this, and on top of that having no official response to multiple threads on this issue for months on end?

    We already ripped it out of one project, it would be nice to know if we should pretend the VideoPlayer doesn't exist on Android for any foreseeable projects as well. At this point in time, I have to assume the answer is "yes".
     
    t-schulz likes this.
  3. t-schulz

    t-schulz

    Joined:
    Feb 25, 2015
    Posts:
    13
    i have no words... unity should respond to that high number of posts relating to the horrible expensive Prepare() of the VideoPlayer. The number of bugs related to unity is getting more and more. We can´t build what we want cause of unfixable bugs...
     
  4. YoungXi

    YoungXi

    Joined:
    Jun 5, 2013
    Posts:
    63
    It's 9102, still no hope?