[vlc-devel] Multiple instances and/or multiple players
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,
>> 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
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.
More information about the vlc-devel