the big modules changes
gbazin at netcourrier.com
Wed Jul 31 21:58:26 CEST 2002
On Wednesday 31 July 2002 21:17, Samuel Hocevar wrote:
> Unfortunately I can't think of an easier way to do it, even with the
> new stuff. Maybe we could have a chroma meta-plugin whose goal would be
> to try several chroma plugins and build a chroma chain? That would solve
> multilevel chroma transform issues at least.
> But that would still leave us with the problem of the video output
> module being initialized before the chroma is even looked at, preventing
> us to chose the best combination. Maybe the meta plugin could work in
> the background and provide such a service to the video output? I don't
> really know...
hmmm, I'd like to know something else which could make my life easier
implementing this thing (when I'll have some time;).
I'd like to know if it could be reasonnable to assume that vlc will always
probe for existing plugins at load-time only and that the user shouldn't
remove or insert any new plugins during run-time (if he does we could just
I'm saying that because we could then get rid of:
/* Lock all selected modules */
p_tmp = p_first;
while( p_tmp != NULL )
LockModule( p_tmp->p_module );
p_tmp = p_tmp->p_next;
in src/misc/modules.c in module_Need().
That would speed up module spawning quite a bit.
But that would also allow us to easily pass lists or sub-lists of available
plugins to other modules requesting it (for instance video_output.c could
know the list of available chroma plugins without having to actually load
them into memory or take the module_bank.lock).
> Ah ah ah. As if I hadn't thought about that. Erm. Well, dummy, logger
> and null will probably go to a misc/ directory. As for SDL, the least
> ugly place would probably be in arch/, what do you think?
A misc category would surely be usefull for things like the logger plugin,
but for the others I guess it would be more sensible to split the plugins
into different directories corresponding to their categories. Most of them
are already splitted at the source file level anyway (like vout_dummy,
input_dummy etc...). For instance vout_dummy.c would go into
video/output/dummy, aout_dummy.c would go into audio/output/dummy and the
comman part dummy.c could go into misc or maybe common.
I guess it will be a little bit more difficult to integrate this in the
build system though.
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