[vlc-devel] CIL bindings and brain dump on LibVLC
rem at videolan.org
Sun Oct 21 21:36:07 CEST 2007
If you read the commit logs, you would have noticed I added some preliminary
bindings for LibVLC for the Common Intermediary Language, in other words
DotNet. These are IN NO WAY a replacement for the ActiveX plugin, since these
do not provide an ActiveX plugin. However they do run where the ActiveX
won't - beyond Win32 - or would be suboptimal - any "managed" application.
This brought several issues to my mind.
First, I was badly confused with the old mediacontrol_ APIs still being there.
libvlc-control is now a nasty mess providing two competing APIs - in the same
shared object! Second, the mediacontrol_ ABI has been silently broken from
0.8.6 (contrary to the promise not to do so). I am considering reverting my
changes to mediacontrol, but that won't solve this problem. As such, I would
really consider REMOVING mediacontrol_ from 0.9.0 completely.
Now on the new LibVLC:
For the reference, CIL provides a grand total of six integers types, which
corresponds to the following C99 types: int8_t, int16_t, int32_t, int64_t and
intptr_t and bool. Note that "int" is not directly supported - I am currently
assuming it is int32_t, which works by far on most platforms (at least all
32-bits platform as well as x86_64). But it might break :-(
I am not too sure about bool. Within Win32, BOOL maps to 32-bits, but I
suspect gcc maps bool to 8-bits on the same Windows platform :-(
And then, same problem with enum, which compilers are free to map to any "big
enough" integer type.
It gets interesting when you consider that you cannot provide native "glue" C
code here, since it would defeat the whole CIL concept of "compile once, run
anywhere". In other words, any piece of code beyond libvlc-control is to be
compiled in CIL. So basically, anything that uses int may be somewhat broken,
and anything that uses bool or enum is somewhat more likely broken.
The other big problem I have had is the lack of reference counting on
libvlc_instance_t. The garbage collector ensures that any allocated
libvlc_instance_t will be released with libvlc_destory, but it cannot warrant
that any other dependent LibVLC object such as a media instance or a media
descriptor will not similarly be released *after* libvlc_instance_t... and
then, it does actually crash the whole process :-(
I would really prefer that libvlc_instance_t be reference counted, yield
whenever a dependant object is allocated, and released whenever it is
destroyed, so that it may survive beyond libvlc_destroy if needed. There is
support for reference counting the handle in CIL, but I think it would be
clumsy to do so.
Last topic is build system integration. As I already noted for other language
bindings, I suspect it would be a terrible idea to include these in the VLC
tarball and build these within the VLC build system. How likely are
distributors to add yet another big dependency (the whole .Net SDK or Mono)
to our monolithic build scripts? not much. Especially if I look at the
current state of binary packaging the Python and Java bindings...
Besides, thanks to "compile once run anywhere", there is no need to recompile
this for all platforms. Also, it does not at all depend on libvlc.h or
libvlc-control.la anyway, as CIL uses dlopen-style imports, with
CIL-translated function prototypes.
Then it all comes down to, where should the source code be stored?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the vlc-devel