I have tried in b09 (crashes android device on play) and b10. Black object instead of video playing. The video plays in the trial version of the Unity store asset AVPro video.
Also I downloaded the Unity demo posted at the top of the forum, same result (crash).
Sorry youāre having trouble with playback on Android, an important rework was done for b10, but is missing one important bug fix having to do with clips not starting when the timestamp of the first frame is not 0. Many clips have their first frame start at frame 1 which trips some logic in our Android decoding implementation. This is fixed in the next version (beta 11).
Thanks for the reply. I tried the video you suggested on b10. No crash but the video isnāt playing (black gameobject). Works fine in the editor. I have tried a few transcoding options with same result.
OK, thanks for trying out. Can you also try both with GLES2 and GLES3 Graphics APIs?
There si a GL extension that has to be present for the decode-to-texture to work, and GLES2 and 3 each have their on flavour of the extension. If you have time, please submit a bug with the project as well as the logcat from your device so we can make sure we cover this scenario in our tests.
Thanks for taking the time to dig through this. For the audio to work, did you use the āAudio Sourceā Audio Output Mode? The āDirectā Audio Output Mode doesnāt yet work outside of OSX / iOS, so you have to assign an Audio Source to the Video Player (in the UI or through scripting) for the audio to be heard on Android. Iāve recently added a warning in the console when we detect the direct mode being used in a context where it isnāt yet supported.
When you have the bug id you submitted, please post it to this thread so everyone can follow its progress.
We have to see what we can do about GLES3 being selected by default when Auto Graphics API is on and preventing the GLES2 API from being used (the bug you logged).
We need to document that direct output doesnāt work (yet) on Android. In fact, it only works for OSX / iOS for now, and Iāve added a warning about this that is sent to the log, but of course on your device it will be rather subtle: it goes to the deviceās log. This feature will be implemented in a future release.
Yes I think so. To clarify, when you uncheck Auto Graphics API and are left with OpenGLES2, OpenGLES3, and Vulkan in the list. (i.e. you donāt have to remove any of the APIās ) The video plays fine with all 3 in the list.
It doesnāt play when Auto Graphics API is checked
OK, thanks for the clarification. Weāll have to see in what order the APIs are tried and how the VideoPlayer can influence the choice of the graphics API at startup time.
Follow-up: for anyone following this situation, the workaround really is to force the Graphics API to GLES2 because on devices that donāt have full support for GLES3 (including the GL_OES_EGL_image_external_essl3 extension), the VideoPlayer will not work. Weāll have to devise a solution for having the VideoPlayer work on GLES3 implementations that donāt have this extension (at least one solution comes to mind, but has performance implications) but meanwhile, please force the Graphics API to GLES2 when faced with this problem.
Using Unity 5.6.0b11
forced GLES 2 errors a lot after preparing and playing the video from web url
disabled automatic graphics API, left the list untouched: Vulkan, GLES 3, GLES 2 it still errored
Automatic graphics API turned on still doesnāt play video.
Either situation on a Nexus 5 I could not get it working on android.
Sidenote: have not tried the video you linked before.
With automatic graphics API it does prepare the video, when play is called it will still be a black screen because it could not find video decode shader pass.
Thanks a lot for taking the time to report this, Iāll see what we can do to reproduce locally with a similar device. I am working on a number of improvements to this situation that will be tested in the upcoming days. If you can, please report details about your device (exact model, OS version) so we can make sure to correctly cover this.
Note that with the version you are using, the only āvalidā configuration for testing is keeping auto graphics API off and only leaving GLES 2 in the list. The version I am working on right now should let you use both GLES2, GLES3 or Auto. Of course there is a lot of variability in the video playback world on Android, so we cannot be sure for every device, but weāre doing everything we can to improve this.
So I went and re-created the build with GLES2 only to try again and used the http://download.blender.org/peach/bigbuckbunny_movies/BigBuckBunny_640x360.m4v
Seems to work fine now (donāt know why it didnāt before, maybe it was an other mp4 url that didnāt work).
So canāt reproduce it at this moment. If I can Iāll be sure to make a bug report of it.
Would be nice to see GLES3 going (or vulkan, whatever is better for performance).
Iām looking forward to the release and stability of the video player.
As I think this has a lot more potential than the āEasy Movie Textureā plugin ever had.
GLES3 on Nexus 5 has been tested locally and now works. Weāre making every effort for these improvements to make it in time for the 5.6 release. Vulkan is an entirely different discussion however and is not supported by the Android VideoPlayer for now.
Maybe this is a related issue?
I was encountering the same blank video screen as the earlier threads (unity ver 5.6.0f1), and suggested solution of using GLES2 also fixed the problem for me. But it seems the same issue with videoPlayer is now re-occuring when implementing Google GVR SDK for Unity v1.30. Anyone also using gvr camera and encountering similar issue?
Hi Dominique, Iām still having trouble with VideoPlayer when using a project set up for google cardboard. On Nexus 5x 7.1. The video player functionality seems stable in a completely bare project, but starts to break down especially when streaming, if there is more going on. I have a test case and a logcat if youāre interested.
Yes, Iām really interested, thanks for the offer!
Would you mind submitting the project as a bug report so we have all the info (Unity version, project, logcat) at the same place? It helps with internal communication and prioritization as well and makes it easier to enlist the help of QA and support teams.
I understand that performance problems start to creep up as you raise complexity, but it would make profiling and general investigation easier if you kept the simplicity level as low as possible - while keeping the performance problems visible of course.
It could be that the solution resides in using a more lightweight video, but it will be a good exercise to go through your project to see if there are any low-hanging fruits.
Note that the closest device I have to test this is a Nexus 6 running 6.0.1. Think this is an adequate substitution?
Iāve submitted a bug report and attached a project and logcat.
I believe the video weāre trying to stream is 360p and, while quite long, Iām having issues before the first frame is visible.
The log cat has a whole host of GLES enum argument out of range errors after the line āmakeComponentInstance(OMX.google.aac.decoder) in mediacodec processā so I believe this is a decoding issue rather than a memory problem.
I have a range of devices here, the 5x is the worst of the lot the 6p has been fine. Pixel is somewhere in between. I hope this helps you guys to track this down.
Thanks for submitting this! 360p is definitely reasonable so we should be able to do something.
Also please add the bug id on this thread so I can go have a look asap.
About the OMX.google.aac.decoder, this is a audio-related message (AAC being the audio codec for audio streams that normally accompanies H.264 video streams), so this is likely not related to the GL error.