Improving the libVLC implementation

[kura]

With #2534 changing libVLC to be marked as experimental with the comment There's a lot of crashes when using LibVLC because our implementation is just bad, I was wondering if/when this might be improved?

The reason I use libVLC over Exoplayer is because Exoplayer is missing support for some functionality, like SSA/ASS and PGS subtitles. Requiring any content with those subs to be transcoded.

I notice that a libVLC backend is an item on the #1057 player rewrite mega task list and wondered if that will bring an improved libVLC implementation, and if so, when?

If not are there plans to improve the libVLC implementation, or are you planning on focusing on an MPV implementation instead, which I think would also solve the use cases I have for libVLC?

[nielsvanvelzen]

The existing playback code is pretty much end-of-life. I do review/merge fixes for it but I'm not touching it myself nor do I support it. We see most issues arise from our LibVLC implementation which uses JNI bindings that are not always destroyed correctly causing memory leaks or crashes when the code attempts to use the instances after they are destroyed.

With the playback rewrite I'm working on the initial release will use ExoPlayer only. I can't say anything about if or when LibVLC / MPV will get implemented, but if they do; it will be a from-scratch implementation that's properly tested and maintainable.

[kura]

That makes sense, nobody likes supporting EoL code that is finicky. :) It also might explain the random crashes and odd behaviour I see with the libVLC implementation sometimes, like the client randomly crashing or when starting a new episode playback crashing and refusing to play anything until I reboot the Shield.

Sadly a libVLC or MPV implementation is something of a requirement for me currently. Unless ExoPlayer gets markedly better over the next few months and starts supporting features other players have supported for years.

Is the new playback implementation likely to be released with existing features like libVLC removed? I only started using the Android TV variant because I have an LG TV and the native LG video player doesn't support Dolby Vision content in an MKV container and I didn't want to remux everything. Depending on how the releases go, I may end up having to shuffle between WebOS client and Android TV client depending on what I want to watch. Or bite the bullet and remux DV content to MP4 container and stop using the Shield + Android TV client entirely. Or just switch to something like Kobi with the Jellyfin plugin, but I don't like the Kodi UI.

[nielsvanvelzen]

Is the new playback implementation likely to be released with existing features like libVLC removed?

The initial release (0.16) will only contain ExoPlayer but the rewritten code is only enabled for music. I don't know yet if the release that enables the rewrite for video will contain multiple backends or not. One of the goals with the rewrite is to transcode less often compared to the current implementation so if we need to add additional backends to support that goal we will.

[kura]

Good to know! Thanks for all the details, it's much appreciated. Good luck finishing up the rewrite.

Once that's done what are the odds of the focus shifting to making the UI look more like the web UI clients? :D

[nielsvanvelzen]

UI is on my "big list of things I want to rewrite". I'm slowly working on it already (The login screens in 0.12, the screensaver in 0.13, picture viewer in 0.15 and the new new screensaver recently merged for 0.16).
I'm mostly waiting for Jetpack Compose (the new UI framework for Android) to support TV navigation before doing more work on interactive UI.

[alannssantos]

There's this guy making and supporting an mpv library for the mobile app (findroid), I think it would be more interesting than libVLC.

https://github.com/jarnedemeulemeester/libmpv-android

thanks for everything