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

Rémi Denis-Courmont remi at remlab.net
Tue Aug 18 15:57:02 CEST 2009

On Tue, 18 Aug 2009 14:26:58 +0200, Pierre d'Herbemont
<pdherbemont at gmail.com> wrote:
>>> - 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.
> This is fair. Yet, if we want to reuse one vlc object between two  
> instances (to be able to cache), is this something that could be  
> envisioned? That's something that makes me believe that using multiple  
> instance is weak. (more below)

Well, you cannot move objects across instance (the p_libvlc pointer would
get corrupted). That said, even reparenting objects (within an instance) is
problematic to this day: I think p_parent is not thread-safe.

> This is not so related. All the audio mixing is done by VLC. So each  
> audio configuration should be independent. Everything else is a bug.

Different players should not only have independent filtering, they should
also have independent outputs. Modern OSes have middleware (and/or
driver-level) support for mixing; we are also starting to see middleware
for audio policy (PulseAudio is moving in that direction). Mixing inputs
(other than down-mixing) is hence "bad". Also multiple players could have
different selected --aout configuration (e.g. independent WAVE file

> However the question of being able to reuse the same audio output  
> remains unanswered. We could think about something similar when trying  
> to stream two media player instances to the same video output  
> (mosaic), but with independent controls. I admit that this is  
> speculation.

Recycling the audio output makes sense within an input "context" (input
resource as it's currently called). I don't see the point across contexts.

>>> 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.
> This would be great, even if we don't chose to have multiple instance.  
> This choice has to be an implementation detail.

Well yeah. I don't really mind whether we remove multiple instances or
multiple LibVLC players per instance. But I think keeping both options
makes our implementation and usage needlessly complicated.

Rémi Denis-Courmont

More information about the vlc-devel mailing list