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