\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.
