|
|
@@ -1,3 +1,62 @@
|
|
|
+\section{Architecture de VLC}
|
|
|
+
|
|
|
+VLC est découpé en plusieurs parties. Deux parties ressortent particulièrement
|
|
|
+comme étant des bibliothèques charnières pour le fonctionnement du logiciel.
|
|
|
+D'un côté, les applications finales utilisent l'interface exposée par la
|
|
|
+LibVLC. L'objectif est d'avoir quelque chose de très haut niveau pour
|
|
|
+construire un pipeline sans avoir besoin des considérations techniques liées au
|
|
|
+multimédia.
|
|
|
+
|
|
|
+De l'autre LibVLC fonctionne à travers la LibVLCCore qui expose les fonctions
|
|
|
+bas niveau de chargement de module et contrôle les threads, les modules, les
|
|
|
+horloges, la liste de lecture et tout le contrôle bas niveau dans VLC. Les
|
|
|
+modules sont alors linkés à la LibVLCCore pour profiter des fonctions bas
|
|
|
+niveau.
|
|
|
+
|
|
|
+% Mettre schéma
|
|
|
+
|
|
|
+En résumé LibVLC expose l'API tandis que LibVLCCore réalise le lien entre les
|
|
|
+différents modules. La sélection des modules à utiliser est donc au cœur du
|
|
|
+développement de VLC, ce qui rend le core bien plus maintenable que les modules
|
|
|
+eux-mêmes.
|
|
|
+
|
|
|
+Il faut néanmoins noter que les modules sont chargés à partir du moment où un
|
|
|
+autre module le demande. C'est ce qui crée la notion de pipeline dynamique:
|
|
|
+seuls les modules apportant les fonctionnalités requises par un autre module
|
|
|
+sont injectés dans le pipeline. Ces modules sont alors chargés soit de façon
|
|
|
+statique, soit depuis une bibliothèque de code dynamique.
|
|
|
+
|
|
|
+Actuellement, le développement de VLC est beaucoup centré sur son approche
|
|
|
+multi-thread, par exemple pour que les décodeurs et les sorties fonctionnent de
|
|
|
+manière indépendante et correctement synchroniser le temps. Le décodeur et la
|
|
|
+sortie vidéo fonctionnent ainsi de manière asynchrone. L'idée centrale est
|
|
|
+qu'avoir plusieurs entrées en lecture et plusieurs sorties simultanément ne
|
|
|
+doit pas être impossible. Une démonstration de ce fonction a d'ailleurs été mis
|
|
|
+en place en tant que «VLM», qui permet de contrôler plusieurs flux en entrées
|
|
|
+et de choisir comment les utiliser en sortie; que ce soit en les diffusant, en
|
|
|
+créant une mosaïque ou en affichant des flux dans de nouvelles sorties.
|
|
|
+
|
|
|
+\section{Variables de configuration}
|
|
|
+
|
|
|
+La gestion de la configuration des modules dans VLC passe principalement par un
|
|
|
+système d'objet à travers le type \inltype{vlc_object_t}. Tous les modules de
|
|
|
+VLC sont représentés comme un \inltype{vlc_object_t} tout comme certains
|
|
|
+éléments du core et la LibVLC elle-même. Ces objets sont liés à un objet
|
|
|
+\inltype{libvlc_instance_t} particulier et sont agencés en arbre d'objet.
|
|
|
+
|
|
|
+On peut associer des variables à ces objets en leur faisant suivre certaines
|
|
|
+règles. On peut par exemple les créer avec une valeur par défaut, les créer sans
|
|
|
+leur donner de valeur ou bien les créer en les initialisant récursivement avec
|
|
|
+la valeur du parent.
|
|
|
+
|
|
|
+Ces variables portent ainsi une configuration qui est propre à eux, qui vient de
|
|
|
+la configuration imposée ou suggérée par leur parent, qui vient de la
|
|
|
+configuration donnée en ligne de commande ou qui vient du fichier de
|
|
|
+configuration de VLC. Il s'agit donc d'un mélange entre une interface
|
|
|
+utilisateur et une interface entre modules.
|
|
|
+
|
|
|
+\section{Modules}
|
|
|
+
|
|
|
Le principal de l'architecture actuelle de VLC est organisé autour de la notion
|
|
|
de module. D'un côté, le core contrôle le chargement des fonctionnalités et joue
|
|
|
un rôle d'orchestrateur. De l'autre côté chaque fonctionnalité est apportée par
|
