vlc-video: Fix some enum names

[meklu]

VLC 4 changes the respective names of libvlc_Ended and libvlc_MediaPlayerEndReached to libvlc_Stopping and libvlc_MediaPlayerStopping.

For reference, see this merge request from 2022
https://code.videolan.org/videolan/vlc/-/merge_requests/1565

Description

This change updates the enum names to correspond with VLC 4. Additionally, there's a small compatibility block for older versions.

Motivation and Context

With VLC 4, a couple of enum names have been changed, resulting in build failures when attempting to compile OBS against that version.

How Has This Been Tested?

This patch has been tested to compile against OBS 32.1.0 and a pre-release version of VLC 4.0.0 on a Gentoo Linux box of mine.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• I have read the contributing document.
• My code has been run through clang-format.
• My code follows the project's style guidelines
• My code is not on the master branch.
• My code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[pkviet]

see the discussion here:
#13322

[Chiitoo]

While compiling seems OK here too, the plug-in seems to only work with vlc-3 here.

With vlc-4:

error: os_dlopen(libvlc.so.5->libvlc.so.5): libvlc.so.5: cannot open shared object file: No such file or directory

[meklu]

Yeah, it's a major caveat that I didn't test for runtime woes at all. There was some more care taken in that aspect in the linked PR above.

[PatTheMav]

Thank you for the contribution, but we prefer getting in proper VLC 4 support (including testing, possible refactoring, and more) rather than just bolting on little bits and pieces to "get it to load".

IMO such an update would need fulfil the following requirements:

• VLC 4 is on a release track, i.e. it has reached RC status and a proper release is due soon.
• The implementation is end-to-end tested (all current functionality successfully tested against VLC 4 and VLC 3) and thus also "complete".
  • Specifically it should pass tests on Windows, macOS, and Linux. "It compiles" is not a test. 😉
• The current source is kinda long in the tooth already and I can spot at a glance multiple areas that should be refactored and brought up to current coding standards (reducing reliance on macros, better use of constants, splitting up of monolithic source files into logical translation units, use of platform-specific source files rather than macro slicing of function bodies, etc.)

For the time being OBS supports VLC 3, because that's what the module is built for. Just making it compile with VLC 4 present would create the reasonable expectation of users that VLC 4 is indeed officially supported by OBS, which is not the case and would just lead to unnecessary friction for end users.

[meklu]

@PatTheMav Sounds completely reasonable.

Digging into this a bit further the API has changed enough for there to have to be some actual logic adaptations rather than getting away with some simple renamed symbols. As an example: Just forcing the plugin to load the new shared object gives us the following

warning: [vlc-video]: Could not func VLC function libvlc_media_tracks_get, VLC loading failed

and the new API via libvlc_media(_player)?_get_tracklist has a different function signature and a neat new list type it returns rather than a **double_pointer_whatever.