[vlc-devel] Multiple instances and/or multiple players

[Rémi Denis-Courmont]

On Tue, 18 Aug 2009 12:39:14 +0200, Pierre d'Herbemont
<pdherbemont at gmail.com> wrote:
> A few things come to my mind:
> - multiple instances is not something that is being tested a lot in VLC.

Neither are multiple players.

> - I am a bit candid here, but what is the effective performance  
> impact? do you have any numbers?

It consumes a little bit more memory, although this is in great due the
unused playlist. The module directory has to be browsed if you destroy
*all* instances _then_ create a new one. That said this cost is also
present if libvlc is instanciated only when one (or more) player is needed.
If we want to optimize it away, I would rather have a pair of void(*)(void)
function that increase the reference count of the module cache (kind of
like WSAStartup/WSACleanup on Windows), than use
libvlc_new()/libvlc_release().

> - Do we want to allow sharing of input item between different  
> instance? How much do we want to make sure we can share between two  
> instances?

Do input items reference anything external anyway? They are not even VLC
objects.

> - Cache: All cached data will be into globals? How do you plan to  
> flush caches? AFAIK this was the only goal of libvlc_new,  
> libvlc_release.

The module cache is already implicitly shared across all instances, and
-this is a bug- so is the configuration.

> - Having multiple audio output could be problematic in some platform,  
> and doing audio mixing ourselves is then a great plus. How do you do  
> that with one instance?

Having a *single* audio output sucks. As Brezhoneg pointed out, you cannot
configure the audio per input as a consequence of this mis-design. I was
planning to have per-input audio outputs regardless - if we keep multiple
player per instances.

> That said, this is an implementation details, how do you plan to  
> reflect that on the API?

Basically, we could merge instance and player types, and simplify quite a
bunch of stuff.

-- 
Rémi Denis-Courmont