| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354 |
- \section{Gestion des blocs de données dans le pipeline}
- Lorsque l'on traite des données en streaming, on récupère la plupart du temps
- des tronçons de données. Dans VLC, ces tronçons sont annotés par des données
- multimédia : le dts et le pts par exemple, qui indique des instants pour le
- décodage et la présentation des images d'une vidéo. On verra son fonctionnement
- en détails dans la partie encodage matériel pour Android.
- Ce type de données est particulièrement présent dans le pipeline multimédia de
- VLC. On obtient des \inltype{block_t} après une lecture depuis un fichier ou le
- réseau, qui est transmis au \inltype{demux_t} qui va analyser et extraire
- différents flux audio, vidéo et sous-titre. Il crée un \inltype{block_t} pour
- chacune des unités correspondant au format de ces flux, on peut par exemple
- penser à une image pour un flux MJPEG. Ces blocs sont ensuite transmis au
- décodeur correspondant qui va créer la \inltype{picture_t} pour la vidéo, ou
- \inltype{subpicture_t} pour les sous-titres, ou \inltype{block_t} pour l'audio
- et la passer dans la chaîne de filtre pour l'envoyer à la sortie correspondante.
- Il faut désormais repenser à la situation de la sandbox et se souvenir que ces
- données-là vont devoir transiter d'un processus à l'autre de façon efficace. On
- va donc essayer de s'intéresser aux allocations effectuées par les modules et
- intégrer cette gestion en utilisant les mécanismes du système d'exploitation.
- Dans tous les cas, le système d'exploitation dispose d'un mécanisme de mémoire
- partagée pour dresser la correspondance de pages mémoires dans des processus
- différents. On peut donc essayer d'introduire des \inltype{block_t} alloués
- comme des mémoires partagées que l'on transmet de processus en processus.
- \section{Intégration avec la gestion des accès}
- Avec cette idée-là, la gestion de l'accès des processsus aux ressources devient
- cruciale. Il faut d'un côté pouvoir donner accès à ces données de façon
- performante, mais de l'autre côté offrir une isolation suffisante entre les
- processus. Il faut également pouvoir s'intégrer facilement dans le système
- d'envoi de message.
- Deux solutions sont alors envisagées. La première est de créer des blocs de
- mémoire sous forme de jetons d'accès dès lors qu'il y a création d'un nouveau
- bloc. Ces blocs peuvent donc être passés de façon indépendante, idéalement avec
- un paradigme \og{}fire\&forget\fg{} qui fera le transfert de l'appartenance du bloc d'un
- processus à l'autre. Avec cette méthode, il suffit de modifier les fonctions
- comme \inltype{block_Alloc}, presque aucune synchronisation supplémentaire n'est
- requise.
- La seconde solution est de créer un seul bloc de mémoire partagé entre les deux
- processus, puis de multiplexer l'accès dessus pour plusieurs blocs. Bien
- qu'étant plus compatible avec la plupart des systèmes ainsi que plus performant,
- cela implique des manipulations sur le tampon ainsi qu'une moins bonne isolation
- entre les modules, on préfèrera donc la première méthode dès lors qu'elle est
- possible à mettre en place.
- On pourra noter qu'il est également possible d'émuler l'accès à travers une IPC,
- en transférant directement les blocs dessus, mais on souhaitera éviter cette
- situation pour des raisons de performance.
|
