libVLC for Android, Sample app fails using textureView instead of surfaceView

[langolier7]

Hi, i was just trying out the sample android application from here: https://code.videolan.org/videolan/libvlc-android-samples

I was using the java-sample (using libVLC 3.1.12), which was working great by default, using the surface view. As i need the video to use a texture view, which seems to be supported by the project I simply changed the Mediaplayer call in JavaActivity to:
mMediaPlayer.attachViews(mVideoLayout, null, ENABLE_SUBTITLES, true);

which handed me this following stacktrace:

2019-09-13 14:56:33.442 6074-6074/org.videolan.java_sample E/AndroidRuntime: FATAL EXCEPTION: main
Process: org.videolan.java_sample, PID: 6074
java.lang.RuntimeException: Unable to start activity ComponentInfo{org.videolan.java_sample/org.videolan.javasample.JavaActivity}: java.lang.IllegalArgumentException: surfaceTexture must not be null
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2910)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2985)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1649)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:180)
at android.app.ActivityThread.main(ActivityThread.java:6914)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:797)
Caused by: java.lang.IllegalArgumentException: surfaceTexture must not be null
at android.view.Surface.<init>(Surface.java:178)
at org.videolan.libvlc.AWindow$SurfaceHelper.attachTextureView(AWindow.java:97)
at org.videolan.libvlc.AWindow$SurfaceHelper.attach(AWindow.java:110)
at org.videolan.libvlc.AWindow.attachViews(AWindow.java:325)
at org.videolan.libvlc.VideoHelper.attachViews(VideoHelper.java:95)
at org.videolan.libvlc.MediaPlayer.attachViews(MediaPlayer.java:605)
at org.videolan.javasample.JavaActivity.onStart(JavaActivity.java:78)
at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1385)
at android.app.Activity.performStart(Activity.java:7003)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2873)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2985)
at android.app.ActivityThread.-wrap11(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1649)
at android.os.Handler.dispatchMessage(Handler.java:105)
at android.os.Looper.loop(Looper.java:180)
at android.app.ActivityThread.main(ActivityThread.java:6914)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:240)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:797)


I tried to go through the code, but i cannot tell what exactly the problem is, but it seems the textureView won't get initialized correctly, which could be a bug.

[mohru_mo]

I have exactly the same exception when running the libvlc-android-samples with gradle dependency implementation 'org.videolan.android:libvlc-all:3.2.5' (the lates available), so I would say that this bug still ocurrs.

I'm not able to build libVLC sources myself, so I cannot tell if this issue was solved in the latest versions, but I really need to use TextureView in my player.

I would say that the problem is in the MediaPlayer.attachViews because textureView is inflated in the VideoHelper constructor, and right after it the attachViews method tries to get the surfaceTecture from it before it's even created - there should be probably a SurfaceTextureListener set somewhere there.

Can you tell me if this issue has been fixed in any later vlcLib version?


edit. Now I found something much more disturbing. Correct me if I'm wrong, but I think that VideoHelper is not prepared for handling TextureView instead of SurfaceView in general.

I tried to workaround the issue I mentioned above, and inflate the textureView stub earlier (and wait for the surface to be available), but anyway, when the layout is changed updateVideoSurfaces method is called and it tries to update 'mVideoSurface', which is null because I use TextureView. That makes no sense.

I would be really grateful for some explanations if I mixed something up, or is this just a really big bug.

[mohru_mo]

I found a bug reported on VLC-android issue-tracker https://code.videolan.org/videolan/vlc- ... ssues/1359, and now I'm pretty sure that the bug is that big.

I managed to overcome it by implementing the changes done in old commit from libvlc-android-samples repository and creating in VideoHelper a new variable that would take the value of surfaceView or textureView depending on which one is set, and then operate on that variable instead of surfaceView. Also, the texture_stub should be inflated earlier and mMediaPlayer.attachViews should be called from onSurfaceTextureAvailable callback.

I hope this will get fixed in the future versions of libVLC.