libvlc and other changes

Samuel Hocevar sam at zoy.org
Tue Apr 30 16:59:31 CEST 2002


   I just wanted to let people know that my employer is interested in
embedding vlc into a browser plugin (first for Mozilla, and probably
IE a bit later), and I have been working on this task for the last two
weeks.

   To achieve this I decided to change the vlc core into a thread-safe
library, which was done by a/ splitting main() into init, run, stop,
etc. functions and b/ removing every global variable from the code. The
library is currently statically linked and I think it'll be a long time
before it's mature enough to be distributed as a shared library.

   This has a few uncomfortable consequences (p_main isn't available
from everywhere anymore, a few functions need additional arguments to
work properly), but IMHO it also means we now have a nicer design: every
major vlc "object" (p_aout, p_vout, p_input, p_module, p_decoder_fifo)
can be cast to a generic vlc_object_t which contains several common
variables:

    * boolean_t b_die, b_error for inter-thread communication
    * vlc_object_t *p_this to have a C++ish "this"
    * vlc_object_t *p_parent to keep track of the parent structure
    * vlc_t *p_vlc to keep track of the main structure

   Most of these properties are automatically set by the VLC_INIT_OBJECT
macro (see include/common.h). The purpose of p_parent is to allow for
tree-browsing of the whole structure, for instance to look for the
interface(s) or the decoder(s) attached to the current video output. I
think having a pp_children structure might be useful as well.


   I am not completely finished: the message bank is still a global
variable, and I didn't get rid of the p_*_bank approach (I merely put
the banks into p_main -- now called p_vlc), but this will be addressed
as well when I write the "look for parent interface" or "set b_die to 1
in all input threads" features.

   The libvlc functions are currently as follows:

    vlc_t * vlc_create( void );
    int vlc_init    ( vlc_t *p_vlc, int i_argc, char *ppsz_argv[] );
    int vlc_run     ( vlc_t *p_vlc, int i_mode );
    int vlc_stop    ( vlc_t *p_vlc );
    int vlc_end     ( vlc_t *p_vlc );
    int vlc_destroy ( vlc_t *p_vlc );

   This is just a consequence of the main() split, but we'll have to
think about a more complete API, which will allow actions such as "pause
playback", "add target XXX to playlist"... I'm not very smart with this
kind of things since I tend to only write things I will need, so any
discussions on the subject are welcome!

   For reference, here is the new vlc code (without error checks):

    #include <videolan/vlc.h>
    int main(int i_argc, char *ppsz_argv[]) {
        vlc_t * p_vlc = vlc_create();
        vlc_init(p_vlc, i_argc, ppsz_argv);
        vlc_run(p_vlc, 1); /* 1 means blocking mode */
        vlc_stop(p_vlc);
        vlc_end(p_vlc);
        vlc_destroy(p_vlc);
    }

   My Mozilla plugin does basically this:

    plugin_start() {
        plugin->p_vlc = vlc_create();
        vlc_init(plugin->p_vlc, i_argc, ppsz_argv);
        vlc_run(plugin->p_vlc, 0); /* 0 means run in the background */
    }

    plugin_manage() {
        vlc_do_flashy_boinky_boinky_stuff(plugin->p_vlc);
    }

    plugin_stop() {
        vlc_stop(plugin->p_vlc);
        vlc_end(plugin->p_vlc);
        vlc_destroy(plugin->p_vlc);
    }

   Another cool thing is that there are no real problems with having
several interfaces and several input threads now. Except that a/ there
is no placeholder yet in p_vlc for more than one p_intf pointer, and
b/ there is absolutely no way to have two separate threads running
gtk_main() without segfaulting, so I need to find a safety check against
this.

   I am not going to commit my changes immediately, because I certainly
broke the MacOS X and BeOS interfaces, and probably other things as
well, which will require some fixing. But if you want to have a look at
what it looks like for the moment:

    http://zoy.org/~sam/vlc/vlc-libvlc-20020430.tar.gz

   Comments are definitely appreciated.

Regards,
--
Sam.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>



More information about the vlc-devel mailing list