[vlc-devel] libvlc on windows

[Rémi Denis-Courmont]

On Sun, 13 May 2012 20:35:56 -0700, Mark Vejvoda
<mark_vejvoda at hotmail.com>
wrote:
> The bottom line is that libvlc either wants the plugins folder in the
> same folder as my binary or optionally it checks the VLC_PLUGIN_PATH
> environment variable.

That's not correct.

LibVLC searches plugins in the plugins/ subdirectory of the directory that
contains the libvlccore run-time, and in the directories specified
VLC_PLUGIN_PATH if set.

Setting VLC_PLUGIN_PATH really only makes sense when debugging (in fact,
VLC does use it for that purpose) or to add custom external plugins. For
normal use by an application, overriding the plugins path is a very bad
idea, due to the tight version coupling between libvlc and libvlccore, and
libvlccore and the plugins. Basically, there are only two sane approaches
to integrating LibVLC in an application:
- ship everything (libvlc, libvlcore, useful plugins and data), or
- ship nothing at all, not even libvlc and find the VLC installation.

In particular, shipping libvlc and possibly libvlccore is a recipe for
disaster. When the VLC installation is updated, the VLC plugins and
application run-time versions will not match and libvlc_new() will just
fail.

> Environment variable management is hideously evil on Windows.

'--plugin-path' was hideous and evil on all platforms, so that is an
improvement. On the ond hand, it did not work properly. On the other hand,
it was widely misused by developers that did not understand all of its
implications. I really do not miss it. Nevertheless, if someone wants to
bring it back, I am fine with that on two conditions:
- The code is not expected to be developed by me on my free time.
- Implementation is semantically correct (_unlike_ previously).

These conditions should be self-evident. But given the very high ratio of
whining-to-patch regarding LibVLC, it seems it is not so evident afterall.

> Googling endlessly I tried everything remotely possibly to
> get me code working, but nothing worked, i kept getting error from
> libvlc that it could not find plugins. Setting he env var manually in
> the command prompt DID work, but trying to control this within my
> application was impossible! Using VC++ and calling _putenv() only works
> on the current process, and by the time the binary loads, libvlc has
> already loaded during program ini and did not find the plugins.

LibVLC only initializes a few mutexes and such when it is loaded. It
definitely does not initialize the plugin bank. That would be far too slow
and risky for DllEntry().

Of course, lots of problems are to be expected with mismatched C
run-times. Calling convention problems and free() are much bigger problems
that putenv(). Don't use MSVC if you don't want that.

-- 
Rémi Denis-Courmont
Sent from my collocated server