Pitivi 0.95 s’élance avec un nouveau moteur !

Peut‐être êtes‐vous, comme moi, amateur des dépêches qui retracent les coulisses du développement de nos logiciels préférés : ah ! les dépêches Sortie du noyau Linux X, LibreOffice Y : sous le capot, Entretien avec Z, développeur de Ω…

La sortie, le 19 novembre 2015, de la version 0.95 de Pitivi, logiciel libre de montage vidéo non linéaire pour GNU/Linux (prioritairement), nous donne l’occasion de revenir sur les coulisses de son développement, à travers deux billets dont nous vous proposons ici la traduction, précédée d’un résumé des épisodes précédents.

Sommaire

• Résumé des épisodes précédents
• La guerre contre les Deadlocks
  • Tl;dr
    • Morceaux choisis
    • Un schéma sinon rien
  • I - L’histoire de l’implémentation de notre nouveau mélangeur d’éléments thread‐safe
  • II - La réincarnation de GNonLin (l’autre millier de deadlocks)
• La suite : tester la nouvelle machinerie, contribuer au projet
  • Essayer la nouvelle version (et celles en développement) en un clic
  • Contribuer

Résumé des épisodes précédents

Depuis sa naissance en 2004, Pitivi a connu de nombreuses réécritures : c’est que tout restait encore à inventer (à part GStreamer, mais qui n’était alors ni aussi performant ni aussi complet qu’aujourd’hui).

Si vous le voulez bien, avançons à présent dans le temps de sept années pour nous concentrer sur la période récente du projet. C’est le 27 septembre 2011 que sort la version 0.15, dernière (j’omets volontairement quelques versions de maintenance) avant le Grand changement, à savoir l’intégration de GES (GStreamer Editing Services), qui explique l’impressionnant « trou » dans la chronologie du développement du logiciel entre 2011 et 2013, comme on le peut voir ci‐dessous (et accessoirement la création, dans le wiki officiel, d’une page sous‐titrée avec humour « rumors of our death have been greatly exagerated… ») :

GES remplit plusieurs objectifs, parmi lesquels :

• résoudre un certain nombre de problèmes structurels concernant l’édition non linéaire avec GStreamer ;
• simplifier le développement de Pitivi (le portage vers GES a permis de supprimer plus de 20 000 lignes de code de Pitivi et de clairement séparer ce qui relève de l’interface de ce qui relève du moteur ; le niveau de connaissance de GStreamer nécessaire pour contribuer à Pitivi a pu être grandement abaissé) ;
• améliorer les performances de Pitivi.

Accessoirement, l’allègement du code de Pitivi a permis de réaliser le chantier de sa simplification. Traduit de la plume de Jean‐François Fortin‐Tam, un des mainteneurs : « Je suis très content : cela signifie que non seulement les nouveaux contributeurs pourront plus facilement mettre le pied à l’étrier, mais aussi que les contributeurs réguliers ne se perdront plus dans les différents modules. »

En mai 2012, le portage de Pitivi sur GES est réalisé dans l’arbre de développement…

Mais la route est encore longue jusqu’à la publication d’une version suffisamment aboutie ! En effet, l’équipe doit relever d’autres challenges dans le même temps, comme de devoir passer simultanément à Python 3.x, GTK+ 3.x et GStreamer 1.x, excusez du peu. Notamment, GNonLin, la bibliothèque logicielle sur laquelle GES lui‐même repose, doit être portée sur GStreamer 1.x, ce qui s’avère être un défi particulièrement difficile.

Le 29 septembre 2013, la sortie de la version 0.91 concrétise — enfin ! — l’immense travail mené depuis 2011 pour ré‐architecturer le logiciel (la version 0.92 sort deux mois après, pour apporter quelques corrections).

Mars 2014 voit fleurir la version 0.93, suivie de la 0.94 en novembre 2014, avec leur lot non négligeable de corrections.

Tout ce travail étant réalisé par un petit groupe de développeurs sur leur temps libre, est lancée fin février 2014 une campagne de financement participatif (toujours en cours !), sous l’égide de la Fondation GNOME et avec le soutien du projet GStreamer, qui doit permettre de financer à temps plein et pendant un an les deux développeurs bas niveau du projet (Mathieu Duponchelle et Thibault Saunier), afin d’accélérer le rythme de développement du projet.
Une réussite en demi‐teinte de la campagne ne permet hélas pas de mobiliser ces développeurs aussi complètement qu’espéré, mais permet toutefois quelques avancées importantes, dont celles qui vont vous être narrées ci‐après — et je ne vous ai pas parlé du remplacement de GooCanvas par Clutter puis finalement par du pur GTK+ pour le dessin de la piste de montage, ni du passage de glimagesink à gtk(gl)sink pour alimenter le moniteur de prévisualisation, ou du travail réalisé sur GStreamer, y compris pour corriger la prise en charge du format MPEG-TS qui sert de base au format AVCHD et à la télévision numérique terrestre…

La guerre contre les Deadlocks

Tl;dr

Morceaux choisis

Morceaux traduits issus de ce billet de Jean‐François Fortin‐Tam.

« Mathieu Duponchelle et Thibault Saunier ont travaillé sur le mélangeur vidéo de GStreamer, en gros en réalisant une refonte complète de notre pile de mixage et en rendant la bête thread‐safe… Cela devrait corriger un grand nombre de blocages (en VO : deadlocks) en rapport avec le mixage vidéo, qui sabotaient notre expérience utilisateur avec des paralysies fréquentes. »

« Ensuite ils ont presque complètement réécrit GNonLin avec une conception différente et plus simple, et il a été intégré directement dans GES (GStreamer Editing Services) sous un nouveau nom : NLE (Non Linear Engine). Avec NLE dans GES, les blocages venant de GNonLin devraient appartenir au passé ; le défilement de la vidéo devrait être bien plus fiable et ne plus être la cause de paralysies comme précédemment. Cela reste un considérable morceau de code : on parle d’environ 6 000 lignes de nouveau code dans GES. »

Un schéma sinon rien

L’architecture révisée de Pitivi 0.95 :

I - L’histoire de l’implémentation de notre nouveau mélangeur d’éléments thread‐safe

ou : La guerre contre les Deadlocks, première partie.

[Article original : The War Against Deadlocks, part 1: The story of our new thread‐safe mixing elements implementation]

Par Jean‐François Fortin‐Tam, le 11 juin 2015.

Laissez‐moi vous raconter une histoire qui fut perdue et oubliée sur le champ de bataille du développement de Pitivi à l’automne dernier, un manuscrit que j’ai rescapé d’un grimoire moisi dans un champ rocailleux. Selon mes données historiques, l’auteur était un certain Dorian Leger, un messager français porté disparu aux alentours de Paris.

Le grimoire moisi, tel que je l’ai trouvé

Je prends la liberté d’altérer assez substantiellement ce manuscrit dans le but d’en clarifier certaines parties tout en rétablissant ses intentions et son style au regard du contexte historique. Cela fera office de première partie à ce récit épique (la deuxième partie reste à écrire ; elle fera l’objet du prochain billet qui aura probablement un style d’écriture plus « moderne ») concernant notre guerre contre les Deadlocks, de viles créatures qui ont menacé la stabilité de notre application bien trop longtemps. Techniquement, nous avons toujours été en guerre contre l’Estasia les Deadlocks ; c’était déjà le cas avec notre version 0.13.2, à une époque où une équipe différente de mainteneurs parcourait cette terre.

Les précédents mainteneurs combattant les Fomoires, du temps de GStreamer 0.8 et 0.10

« Paris, le vingt‐huit septembre MMXIV.

Chers partisans du Front de Libération de l’Édition Vidéo,

Au cours du dernier mois et demi, nous avons fait de grands progrès en déboguant et réécrivant une importante brique logicielle sur laquelle Pitivi s’appuie. La 0.94 est désormais prévue pour les prochaines semaines. Au sujet d’une pièce importante en développement pour cette version, Mathieu Duponchelle explique : « Nous avons arraché de GStreamer un gros morceau de code rongé par les bogues et l’avons remplacé par un tout nouveau mélangeur vidéo que nous pouvons finalement montrer avec fierté et confiance. Il sera d’une aide immense dans notre combat contre les Deadlocks ; avec un peu de chance, il permettra enfin un défilement stable et sans bogue de la vidéo le long de la piste de montage. »

En effet, j’ai entendu des histoires au sujet de précédentes versions de Pitivi qui plantaient invariablement lorsque l’on faisait défiler la vidéo à l’endroit d’un fondu enchaîné entre deux séquences. En d’autres termes, lorsque l’on essayait de sélectionner une image qui contenait un fondu enchaîné, Pitivi se paralysait et devait être achevé par l’utilisateur. Inutile de dire que ce bogue détruisait non seulement l’expérience utilisateur mais aussi le moral de nos troupes, et qu’il devait être réglé aussi rapidement et efficacement que possible.

Le problème technique derrière cette nuisance était un puissant équipement de l’arsenal de GStreamer : le mélangeur vidéo GstElement. Cet engin essayait de gérer avec des threads d’autres éléments qui lui étaient balancés, ce qui était par nature extrêmement complexe et sujet à erreurs ; au point que certains ont dit que ce devait être le travail du Diable lui‐même.

Lorsque nous avons examiné la machine, nous avons découvert le diagramme ci‐dessus. La transcription des étranges écritures figurant dans ce diagramme ont conduit à l’interprétation suivante de son fonctionnement :

« Pour fayre cette machine besogner, voyci céans des tampons affluant de tous les sinkpads dans moult lacets. Tu languiras donc que tous les pads rapportent tampon pour deviser de mixer et mander le résultat au srcpad. Tu pousseras ainsy les tampons à partir du lacet dont tu reçusses le dernier tampon. Garde‐toi de te tenir devant la machine lorsque tu l’actionneras. » — Dante, fils de Sparda. ¹

Le multithreading, si vous avez en mémoire vos cours chez les moines Shaolin, est un art difficile à maîtriser. Il permet de faire tourner des opérations de traitement multimédia en arrière‐plan et d’exécuter plusieurs tâches simultanément. Une approche multithread est essentielle pour nous, mais requiert une gestion laborieuse des variables partagées par différents threads (lesquelles décrivent généralement des données audio et vidéo dans le cas de GstElement, la machine qui sert de mélangeur vidéo). Comme des threads simultanés opèrent souvent sur la même variable, le développeur de la bibliothèque logicielle, expert en langage C, doit s’assurer que ces threads n’éditent pas simultanément une même variable en organisant précautionneusement la façon dont les threads se donnent chacun le signal d’éditer une variable.

Pour ce qui est de l’étrange machine qui causait ces problèmes, nous l’avons détruite par le feu et reconstruite, avec en tête l’harmonie et la simplicité. Je ne peux l’affirmer complètement mais on m’a rapporté que plus de dix mille lignes de l’ancien code ont été réécrites grâce à l’art exquis du kung‐fu multithread. La nouvelle machine qui sert de mélangeur vidéo a dorénavant le srcpad opérant sur son propre thread, et nous agrégeons et adressons les tampons au srcpad à partir de ce thread. Cette technique nous rend bien plus forts contre les Deadlocks. »

Comme vous vous en êtes certainement rendus compte vous‐mêmes, les versions précédentes de Pitivi — particulièrement à cause des éléments de mixage dans GStreamer — étaient infestées de bogues qui forçaient les threads à s’attendre indéfiniment. Pour mieux se figurer la chose, prenons une analogie moderne : l’implémentation précédente du mélangeur vidéo était comme une ville pleine de voitures à des carrefours équipés de panneaux stop, chaque voiture attendant que l’autre démarre, causant un embouteillage sans fin derrière elles. La bonne nouvelle est qu’après la réécriture de plus de 10 000 lignes de code, les panneaux stop ont été remplacés par un système bien plus simple et fiable dans la 0.94, ce qui veut dire que les threads de notre mélangeur vidéo sont maintenant harmonisés, et que ce dernier est maintenant « exempt de bogues ». Cela a demandé une réécriture complète de notre pile de mixage (par l’écriture d’une nouvelle baseclass pour remplacer collectpads2). Ce fut un processus assez prenant.

Nous sommes assez contents de ce que nous avons accompli ici, mais les Deadlocks ne sont pas si facilement vaincus, et l’histoire ne s’arrête pas là. Le reste du manuscrit est assez court et consiste essentiellement en des prédictions d’événements survenus depuis, que je couvrirai dans un prochain billet, quand je trouverai plus de temps, car cela demande d’avantage d’analyse et de développement.

II - La réincarnation de GNonLin (l’autre millier de deadlocks)

ou : La guerre contre les Deadlocks, deuxième partie.

[Article original : The War Against Deadlocks, part 2: GNonLin’s reincarnation (the other thousand Deadlocks)]

Par Alexandru Băluț, le 15 octobre 2015.

GNonLin a servi notre cause honorablement pendant plusieurs années, mais a conservé d’indélébiles marques de l’Ancien temps. Nous avons été de plus en plus ennuyés par les liens notoires qu’entretenait GNonLin avec les Deadlocks, au point qu’il était connu au sein de notre bataillon comme étant « le Baron des Deadlocks ». Nous avons essayé de le raisonner, de discuter avec lui, mais, hélas, nous n’avons obtenu que des erreurs de CAPS « non négocié ».
Une intervention rapide eut lieu. Le baron fut capturé et nous lui avons appliqué un mélange d’intense persuasion et d’alchimie jusqu’à ce qu’il renonce à ses liens douteux et renaisse. L’arrivée du greffon Non Linear Engine (NLE) apporta beaucoup de joie dans le comté. Les utilisateurs n’étaient plus harcelés par des Deadlocks renégats lorsqu’ils déroulaient tranquillement leur piste de montage. Les Deadlocks pourraient bien continuer à nous hanter, mais nous voilà dans une Nouvelle Ère, dans laquelle les vieilles ruses n’auront plus d’effet sur nous.

La capture du Baron (instantané)

De la plume des développeurs :

« Nous avons réutilisé des portions du greffon videomixer pour créer un greffon compositor qui, lui, est thread‐safe. Le nouveau greffon compositor est d’ores et déjà utilisé par un bon nombre d’applications multimédia. Simultanément nous avons créé une nouvelle classe de base qui a facilité la réécriture du greffon audiomixer pour corriger ses défauts et le rendre thread‐safe. Ce qui nous a permis de passer du greffon adder au greffon audiomixer.

Comme vous le savez sans doute, les greffons GStreamer sont utilisés pour créer des pipelines, par exemple : (video1 * effect1) + video2 = x. Le greffon compositor implémente le + dans cette équation. Un pipeline est utilisé par NLE pour jouer un projet vidéo. NleComposition convertit dynamiquement la piste de montage d’un projet en un pipeline GStreamer, en tenant compte de la position actuelle :

Nous venons de terminer le remplacement de GNonLin par Non Linear Engine. Cela signifie que la composition utilise à présent un thread maître pour configurer (délier, relier) le pipeline ; précédemment, l’ancien procédé de composition le faisait à la fois du thread de streaming et du thread de seeking, ce qui engendrait une foule de Deadlocks en colère (« la légion de l’autre millier »). De plus, dans l’état PAUSED nous devions avoir précédemment dans la composition tous les éléments de la totalité de la piste de montage, ce qui signifie qu’il y avait tellement, oui tellement, de threads inutiles, créés et attendant comme des bonshommes de neige ; tandis qu’à présent les éléments ne sont créés que lorsque le pipeline en a besoin, et sont conservés dans l’état READY jusqu’à ce qu’ils soient effectivement utilisés par le pipeline. »

Longue vie au Non Linear Engine !

La suite : tester la nouvelle machinerie, contribuer au projet

Essayer la nouvelle version (et celles en développement) en un clic

Dans le cadre de l’effort fourni pour la campagne de financement, l’équipe de développement met à disposition des versions compilées de la journée, sous forme d’archives qui comprennent toutes les dépendances nécessaires (permettant de lancer le logiciel isolément de votre système, et donc potentiellement sur n’importe quel système, sans avoir à attendre les nouvelles versions des dépendances pour votre distribution, telles que GStreamer, etc.).

• Télécharger le daily bundle.

Contribuer

Comme vous l’aurez compris à la lecture du résumé préliminaire, tout est fait pour faciliter les contributions en code (note : Pitivi est écrit en langage Python).

Les contributions peuvent également consister à :

• rédiger de la documentation ou des traductions ;
• effectuer des tests du logiciel pour en rapporter les bogues aux développeurs (surtout si vous rencontrez encore des paralysies ou plantages, faites‐les remonter aux développeurs qui sont demandeurs : il leur est matériellement impossible de tester seuls tous les cas de figure !) ;
• soutenir financièrement le projet ;
• etc.

Cela démarre ici :

• page d’entrée du wiki pour contribuer ;
• comment rapporter un bogue (voir aussi la liste des bogues ouverts) ;
• soutenir financièrement le projet.

Les frimousses des principaux membres actuels de l’équipe derrière Pitivi et GES, que vous pourrez croiser sur IRC (#pitivi sur Freenode), où ils sont très présents :

(de gauche à droite : Mathieu Duponchelle, Thibault Saunier, Jean‐François Fortin‐Tam et Alexandru Băluț).

Maintenant, c’est à vous de jouer !

Aller plus loin

• Annonce de la version 0.95 — blogue de Jean‐François Fortin-Tam (407 clics)
• Donner pour soutenir le projet — fundraiser.pitivi.org (126 clics)
• Suivre l’actualité du projet — Planet Pitivi (144 clics)
• Suivre l’actualité du projet — Twitter (92 clics)
• Suivre l’actualité du projet — Google+ (86 clics)
• Article sur Pitivi — Wikipédia (279 clics)
• Article sur GStreamer — Wikipédia (102 clics)
• Les bases de Pitivi (tutoriel) — Libre et ouvert (319 clics)