[vlc-devel] [PATCH] Extensions and Lua dialogs

Pierre d'Herbemont pdherbemont at free.fr
Mon Dec 28 11:48:52 CET 2009

2009/12/27 Rémi Denis-Courmont <rem at videolan.org>:
> Le mercredi 23 décembre 2009, Jean-Philippe André a écrit :
>> Now it's time for me to submit the Extensions I've presented back
>> then.
>> For those who don't know what I'm talking about, here are some
>> presentations:
>> http://jpeg.dinauz.org/VideoLAN/presentations/extensions.pdf
>> http://jpeg.dinauz.org/VideoLAN/presentations/extensions2.pdf
> Maybe it's just me but... I'd like to learn from others.
> Firefox seems to have a lot of problems with (low-quality) extensions
> (including the VLC plugin :-( ). I'm afraid adding generic extensions
> will make it too easy to screw VLC up, and then guess who gets the
> bogus bug reports, and damaged reputation :/
> VLC ought to protect itself from crappy extensions. I don't know
> how "safe" LUA is. But I assume it's Turing complete, which means it
> can definitely dead lock and/or busy loop, and leak memory. Then, I'm
> afraid the only solution is to run extensions out-of-process, just
> like -I believe- Chrome does.

An tangential note. Mplayer on the Mac never seems to crash because
the UI and the video playback are in separate processes. The overhead
seems to be around 10% CPU here (playback at 30% for the mplayers and
20% for VLC here).

Were still seeing a hudge number of crash due to the contribs
upstream. I would says that it would be awesome to see a way to do map
everything that is being reading external data out of process. File
parsing, is Or have a vout that can display in out of process. We
would still have to figure out how to share the rest.

Having the extension running a second process seems like a good idea.
I guess that here extensions are less critical to be run
out-of-process since they require manual launching. (whereas firefox
extensions live within the life span of the browser)


More information about the vlc-devel mailing list