internship-report-vlc/chapters/other_bug_features.tex

\section{Description des missions}

Durant le stage et particulièrement au début, je me suis attaché à corriger des
bogues et ajouter des fonctionnalités mineures à certaines parties de VLC.
L'objectif de ces missions était pour la plupart d'entre elles d'apprendre le
fonctionnement de VLC.

Parmi ces missions, j'ai d'abord tenté de corriger un crash apparaissant lors de
la fermeture de VLC. Puis j'ai ajouté le support du format MPEG-2 dans le
décodeur hardware pour Android, alors que les brevets liés au format expiraient.
Ensuite, j'ai rajouté une solution de contournement pour les fichiers réalisés
avec un logiciel qui produisait un flux Matroska (mkv) invalide, mais restait
lisible par d'autres logiciels.
% TODO http://www.mpegla.com/main/programs/M2/Documents/m2-att1.pdf

Certaines parties du stage ne seront pas décrites dans ce document. Il s'agit
par exemple du support sur le forum dédié à VideoLAN, des communications avec
des acteurs externes à VideoLabs, les réunions et discussions effectuées autour
de différents thèmes venant la plupart du temps d'un des projets de ce document,
les tests manuels de l'application avant la sortie d'une nouvelle version
importante, ou bien les ajouts réellement mineurs liés à une demande
utilisateur.

\section{Tentative de correction d'un crash}

Cette mission fut ma toute première à VideoLabs. Arrivant légèrement en avance,
et après discussion sur l'environnement de travail et mon futur rôle de
stagiaire dans l'entreprise, on me demanda de compiler VLC pour me faire
patienter avant midi, puis ne suffisant pas je fus redirigé vers ce bogue.

% TODO: use after free ou double free ?
Après utilisation de \inltype{asan}, un outil de vérification intrusif des accès
mémoires, il s'avérait qu'un \og{}use-after-free\fg{} avait lieu dans le code de la
playlist VLC lors de la fermeture de l'application. N'ayant jamais utilisé Asan
auparavant, ce fut une excellente introduction à l'outil, mais ne m'a pas suffit
à déterminer la source du problème.

% TODO http://git.videolan.org/?p=vlc.git;a=commit;h=70174a131ac045b33a8db417e7c626ec67cb0f53

Le bug fut corrigé peu après par un autre développeur de l'entreprise, mais m'a
permis de commencer à savoir naviguer dans un code source conséquent tout en
faisant plus attention à mon environnement de débogage et de compilation,
particulièrement sous Archlinux.

\section{Ajout du support MPEG-2 dans MediaCodec}

Cet ajout de fonctionnalité fut le premier patch intégré dans la branche master
de VLC. Ce fut également le premier bug que j'ai pû écrire pour l'application.

D'un part, l'activation du format fut raisonnable simple et correspondait à
remplir un cas particulier dans un \inltype{switch}.

De l'autre part, il a fallu rajouter des fonctions pour parser le bytestream
entrant et extraire les informations de ratio d'aspect. Cette partie fut plus
complexe, dans un premier temps pour comprendre cette notion de ratio d'aspect
et les différences et interactions entre le ratio d'aspect source, le ratio
d'aspect écran et le ratio d'aspect définit par l'utilisateur. Néanmoins ces
informations-là m'ont servi plus tard pour aider à l'ajout de la gestion de
l'aspect ratio utilisateur dans la version iOS de l'application.

Ce passage fut également pour moi l'occasion de lire ma première norme liée au
multimédia, ici la norme DVD, tout en produisant mon premier patch utile pour
VLC. Ce fut également l'occasion de commencer à utiliser
\inltype{git send-email} en suivant les recommandations du wiki de
l'association.

Quant au bug introduit, il fut corrigé plusieurs mois plus tard, révélant la
difficulté de tester correctement VLC avec la diversité des formats, des
bytestreams et des éditeurs existant, en plus de poser des questions techniques
complexes vis-à-vis de la méthode de test.

\section{Contournement pour la lecture de fichiers matroska invalides}

Il arrive parfois que certains fichiers soient lisibles avec d'autres lecteurs
vidéos mais ne le soient pas avec VLC. Ce cas-ci s'est présenté à moi alors que
les lecteurs en question étaient bien plus simple et supportaient moins de
fonctionnalités.

Le fichier, une vidéo encodée en h264 muxée dans un format matroska, n'ayant
aucune caractéristique supplémentaire indiquant un manque de fonctionnalité j'ai
dû utiliser \inltype{gdb} pour savoir exactement quelle condition rejetait le
fichier. Le problème arrivait en particulier seulement sur le décodeur MediaCodec mais
pas avec le décodeur FFmpeg.

Après débogage, il apparu que c'était la fonction
\inltype{h264_helper_set_extra} qui renvoyait un \inltype{VLC_EGENERIC}.

Le bytestream h264 peut être présenté sous deux formats. Le premier, appelé
Annex B en référence à l'annexe de la norme le décrivant, consiste à séparer les
unités du format par un code spécial, étant ici \inltype{0x00 0x00 0x00 0x01}.
Ce code indique donc le début d'une nouvelle unité à décoder et est spécialement
adapté au streaming vidéo, où on peut commencer à recevoir le stream au milieu
d'une unité. Le second, avcC, précise des informations en début d'unité pour
indiquer où trouver la suivante.

La fonction \inltype{h264_helper_set_extra} se découpe selon le format: le
comportement changent selon si bytestream est de l'avcC ou de l'Annex B, et une
erreur est émise s'il ne s'agit d'aucun des deux. En affichant les quatres
premiers octets de chaque tampon mémoire reçu, j'ai alors vu que je recevais
systématiquement \inltype{0x01 0x00 0x00 0x01} et j'ai donc regardé les
informations et note de mise à jours liées au logiciel utilisé,
\inltype{mkvmerge}. J'ai finalement trouvé une information indiquant que le
premier octets du code de démarrage de l'Annex B, censé être réservé et définit
à zéro, était incorrectement définit à un.

%    demux:mkv: fix hvcC detection with mkvmerge
%
%    mkvmerge had an issue with the first reserved bits and fixed it in v16.0.0
%    in the commit 4bb8ad6f5565e87ad6d6a8e7e9d453e64985344e. Some files done
%    with anterior versions were not played by VLC with mediacodec.
%
%    See the changelog of mkvmerge for version 16.0.0, especially the
%    following:
%    * mkvmerge: HEVC/h.265: the generation of the HEVCC structure stored in
%      `CodecPrivate` was wrong in two places: 1. the position of the number of
%      sub-layers was swapped with reserved bits and 2. the VPS/SPS/PPS/SEI lists
%      did not start with a reserved 1 bit.
%
%    See also https://code.videolan.org/videolan/vlc-android/issues/466 for issue
%    and sample.

Je suis alors remonté jusqu'au demuxeur pour rajouter un test vérifiant le
logiciel utilisé pour muxer et la version de ce logiciel. Si il s'agit de
mkvmerge < 16.0, une correction du bytestream est désormais appliquée pour ne
plus poser de problème au niveau des décodeurs.

Cette résolution de bogue a été étrange pour moi sur la façon dont il a fallu le
résoudre, tout en me montrant deux points particulier. D'abord, supporter des
fichiers invalides peut donner lieu à plus de fichiers invalides et peut à terme
réduire les possibilités d'extension du format ou même son interopérabilité avec
des lecteurs faisant plus attention à la norme. Ensuite, les problèmes liés au
multimédia sont souvent causés par des formats peu compris, mal exploités ou
complètement invalide. Enfin, le patch que j'ai fait n'a finalement pas suffit
et d'autres occurences du problème ont eu lieu plus tard, donnant lieu à un
patch plus large et montrant une nouvelle fois la difficulté de tester le
logiciel sur tous les formats disponibles.