[vlc-devel] var_Set returns variable not found
jboileau at gmail.com
Mon May 5 20:26:29 CEST 2008
Thanks for the info guys!
Pierre: I have tried creating the variable first and now the return
code for var_Set is 0. But unfortunatly the marquee text does not
change. I have done like this:
var_Create( Plugin, "marq-marquee", VLC_VAR_STRING | VLC_VAR_DOINHERIT);
Olivier: As you can see I am a bit stuborn. :-) Yes I did read
comments about vlc_object not being accessible but felt I was getting
near success so I did try anyway. I thought that if I could get a
handle to one vlc_object, the main one probably, (which I believe I
was successful at) I could use the API to navigate where I needed to
go. I will take a look at MediaControl as you suggest, although my
application is already built using the libvlc_media_... interface from
Yes, it would be nice to have a little more rope, even if it meant
danger. I can more easily deal with danger than frustration at not
being able to do what I need. Although I do understand the logic of
shielding us from internal API not meant to be exposed.
If all else fails, is there a way to build an application using the
VLC source code directly without going through libvlc and
libvlc-control? This does not seem to be a trivial task though.
On Mon, May 5, 2008 at 1:25 PM, Olivier Aubert
<olivier.aubert at liris.cnrs.fr> wrote:
> As I previously indicated, the libvlc API is basically a wrapper around
> the internal VLC objects, and both worlds are isolated. You can consider
> the vlc_object structure as internal to VLC, and not accessible to 3rd
> party apps using libvlc. Except of course if you compile code that is
> part of VLC, such as a plugin.
> To achieve your specific goal here, you can use the MediaControl
> display_text API. In python (easily translatatble to C) :
> mc=vlc.MediaControl() # You can also pass an existing vlc_instance object
> mc.playlist_add_item('foo.mpg') # In current SVN, it is now mc.set_mrl('foo.mpg')
> mc.display_text("Jacques Boileau", 0, 5000)
> but I agree that libvlc should not be so watertight, to allow more
> experimentations, and provide some means to access at least variables
> for named objects. But the libvlc API would then become less safe, i.e.
> you would have plenty of rope to hang yourself. Pierre is the person to
> hassle for this (I wrote the mediacontrol API, and not the libvlc one).
> On a side note: there once was python bindings for the internal VLC
> object system, but it is not working anymore since more checks have been
> added to prevent the use of vlc_object_* functions.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel