La dernière dépêche sur le jeu Unvanquished a été publiée ici en 2023, pour son dixième anniversaire. La dernière version annoncée ici était la version 0.53, en 2022. Alors que nous sommes à deux mois de 2025 et à quelques jours de la prochaine version 0.55, c’est l’occasion de faire un point sur ce qui s’est passé ces dernières années et d’ajouter un épisode à la série « des nouvelles de [votre jeu préféré] » et de faire suite à celui sur Xonotic.

Laisse-moi sortir de là ! — réclame la version 0.55…

Unvanquished est un jeu de stratégie en temps réel (RTS) à la première personne (FPS) où des extraterrestres évolutifs et des humains lourdement armés s’affrontent pour leur survie. Son développement, basé sur Tremulous, a commencé en 2011.

Sommaire

• Quelques nouvelles en vrac
  • Un nouveau lanceur
  • Des améliorations graphiques
  • Un explorateur de serveur minimaliste
  • Des vidéos et un compte Mastodon
• Unvanquished, ARMé et dangereux
  • De nouvelles architectures
  • Interface, jouabilité et bots
  • La danse des submodules
  • Contributions
  • Des traductions !
• La 0.55 arrive !

Quelques nouvelles en vrac

Un nouveau lanceur

En prévision de la prochaine version 0.55 qui arrive (deux « release candidates » ont déjà été publiées), le « lanceur » (aussi appelé « updater ») a été mis à jour en juillet dernier.

Le lanceur est le moyen recommandé d’installer Unvanquished : il permet une intégration optimale avec le système (possibilité de cliquer sur des liens pour lancer une partie) et propose la mise à jour du jeu quand une nouvelle version est disponible. Le lanceur sait aussi se mettre à jour et c’est ce qui a été fait en juillet.

Des améliorations graphiques

L’année dernière le projet Unvanquished avait annoncé être en recherche d’un développeur spécialisé dans les moteurs de rendus. Reaper a rejoint l’équipe et a réalisé un gros travail : débugage et finalisation des miroirs récursifs et d’autres choses. Il fait aussi progresser le moteur pour tirer partie d’OpenGL 4.6 et autre techniques avancées (« bindless textures », etc.).

Un explorateur de serveur minimaliste

Viech a publié un explorateur de serveur de jeu minimaliste qui tient dans la barre de notification (tray browser). C’est à la fois simple et pratique.

Des vidéos et un compte Mastodon

Diverses vidéo montrant les avancées du développement ont été publiées sur la chaîne Youtube d’Unvanquished, c’est l’occasion de rappeler l’existence de cette chaîne : https://www.youtube.com/@UNVofficial

Pour ceux qui préfèrent Peertube, qui permet aussi de s’abonner aux chaînes à travers Mastodon et plus globalement le Fédiverse, avec la publication de certaines parties : https://vdo.unvanquished.greboca.com/

Un compte Mastodon a été créé sur l’instance idtech.space dédiée aux technologies id Tech et projets associés (le moteur d’Unvanquished dérive d’id Tech 3) : https://idtech.space/users/UNVofficial

Ce compte Mastodon s’ajoute aux comptes X et Facebook. Le public libriste sera peut-être plus intéressé par ce compte Mastodon.

Unvanquished, ARMé et dangereux

De nouvelles architectures

La version 0.54 de Unvanquished sortie en janvier 2023 avait été la première à être jouable autrement que sur PC (x86 et x86-64), en proposant des binaires pour les processeurs ARM (sous Linux seulement pour l’instant).

Côté moteur la version 0.54 avait reçu de nombreuses optimisations pour mieux tourner sur des machines moins performances, par exemple, Certaines ressources logiciels optionnelles comme les deluxemaps ne sont plus chargées si désactivées, ceci économise non seulement le calcul, mais aussi la mémoire de la carte graphique. Les lightstyles peuvent être désactivés, ce qui peut accélérer le rendu graphique, etc. La compatibilité matérielle sera encore étendue avec la version 0.55.

À partir de la version 0.54 tous les binaires pour toutes les architectures matérielles et systèmes d’exploitation sont compilés dans des containers Docker, y compris les binaires macOS compilés dans un container Linux en utilisant Darling, Darling étant à macOS ce que Wine est à Windows. La version 0.55 sera produite de la même manière.

La version 0.55 apportera la compatibilité pour un nouveau système d’exploitation ! 🤫️

Interface, jouabilité et bots

Le nouvel écran de chargement des cartes.

L’interface avait été revue à l’occasion de la version 0.54 :

• Nouvelles icônes d’inventaire contribuées par Nanaa, Gireen et Bob Vador
  Ces icônes donnent un coup de fraîcheur, on distingue mieux les deux types de grenades et les armures ainsi que le mode de déplacement.
• L’écran de chargement des cartes affiche le nom de la carte et des auteurs (si renseigné) depuis les métadonnées. Historiquement, les artistes inscrivaient ces informations sur l’image d’illustration de la carte avec un logiciel de dessin… (!!!)
• La version 0.55 apportera des modifications d’interface réalisées par Grise.

Côté jouabilité, la version 0.54 avait corrigé le momentum négatif qui était particulièrement pénalisant. Le momentum, est généré par les Leech (Alien) ou les Drills (Humain). Il faut qu’il y ait assez de momentum pour pouvoir construire d’autres éléments.

La version 0.54 a apporté toute une série de nouveautés au niveau des bots (entités qui remplacent les joueurs afin de compléter les équipes) :

• Amélioration de l’évitement d’obstacles pour les bots.
• Les bots peuvent viser des cibles situées sur des navmesh différents.
• Certains bots n’hésiteront pas à sauter pour atteindre une cible en hauteur, d’autres se retiennent d’exécuter une attaque qui pourraient les blesser si la cible est trop proche…

Depuis quelque temps, le développement des bots suscite un regain d’intérêt. La version 0.55 ne sera pas la plus riche à ce sujet car elle apportera surtout des améliorations du moteur. Le développement de gameplay ne s’est pas ralenti mais s’est surtout focalisé sur des mods dont il faudra fusionner les avancées dans le tronc commun après la sortie de la version 0.55. Ces améliorations de gameplay sont déjà jouables sur des serveurs en ligne.

L’amélioration du comportement des bots à permis un nouveau type de jeu : Le PVE. C’est à dire que les joueurs peuvent jouer ensemble contre l’ennemi piloté par le serveur. Certaines cartes ont été créées spécifiquement pour ce type de jeu, et d’autres ont été adaptées à l’aide de layout qui étaient déjà utilisés pour créer des variantes de parties.

La version 0.54.1 n’avait pas vraiment proposé de modifications des données, il s’agissait surtout de publier des correctifs de bugs gênant du moteur. La version 0.55 viendra avec une mise à jour des données et donc avec les corrections attendues. Par exemple un bug dans la chaîne logicielle de conversion d’images avait produit des artefacts dans certaines textures, ce sera corrigé dans la version 0.55.

La danse des submodules

            _________________
           /                 \
          |         ✝         |  
          |                   |
          |      beloved      |
          |     submodule     |
          |                   |
          |    2017-12-30     |
          |     2023-04-11    |
          |                   |
          |       R.I.P.      |
          |                   |  🄵
  (,,)é   |                   |   ɘ̀(⹁⹁)  ɘ̀(⹁⹁)
////////////////////////////////////////////////

Press F to Pay Respects!

Tous ceux qui doivent traiter avec Git savent que les submodules sont très pratiques mais parfois bien ennuyeux. Un travail de fond réalisé sur les outils de production des données a permis la réintégration du dossier source unvanquished_src.dpkdir. Le générateur de code CBSE qui produit la plomberie pour la logique de jeu a été réintégré aussi. Cela rend plus facile de travailler sur des mods en évitant de devoir gérer plusieurs dépôts différents.

Contributions

Voulez-vous en savoir plus ?

Comme vous le voyez, ce cycle de développement a aussi vu de nouveaux contributeurs apporter leur concours au projet. Certaines de leurs améliorations ont déjà été publiées dans la version mineure 0.54.1, d’autres arriveront avec la version 0.55.

Récement, le développeur Slipher qui est un des développeurs Unvanquished les plus prolifiques et les plus fidèles a étendu ses activités au moteur de rendu et a rejoint la petite élite de ceux qui savent comment le moteur fonctionne. Il a corrigé entre autre le rendu de vidéo sur des surfaces et une fonctionnalité de sprites.

La liste de régressions depuis le désormais lointain ancêtre d’Unvanquished, Tremulous, est maintenant réduite à peau de chagrin.

Des traductions !

La grosse nouveauté de la version 0.54.1 publiée en décembre 2023 a été de proposer à nouveau des traductions intégrées au jeu. L’outil de traduction est gracieuseuement hébergé par Weblate.

L’interface de traduction Weblate.

Il y a longtemps, le jeu était traduit, mais suite à de très profonds changements (par exemple le remplacement total de la technologie utilisée pour faire des menus, désormais sous RmlUi), l’effort de traduction avait été interrompu.

La traduction francophone est bien avancée, mais la traduction en breton a besoin de plus de contributions. Si vous souhaitez contribuer votre langue régionale, vous êtes les bienvenus, c’est ici que cela se passe !

La 0.55 arrive !

Préparez votre souris et votre clavier, la version 0.55 arrive très bientôt.

Le festival Pas Sage En Seine (société, internet, liberté) a eu du 31 mai au 2 juin 2024. Les vidéos ont été publiées (annonce des vidéos April).

L'April a publié treize transcriptions au mois de mai 2024, ce qui correspond à dix heures et trois minutes d’enregistrements audio ou de vidéos.

La « conférence pour l'éthique et la diversité dans la tech avec des crêpes et du cœur » MiXiT a eu lieu en avril. Les vidéos ont été publiées (une sélection par Frédéric Couchet).

L'OW2con 2024 a eu lieu les 11 et 12 juin 2024. Les vidéos ne sont pas encore disponibles (voir celles de 2023). Mise à jour : les vidéos 2024 sont désormais disponibles

L’initiative IIIF, pour International Image Interoperability Framework, est née de la constatation que la diffusion d’images patrimoniales sur le web était « trop lente, trop coûteuse, trop décousue, trop complexe ». IIIF apporte une solution pérenne et élégante à ces difficultés en conciliant accessibilité, interopérabilité et sobriété. Il intéresse les GLAM (collections, bibliothèques, archives, musées, etc.) ainsi que les acteurs de l’enseignement et de la recherche.

Concrètement, IIIF créé un cadre technique commun grâce auquel les fournisseurs peuvent délivrer leurs contenus sur le web de manière standardisée, afin de les rendre consultables, manipulables et annotables par n’importe quelle application compatible.

Sommaire

• Origine de IIIF
• Qu’est-ce que IIIF ?
  • Visualisation d’un document
  • Visualisation de plusieurs documents
• Apports de IIIF
  • Pour les usagers
  • Pour les diffuseurs
  • Pour les développeurs
• Comment ça marche ?
  • API Image
  • L’API Presentation
  • Les autres API
• Au-delà de l’image : l’audio, la vidéo et la 3D
• IIIF et IA

Origine de IIIF

En 2010, constitution d’un groupe de réflexion et d’expérimentation sur l’interopérabilité des manuscrits médiévaux numérisés à l’initiative de l’université de Stanford. Ses travaux ont conduit à l’élaboration d’un modèle de données Shared Canvas basé sur le modèle d’annotation du W3C.

À la même époque, de grandes bibliothèques nationales et des universités ont travaillé à la définition d’un mécanisme d’échange des images pour aboutir en 2012 à la publication de la version 1 de l’API Image de l'International Image Interoperability Framework (IIIF).

Le Consortium IIIF a été créé en 2015 par onze institutions : la British Library, Artstor, Die Bayerische Staatsbibliothek, la Bibliothèque nationale de France, Nasjonalbiblioteket (Norvège), Wellcome Trust, et les universités d’Oxford, Stanford, Cornell, Princeton et Yale. Il compte actuellement 69 membres.

Qu’est-ce que IIIF ?

Un aspect spectaculaire de IIIF réside dans la visualisation fluide des images et le zoom profond, cf. Sagami River, Kyoto (1660?-1670?). Princeton University, mais IIIF ne se résume pas à ça, loin de là.

IIIF désigne à la fois le cadre technique partagé d’un ensemble de protocoles ouverts et une communauté humaine qui les implémente, développe des logiciels et in fine expose des contenus audiovisuels interopérables.

Ce standard de fait est utilisé par de plus en plus d’institutions culturelles — collections, bibliothèques, musées, archives, etc. — et scientifiques — universités, labos, muséums, etc. Ses fonctionnalités s’étendent maintenant à l’audio et à la vidéo ; la prise en compte de la 3D est en cours.

Pour l’heure, IIIF est surtout utilisé pour la diffusion d’images numériques. Ce sont ainsi des centaines de millions d’images qui deviennent véritablement découvrables, consultables, comparables, manipulables, citables, annotables et mixables par n’importe quelle application compatible capable de se « brancher » sur les entrepôts des uns et des autres.

Sans téléchargement de fichiers images, ces ressources de « première main » sont immédiatement utilisables par les professionnels comme par les amateurs. Elles intéressent aussi les chercheurs, les enseignants et les élèves, et les médiateurs culturels, scientifiques et artistiques. IIIF facilite grandement la diffusion, la réutilisation et la valorisation de toutes ces ressources disséminées.

Principe général d’interopérabilité de IIIF : trois applications différentes sont branchées à trois entrepôts IIIF (source : Biblissima+ — Licence Ouverte / Open License 2.0)

Visualisation d’un document

Copie d’écran du logiciel libre Tify présentant une photographie de Martin Luther King et de Joan Baez (Bob Fitch, 1966). Ce document est fourni par un serveur IIIF opéré par l’université de Stanford.

Visualisation de plusieurs documents

La magie IIIF c’est la capacité de jongler avec les références des ressources, par exemple, pour les réunir dans des bibliothèques virtuelles ou encore pour servir de points d’entrée aux robots et autres IA afin d’analyser les documents.

Léonard Limosin est un peintre, émailleur, dessinateur et graveur français du XVI^e siècle. Deux de ses œuvres sont présentées ci-après dans le visualiseur libre IIIF Mirador.

• Médaillon, Art institute of Chicago, à gauche.
• Portrait présumé de Jeanne d’Albret, Musées de la ville de Paris, à droite.

Sur cette page, vous pouvez explorer chaque image et zoomer, les comparer, lire leurs métadonnées, passer en plein écran ou agencer différemment les fenêtres. L’interface de Mirador vous permet aussi d’accéder à d’autres références en cliquant sur le bouton rond bleu puis en sélectionnant les documents préenregistrés.

Vous avez aussi la possibilité d’en ajouter d’autres via le bouton bleu Ajouter une ressource en bas à droite, ensuite en insérant l’URL d’un manifeste IIIF. En faisant une recherche sur Léonard Limosin vous trouverez différentes collections comportant certaines de ses œuvres. Certaines les exposent au standard IIIF. Dans ce cas, pour chaque notice il s’agit de récupérer le lien d’un manifeste IIIF (explicite ou associé au logo IIIF). Exemple, avec cette Crucifixion au Fitzwilliam Museum (Cambridge).

Le logiciel libre Omeka dispose de fonctionnalités IIIF et permet de créer des bibliothèques virtuelles de ressources IIIF.

Apports de IIIF

D’après IIIF en 5 minutes.

Pour les usagers

L’accès à des images de haute qualité ainsi qu’à leurs métadonnées, large choix de visualiseurs libres :

• Mirador,
• Universal Viewer,
• Openseadragon,
• Tify.

Ces outils, et d’autres encore, offrent une large palette d’interfaces riches et universelles pour :

• visualiser et explorer les images notamment grâce au zoom profond :
  • Ōmi Kuni-ezu—近江國絵圖,
  • CellXplorer (eukaryotic and prokaryotic cells),
• comparer différentes vues d’un même objet ou des images de différentes provenances :
  • River scene with a bridge in the distance de Turner,
  • David Gives Uriah a Letter for Joab, Pieter Lastman, 1619,
  • John Dee performing an experiment before Queen Elizabeth I,
• reconstituer un document à partir d’éléments dispersés, créer de nouveaux documents :
  • manuscrit 5 de la bibliothèque municipale de Châteauroux,
  • IIIF Manifest Editor (Bodleian Libraries),
• citer et partager une image ou une zone d’intérêt avec une URL :
  • IIIF Cropping tool,
• rechercher dans des contenus :
  • Welsh Newspapers,
• annoter des images, proposer des explorations commentées :
  • Recogito,
  • Storiiies et son éditeur,
  • Exhibit,
  • Adno (je pilote ce projet libre ;),
  • Annona,
• jouer :
  • Antlitz,
  • Puzzles : Puzzles! et une autre série,
• éditer et agréger des ressources :
  • Quire,
  • IIIF Curation Viewer.

Il existe de nombreux dispositifs pour utiliser ces ressources de « première main » et corpus dans un environnement éducatif et de recherche.

Pour les diffuseurs

• bénéficier d’une manière standardisée, cohérente et efficace, de présenter et de partager leurs collections,
• améliorer leur visibilité, l’accessibilité à leurs données et développer des espaces de collaboration et de recherche,
• faciliter la gestion des ressources numériques en garantissant un accès homogène et pérenne,
• promouvoir la participation des usagers en mobilisant des outils avancés pour l’exploration et l’utilisation des ressources,
• proposer des projets de transcription, de crowdsourcing ou de sciences participatives en fournissant des documents annotables,
• réduire et mutualiser les coûts en utilisant un standard ouvert, des services et des logiciels éprouvés.

Pour les développeurs

Il existe de nombreux logiciels et composants compatibles avec les API de IIIF, beaucoup sont libres. La page officielle Awesome IIIF recense les principaux ainsi qu’un grand nombre de ressources documentaires et de services.

IIIF est entièrement basé sur les standards et l’architecture du Web (principes REST et du Linked Data, Web Annotation Model du W3C, JSON-LD) ce qui facilite le partage et la réutilisation des données.

Le découplage entre la couche serveur et la couche cliente, la modularité des composants logiciels, la ré-utilisabilité des ressources offrent une grande souplesse et réduit la dépendance à un logiciel ou un prestataire.

La communauté des usagers et des développeurs est active.

Comment ça marche ?

Le manifeste est un élément essentiel de IIIF. C’est un document au format JSON-LD qui représente généralement un objet physique numérisé tel qu’un livre, une œuvre d’art, un numéro de journal, etc. Il peut également rassembler des éléments de provenances diverses. Il décrit l’ensemble du document, ses métadonnées, sa structure et référence les images et les médias qu’il embarque.

• manifeste de la photo de Martin Luther King et de Joan Baez
  https://purl.stanford.edu/hg676jb4964/iiif/manifest

Les liens des manifestes IIIF sont plus ou moins faciles à trouver dans les notices des catalogues. Une méthode simple consiste à rechercher le logo IIIF ou à explorer les informations fournies par les visualiseurs. Le site officiel de IIIF alimente un annuaire non exhaustif des sites et, site par site, fournit généralement un mode d’emploi pour récupérer les manifestes.

Techniquement, IIIF comporte deux API principales, l’API Image et l’API Presentation qui fonctionnent de concert.

API Image

L’API Image fournit des informations basiques sur l’image ainsi que les pixels de l’image entière ou de zones à la demande.

Elle se présente avec les éléments suivants :

• une URL d’accès aux informations techniques d’une image, abcd1234 est un exemple d’identifiant :
  http://www.example.org/image-service/abcd1234/info.json
• une URL à construire à la carte pour récupérer et manipuler tout ou partie de l’image en précisant la zone, la taille, l’orientation, la qualité et le format de l’image à produire.

Voilà ce que ça donne en pratique avec l’image de test. Attention ! LinuxFR met en cache les images, si vous souhaitez effectuer les manipulations, copiez et modifiez les paramètres des url ci-après.

Le fichier info.jsonest le suivant :

• https://stacks.stanford.edu/image/iiif/ff139pd0160/K90113-43/info.json

• rendu homothétique de l’image entière avec une largeur de 300px
  
  https://stacks.stanford.edu/image/iiif/ff139pd0160/K90113-43/full/300,/0/default.jpg
  
  

• détail de la même image
  
  https://stacks.stanford.edu/image/iiif/ff139pd0160/K90113-43/1680,1100,1300,1300/300,/0/default.jpg
  
  

• rotation et transformations
  
  https://stacks.stanford.edu/image/iiif/ff139pd0160/K90113-43/1680,1100,1300,1300/150,/45/default.jpg



https://stacks.stanford.edu/image/iiif/ff139pd0160/K90113-43/1680,1100,1300,1300/150,/0/bitonal.jpg


https://stacks.stanford.edu/image/iiif/ff139pd0160/K90113-43/1680,1100,1300,1300/150,/0/gray.jpg
  
  le rendu en niveaux de gris ne fonctionne pas avec ce serveur IIIF.

Pour en savoir plus consultez les spécifications de l’API Image (version 3.0 actuellement).

L’API Presentation

En complément à l’API Image, l’API Presentation fournit les propriétés d’un document IIIF : métadonnées, structures, annotations, etc.

Principales composantes d’un Manifeste IIIF (source : Biblissima+ — Licence Ouverte / Open License 2.0)

Il existe de nombreux visualiseurs pour afficher ces documents et les informations associées. On distingue alors dans différentes zones le rôle de chacune des deux API principales.

Source : Biblissima+ — Licence Ouverte / Open License 2.0.

Source : Biblissima+ — Licence Ouverte / Open License 2.0.

À noter que le visualiseur optimise le trafic en ne demandant au serveur que la partie de l’image à afficher

Pour en savoir plus consultez les spécifications de l’API Presentation (version 3.0 actuellement).

Les autres API

Voir la page des spécifications, extensions, traductions et travaux en cours.

• Authorization Flow (version 2.0) - décrit un système de contrôle d’accès.
• Change Discovery (version 1.0) - fournit les informations nécessaires pour découvrir et utiliser les ressources IIIF.
• Content Search (version 2.0) - définit le mécanisme d’interopérabilité permettant d’effectuer des recherches dans les annotations textuelles associées à un objet.
• Content State (version 1.0) - permet de référencer tout ou partie d’un manifeste IIIF et de décrire des modalités d’accès.

Au-delà de l’image : l’audio, la vidéo et la 3D

Les références à des ressources audio et vidéo sont prises en compte dans la version 3.0 de l’API de présentation IIIF. À noter qu’il n’existe pas pour l’audio et pour la vidéo d’équivalents de l’API Image, en effet, cet aspect est pris en charge par les navigateurs. Exemple : audio et vidéo d’un morceau musical associés à la partition.

Il y a une forte demande pour la prise en compte de la 3D par IIIF. Un groupe de travail rassemble les institutions et les personnes intéressées. Il anime un dépôt Github qui rassemble les documents et expérimentations du groupe.

IIIF et IA

IIIF est de plus en plus utilisé par des dispositifs d’apprentissage et de reconnaissance automatique en raison de la facilité d’accès aux images entières ou à des zones, dans les définitions et qualités nécessaires. Il est aussi possible d’imaginer des IA qui génèrent automatiquement des manifestes annotés.

La société française Teklia s’est spécialisé dans ce domaine. Elle vient d'annoncer le passage sous licence libre de sa plateforme Arkindex.

Harvard Art Museums a créé AI Explorer qui mobilisent un certain nombre d’IA pour décortiquer des reproductions d’œuvres et des photographies.

Le Consortium IIIF a mis en place un groupe de travail et il existe une formation en ligne sur le sujet.

La sélection de Pablo

La sélection de Tristan

Depuis 2006, le LibreGraphicsMeeting réuni une fois par an divers équipes et utilisateurs avancés des logiciels de créations graphiques. Nous parlons ici de Gimp, Krita, Inkscape, Scribus pour les équipes les plus régulières mais d’autres projets viennent régulièrement contribuer au groupe ou se faire connaître, présenter des projets moins visibles, plus ciblés voire des bibliothèques d’outils. Le but de ces rencontres est multiple : permettre aux contributeurs de se retrouver une fois l’an pour définir des objectifs annuels, définir des stratégies interlogicielles afin de favoriser l’interopérabilité comme cela a pu être le cas avec la création de format comme le OpenRaster…

Les effets du LibreGraphicsMeeting ont été importants dans le workflow de la création graphique mais cela n’est pas fini car le domaine évolue beaucoup en termes de besoin mais aussi en termes d’application avec de nouvelles pratiques et de nouvelles priorités.

2024 signe le retour du LibreGraphicsMeeting en présentiel, ce qui était l’objectif initial. Il se déroulera à Rennes du 9 au 12 mai dans les locaux d’Activdesign et sera organisé cette année par l’Association francophone des graphistes libres (AFGRAL) en remplacement du Grafik Labor avant de reprendre éventuellement sa mobilité internationale.

S’agissant d’une édition de reprise, l’objectif est de pouvoir faire un point sur les évolutions et nouveautés de ces dernières années par des conférences, et de permettre les rencontres lors d’atelier ou réunions de travail. Si vous souhaitez participer au LGM, n’hésitez pas à proposer une conférence avant le 2 février 2024, après quoi le comité de programmation se réunira.

Préambule : ma vie (et peut-être aussi la vôtre)

Comme probablement beaucoup d’entre vous, j’ai des milliers de photos et vidéos accumulées au cours des 20 dernières années. C’est très pratique de pouvoir stocker cela sur un seul disque dur. Mais cela pose trois problèmes majeurs :

1. la pérennité du support ;
2. le classement des fichiers pour pouvoir en retrouver un en particulier dans… très longtemps.
3. la possibilité de lire des fichiers dans plusieurs années (je pense à des fichiers Publisher 2.0 que je ne suis plus parvenu à lire par la suite – et non : les versions ultérieures à Publisher 2.0 ne lisent pas ces fichiers.

Ce texte s’adresse à toute personne qui se pose trois questions :

1. Pourrai-je visionner mes fichiers vidéos dans 30 ans pour les montrer à mes petits-enfants ?
2. Comment organiser/classer mes fichiers vidéos pour les retrouver rapidement ?
3. Comment réencoder mes fichiers vidéos pour limiter la place occupée (ou, dit autrement : quel format utiliser) ?

Après avoir lu cette dépêche, je vous recommande très fortement de vous reporter aux commentaires qui suivent car vous y trouverez probablement des précisions, liens, corrections ou suggestions qui l’enrichissent.

• Pour le point 1., aucun support n’étant inaltérable/incassable, la règle tient en une phrase : « sauvegarder sur plusieurs supports (pour parer une éventuelle défaillance), dans différents endroits (en cas d’incendie, de vol, d’inondation…) et si possible en chiffrant ses disques (pour protéger votre vie privée en cas de vol : c’est incroyablement simple sous linux)
• Pour le point 2., j’avais rédigé un document il y a fort fort longtemps où j’expliquais que le seul classement pérenne était le classement chronologique (je vous laisse vous reporter au document pour comprendre pourquoi l’utilisation de logiciels propriétaires est à proscrire). Pour résumer, je crée un dossier par année (2023) dans lequel il y a douze sous-dossiers (2023_01, 2023_02 etc.) et dans chacun d’eux, je crée un dossier par jour avec la date et le lieu (par exemple, 2023_06_25_saint_denis_la_reunion indique immédiatement où et quand ont été prises les photos et les vidéos à l’intérieur de ce dossier). Les photos sont renommées (et retournées si nécessaire) automatiquement avec l’instruction jhead -autorot -nf%Y_%m_%d__%H_%M_%S_ *.jpg. Les vidéos sont renommées manuellement sous la forme 2023_06_25__video_02_christophe_et_philippe_en_velo.mov ¹
• Pour le point 3., le format JPG étant ouvert, la lisibilité des photos est garantie dans le temps. Pour les vidéos, c’est un peu plus compliqué puisqu’en général, trois formats interviennent :
  • le codec vidéo pour l’image (comme h264, h265, av1, mjpeg…) ;
  • le codec audio pour le son (comme mp3)
  • le format de conteneur (comme avi, mp4, mts…)

C’est là où on en revient à l’histoire de ma vie.

Sommaire

• I Il était une fois MA vie !
• II Mon environnement
• III Les choix techniques
• IV Les problèmes rencontrés et les contraintes (spoiler : il faut du temps !)
• V Les scripts utilisés
  • convertion_par_lot_videos_en_265
  • convertion_par_lot_videos_en_265_une_passe_crf
  • convertion_par_lot_videos_en_xvid
  • convertion_vers_mkv_par_lot
  • convertion_videos_en_son_par_lot
  • convertir_son_en_mp3_garder_video
  • extraire_image_precise_d_une_video
  • recuperer_bitrate_video_par_lot
  • recuperer_toutes_infos_video_par_lot
  • stabiliser_video_par_lot_version
  • creer_video_cote_a_cote_par_lot
  • supprimer_bande_son_video
  • stabiliser_video_par_lot_en_testant_les_10_qualites
• En conclusion
  • Les avantages
  • Les inconvénients

I Il était une fois MA vie !

Après plus de 20 ans de stockage, mon disque dur de 1 To frisait les 90 % de remplissage. Alors, oui, 1 To, c’est très commun aujourd’hui : il me suffisait d’acheter un disque de 4 To et le problème était réglé.

Oui… mais non. Je n’aime pas occuper de la place. Je pense que c’est une mauvaise habitude que d’avoir des téraoctets disponibles ou des gigaoctets sur une carte SD pour son smartphone que l’on utilise sans se poser de questions en ayant l’impression d’un stockage illimité. Car un jour, cela nous revient dans les dents (carte SD/disque dur qui plante sans sauvegarde, réinstallation de tout le système, sauvegarde de ses milliers de photos que l’on se décide - un jour - de ranger dans un dossier A_RANGER1 puis A_RANGER2 puis A_RANGER3, etc. puis on abandonne).

En ayant un espace de stockage limité, on doit apprendre à le gérer.

Les plus anciens se souviennent peut-être des magnétoscopes : on achète des cassettes, on enregistre des films en se disant « je le regarderai un jour » et on se retrouve avec des centaines de cassettes qui prennent la poussière. Ben c’est pareil avec les disques durs : on a des téraoctets en pagaille et on se dit : « je garde, on ne sait jamais. Et un jour (qui n’arrivera jamais), je ferai le tri ! »
J’en reviens donc à mon disque dur quasi plein. Je fais une recherche sur mes fichiers vidéos et regarde le débit binaire (bitrate par la suite) : 40 000 kb/s soit environ 5 Mo/s pour des vidéos FullHD et jusqu’à 100 Mb/s (12 Mo/s) pour des vidéos 4k (évidemment, cela dépend de l’appareil à l’origine de la vidéo). Voici les différents bitrate que j’ai pu rencontrer :
• fichier mp4 4K drone : 100 Mb/s ;
• fichier mp4 4K go pro : 60 Mb/s
• fichier mov FullHD : environ 16Mb/s
• ficher avi 640*480 : environ 15 MB/ (mjpeg et format son araw)
• fichier avi 320*240 : entre 1 et 2,5 Mb/s

Loin d’être un expert dans la compression vidéo, le poids des fichiers m’interpelle quand même. En effet, un site de téléchargement de films - que je n’ai jamais fréquenté car c’est illégal - a pour objectif d’optimiser le ratio qualité/poids et donc d’offrir une bonne qualité visuelle pour un poids réduit. Ainsi, un film en FullHD de 90 min a un poids de 1400 Mo soit un bitrate d’environ 2 Mb/s (250 ko/s avec le codec H264). Un film en 4K de 90 min a un poids de 4 Go soit un bitrate d’environ 4Mb (500 ko/s avec le codec H265). Et il paraît – je ne le sais pas directement car je n’ai jamais fréquenté ce site dont je ne connais même pas l’existence – que la qualité des films sur le site en question est bonne, visuellement parlant s’entend.

Il était donc temps de se mettre au travail et de réencoder mes vidéos personnelles.

L’objectif de ce document est donc triple (et permettra de répondre aux questions 1. et 3. que s’est posé le lecteur ou la lectrice dans le préambule :

• ré encoder ses vidéos automatiquement via un script bash (en utilisant le logiciel libre ffmpeg ) sans perte de qualité visible  ;
• réduire le poids des fichiers de façon notable (par notable, j’entends ici une réduction d’au moins 20 %, ce qui est totalement subjectif, mais j’assume) ;
• s’assurer de la pérennité de ses vidéos (i.e. être capable de les visionner dans 20 ans) ;

II Mon environnement

• Le matériel : Lenovo V45 (payé 300 € environ avec un AMD A4-9125 radeon R3, 8Go de mémoire vive et un SSD Samsung de 1To, le tout sous kubuntu 22,04).
• Les logiciels : ffmpeg version 4.4.2, vlc, krename (pour renommer ses fichiers par lot), kfind pour retrouver des fichiers avec des extensions précises (je ne maîtrise pas du tout l’outil en ligne de commande find), avidemux pour faire du montage vidéo basique (couper quelques minutes d’une vidéo par exemple), dolphin pour naviguer dans les fichiers et, surtout, indicator-cpufreq (qui permet de réduire la fréquence du processeur et éviter que le ventilateur ne tourne en permanence).

III Les choix techniques

Je ne devais utiliser que des logiciels libres et des formats ouverts. Pour les logiciels : mon choix s’est porté sur ffmpeg pour l’encodage car c’est LA référence pour la conversion de vidéos, même si l’usage de la ligne de commande peut rebuter cetains (mais vous verrez par la suite que les scripts simplifient grandement la vie). Pour les formats :

• MP3 pour l’audio : il n’est plus protégé par un brevet depuis 2017 et me convenait parfaitement, en choisissant un débit de 250kb/s (ce qui est sûrement excessif mais la place occupée par le son dans une vidéo est faible par rapport à la vidéo). Je sais qu’il y a vorbis mais le mp3 me semble plus « universel », notamment si l’on regarde la vidéo sur un téléviseur
• MKV pour le conteneur : c’est un format ouvert et qui est lu sur tous les téléviseurs sur lesquels j’ai pu le tester.
• H265 pour le format vidéo : c’est un format sorti en 2013 soumis à brevet mais il est possible d’utiliser une bibliothèque libre (x265) pour effectuer l’encodage (c’est cette bibliothèque qu’utilise ffmpeg). Là encore, lorsque j’ai testé des vidéos encodées en h265 sur différents téléviseurs pas trop vieux, je n’ai jamais eu de problème. Sachez qu’il existe le format AV1, plus récent, plus efficace en termes de compression, libre et qui répond à mes besoins. Mais deux éléments m’ont fait renoncer à l’utiliser :
  • l’encodage (avec ma machine) est extrêmement lent (j’ai abandonné l’encodage de 30 secondes de vidéo quand, après une heure, il en était toujours à la première seconde !) ;
  • il n’est pas encore généralisé : peu de téléviseurs peuvent lire ce format (si vous en connaissez, je suis preneur). Il est fort probable que dans une dizaine d’années, je réencoderai mes vidéos en AV1, mais laissons cela pour plus tard.

J’ai également choisi d’encoder mes vidéos en deux passes car cela me permet de décider du débit binaire (et donc de la taille du fichier finale) tout en ayant une meilleure qualité qu’en une passe.
J’ai utilisé le programme indicator-cpufreq qui me permet de réduire au minimum la fréquence de mon processeur (ici 1,2 Gh) afin d’éviter que le ventilateur ne tourne sans arrêt (à noter qu’une mise en veille repasse la fréquence au maximum et il n’est plus possible de la réduire, sauf à redémarrer l’ordinateur). Avec une fréquence réduite au minimum, le ventilateur ne se déclenche que quelques secondes toutes les minutes et le processeur ne dépasse pas les 50°C (c’est hardinfo qui me le dit).

IV Les problèmes rencontrés et les contraintes (spoiler : il faut du temps !)

• L’encodage en deux passes permet d’obtenir une meilleure qualité visuelle (de ce que j’ai compris) mais au prix d’un temps de calcul doublé. Ainsi, une vidéo d’une minute (en FullHD) a nécessité environ 100 minutes d’encodage pour obtenir le fichier final. Autant vous dire que mon ordinateur a tourné pendant environ 5 mois près de 20 heures par jour en moyenne. En revanche, j’ai découvert comment arrêter un processus (kill - STOP numero_pid_util) lorsque j’avais besoin de retrouver toute la puissance du processeur et comment le reprendre plus tard (kill - CONT numero_pid_util). Par ailleurs, je n’ai pas trouvé comment utiliser la carte graphique pour le réencodage, car il paraît que c’est plus rapide…
• Je ne connais pas l’instruction ou l’option (si elle existe) de ffmpeg qui permet de conserver les métadonnées des vidéos. Ainsi, la conversion effectuée avec les scripts ci-dessous supprime toutes les métadonnées (pourtant, cela semble possible)
• Je n’ai pas trouvé, malgré mes recherches, comment reprendre la première passe d’un encodage après une coupure ou un bug (ffmpeg génère un fichier log durant la première passe, fichier qu’il devrait être possible de réutiliser afin de reprendre là où il s’est arrêté). Il m’a donc fallu, parfois, reprendre l’encodage d’une vidéo à zéro.
• La procédure avant encodage demande de l’organisation :
  • Rechercher toutes ses vidéos est relativement aisé et rapide : kfind permet d’effectuer une recherche sur de multiples formats. Ensuite, un copier-coller sur un autre disque dur permet de les isoler.
  • Il est nécessaire de connaître le bitrate de chacune d’elle. Une recherche Internet et hop, le script qui va bien (voir la partie sur les scripts) génère un fichier CSV pour nous faciliter le travail.
  • Il faut ensuite regrouper les vidéos par débit et définition : ainsi, une vidéo 640*480 de 10 Mb/s ne pouvait pas être dans le même répertoire qu’une vidéo en 320*240 de 5 Mb/s également puisque le bitrate final n’était pas le même. Là, pas de secret, il faut le faire manuellement. Mais rassurez-vous, bien souvent, les vidéos d’une même période ont toute le même bitrate.
  • L’étape suivante a consisté à choisir le débit final des vidéos suivant leur définition de façon à ce que la vidéo finale subisse une compression pas ou peu visible à l’œil par rapport à l’original (ce qui est très subjectif). J’ai donc choisi (en partant des débits de YiFY et un peu au doigt mouillé) :
    • 10 Mb/s pour de la 4K (porté très rarement à 12 Mb/s si la vidéo comportait beaucoup de mouvements) ;
    • 4 Mb/s pour de la FullHD ;
    • environ 2 Mb/s pour de la 640*480
    • 1 Mb/s pour de la 320*240
• Un bug est apparu lors de la conversion des fichiers MJPEG directement en H265 : les couleurs finales étaient complètement différentes des originales. Je ne suis pas le seul à avoir subi ce qui semble être un bug. Au final, j’ai contourné ce désagrément en convertissant d’abord ces fichiers en xvid avec un gros bitrate pour limiter la perte de qualité (opération très rapide) puis les xvid en H265, ce qui a réglé le problème.
• J’imagine que, comme beaucoup d’entre nous, je souhaite limiter mon impact environnemental. N’ayant pas de panneaux photovoltaïques, mon empreinte carbone est probablement élevée car j’ai été contraint de laisser tourner mon ordinateur jour et nuit en consommant de l’électricité pas toujours verte. En contrepartie, j’économise l’achat d’un nouveau disque dur. Cela me permet de me donner bonne conscience.

V Les scripts utilisés

Ces scripts (qui fonctionnent sous Linux. Pour Windows, il faudra adapter…) ont été écrits à partir de ce que j’ai trouvé sur Internet car ma maîtrise de ce genre d’outils est très fragile voire inexistante (j’ai donc pas mal bidouillé et ils peuvent sûrement être optimisés). Je vous dirais volontiers qu’ils sont sous licence libre ou dans le domaine public mais n’ayant pas noté mes sources, je les livre ci-dessous sans aucune garantie de quoi que ce soit (la seule chose que je peux garantir, c’est que j’ai fait pas mal de modifications par rapport aux scripts originaux).
Je vous rappelle que pour utiliser ces scripts, vous devez faire un copier-coller du script dans un fichier texte (en utilisant kate par exemple), l’enregistrer puis le rendre exécutable. Ensuite, vous placez ce script dans le répertoire de vos vidéos, et, dans une console, vous tapez ./nom_du_script
Je pense avoir mis suffisamment de commentaires pour comprendre ce que fait chaque script. Si cela n’était pas le cas, signalez les erreurs ou les suggestions dans les commentaires.
Voici un résumé pour chacun d’eux :

1. convertion_par_lot_videos_en_265 : c’est le script que j’ai le plus utilisé pour convertir des vidéos en H265 en choisissant une ou deux passes et le bitrate.
2. convertion_par_lot_videos_en_265_une_passe_crf : convertir en une seule passe en choisissant la qualité voulue
3. convertion_par_lot_videos_en_xvid : convertir des vidéos au format XVID, lorsque la conversion des MJPEG vers H265 pose problème
4. convertion_vers_mkv_par_lot : convertir tous les formats de conteneur en MKV (j’ai eu parfois des problèmes avec certaines extensions, le passage en MKV réglait le problème) ;
5. convertion_videos_en_son_par_lot : ne garder que le son (pour des vidéos youtube que l’on souhaite uniquement écouter par exemple) ;
6. convertir_son_en_mp3_garder_video : réeconde uniquement le son en MP3, ne touche pas la vidéo
7. extraire_image_precise_d_une_video : permet d’extraire une image précise (par exemple la 123) d’une ou plusieurs vidéos. Ce script m’a permis de comparer l’image d’origine et l’image réencodée. J’utilisais ensuite Gimp pour visualiser les différences entre les deux images.
8. recuperer_bitrate_video_par_lot : récupère tous les bitrates des vidéos d’un même répertoire et l’exporte dans un fichier CSV (données séparées par une espace) ;
9. recuperer_toutes_infos_video_par_lot : exporte dans un fichier csv les dimensions de l’image, le fps etc. mais pas le bitrate (je n’ai pas trouvé comment fusionner ce script avec le précédent)
10. stabiliser_video_par_lot_en_testant_les_10_qualites : script pour stabiliser une vidéo avec une image « secouée » en testant les 10 qualités possibles automatiquement. Vous pouvez faire des tests, chez moi, ce n’était pas probant. Le script est à revoir probablement.
11. stabiliser_video_par_lot_version : idem que ci-dessus mais vous choisissez le paramètre de la stabilisation.
12. creer_video_cote_a_cote_par_lot : pour comparer deux vidéos en en créant une nouvelle avec les deux côte à côte (je l’utilise pour comparer la vidéo d’origine et la vidéo stabilisée).
13. supprimer_bande_son_video : ne conserve que la vidéo, supprime le son (pour des vidéos où le son ne présente aucun intérêt). Et c’est parti !

convertion_par_lot_videos_en_265

#/bin/bash
# conversion par lot de fichier video au format H265 avec audio en mp3 qualité 256k
# nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes (en théorie tout au moins...)
# si vous souhaitez interrompre le programme pour avoir accès à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util
echo "Ce script va réencoder vos vidéos (MKV MP4 MTS AVI MOV WEBM FLV MPG MPEG WMV 3GP RM ASX VOB F4V MKS M4V OGV M2V MPV TS M2TS AVC HEVC M1V M2V MPV) en H265, le son en MP3 256k et au format de conteneur MKV en 1 ou 2 passes. Vous allez pouvoir choisir le bitrate d'encodage pour la vidéo, le codec et le nombre de passe. Les extensions des vidéos peuvent être en minuscules ou majuscules mais pas un mélange des deux. Les fichiers originaux seront déplacés dans le dossier originaux et les fichiers convertis dans le dossier convertis_x265"
echo -n "Entrez le bitrate -sans espace - que vous souhaitez utiliser : (4000 recommandé pour de la video FullHD, 10000 pour de la 4K) "
read bitrate
# les lignes (rm x265_2pass.log / rm x265_2pass.log.cutree / rm x265_2pass.log.cutree.temp / rm x265_2pass.log.temp) suppriment les fichiers générés lors des deux passes
# pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
# pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)
echo -n "Souhaitez-vous une passe ou deux passes ? Taper 1 pour une passe (plus rapide mais de moins bonne qualité) ou 2 pour deux passes (plus lent mais la vidéo finale est de meilleure qualité) :  "
read passe
if [ "$passe" = "1" ] ; then
mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_x265
#crée un répertoire où seront déplacés les fichiers convertis
    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
    nice -19 ffmpeg -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=1 -c:a libmp3lame -b:a 256k "$i.mkv"
    mv "$i.mkv" ./convertis_x265
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
    done
elif [ "$passe" = "2" ]; then
mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_x265
#crée un répertoire où seront déplacés les fichiers convertis
    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
    nice -19 ffmpeg -y -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=1 -an -f null /dev/null && \
    #première passe
    nice -19 ffmpeg -i "$i" -c:v "libx265" -b:v "${bitrate}k" -"x265"-params pass=2 -c:a libmp3lame -b:a 256k "$i.mkv"
    mv "$i.mkv" ./convertis_x265
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
#les lignes suivantes suivantes suppriment les fichiers temporaires de la première passe en cas d'interruption.
    rm x265_2pass.log
    rm x265_2pass.log.cutree
    rm x265_2pass.log.cutree.temp
    rm x265_2pass.log.temp
    rm x264_2pass.log
    rm x264_2pass.log.cutree
    rm x264_2pass.log.cutree.temp
    rm x264_2pass.log.temp
    done
else
    echo "Il faut taper 1 ou 2, rien d'autre. Relancez le script !"
fi
    rm x265_2pass.log
    rm x265_2pass.log.cutree
    rm x265_2pass.log.cutree.temp
    rm x265_2pass.log.temp
    rm x264_2pass.log
    rm x264_2pass.log.cutree
    rm x264_2pass.log.cutree.temp
    rm x264_2pass.log.temp

convertion_par_lot_videos_en_265_une_passe_crf

#!/bin/bash
# conversion par lot de fichier video au format H265 avec audio en mp3 qualité 320k
# nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes.
# si vous souhaitez interrompre le programme pour avoir accès à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util

echo "Ce script va réencoder vos vidéos (MKV, MP4, MTS, AVI, MOV, WEBM FLV) en H265, le son en MP3 256k et au format de conteneur MKV en 1 passe. Vous allez pouvoir choisir CRF (constant rate factor) pour la vidéo. Les extensions des vidéos peuvent être en minuscules ou majuscules mais pas un mélange des deux."
echo -n "Entrez le CRF que vous souhaitez utiliser : (entre 1 et 51 - 1 pour la meilleure qualité, 51 pour la plus mauvaise) - 28 est recommandé : "
read crf

echo -n "Entrez la vitesse que vous souhaitez utiliser : (ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow) - votre choix joue sur la vitesse de traitement et la qualité. Superfast sera très rapide mais de moins bonne qualité. medium est le choix recommandé. Votre choix : "
read speed

# on peut modifier le fichier de sortie en ajoutant un répertoire : "$i.mkv" devient "/home/perso/mon_repertoire/$i.mkv"
# les lignes (rm x265_2pass.log / rm x265_2pass.log.cutree / rm x265_2pass.log.cutree.temp / rm x265_2pass.log.temp) suppriment les fichiers générés lors des deux passes
# pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
# pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)
mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_x265
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ;
    do
    nice -19 ffmpeg -i "$i" -c:v libx265 -crf "$crf" -preset "$speed" -c:a libmp3lame -b:a 256k "$i.mkv"

    mv "$i.mkv" ./convertis_x265
    #déplace les fichiers convertis

    mv "$i" ./originaux
    #déplace les fichiers originaux
    done

#les lignes suivantes suivantes suppriment les fichiers temporaires de la première passe en cas d'interruption.
    rm x265_2pass.log
    rm x265_2pass.log.cutree
    rm x265_2pass.log.cutree.temp
    rm x265_2pass.log.temp
    rm x264_2pass.log
    rm x264_2pass.log.cutree
    rm x264_2pass.log.cutree.temp
    rm x264_2pass.log.temp

convertion_par_lot_videos_en_xvid

#!/bin/bash
# ce script balaie tous les fichiers d'un même répertoire et va convertir les AVI en XVID et conserver le son d'origine
# nice -19 signifie que le programme aura la priorité la plus faible, ce qui ne devrait pas beaucoup ralentir l'exécution des autres programmes.
# si vous souhaitez interrompre le programme pour avoir accès à tout le processeur, tapez l'instruction top puis identifiez le PID UTIL des processeurs ffmpeg concernés puis tapez kill - STOP numero_pid_util. Pour relancer le processus, tapez kill - CONT numero_pid_util

echo "Ce script va réencoder vos vidéos AVI en XVID, conserver le son d'origine et au format de conteneur MKV en 2 passes. Les extensions des vidéos (AVI ou avi) peuvent être en minuscules ou majuscules mais pas un mélange des deux. La convertion directe de MJPEG vers 265 pose des problèmes de couleurs. Il faut donc passer par XVID d'abord (voir https://stackoverflow.com/questions/71397605/ffmpeg-mjpeg-h-265-smeared-color-on-output-video-file )"
# on peut modifier le fichier de sortie en ajoutant un répertoire : "$i.mkv" devient "/home/perso/mon_repertoire/$i.mkv"
# pour conserver l'audio, remplacer -c:a libmp3lame -b:a 256k par -c:a copy
# pour réduire la qualité audio, remplacer le 256k dans "-c:a libmp3lame -b:a 256k" par un nombre plus petit (par exemple 128k ou 92k)

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion

mkdir convertis_xvid
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.avi *.AVI ; do
    nice -19 ffmpeg -y -i "$i" -c:v mpeg4 -vtag xvid -b:v 16000k -pass 1 -an -f avi /dev/null
    ffmpeg -i "$i" -c:v mpeg4 -vtag xvid -b:v 16000k -pass 2 -c:a copy "$i.mkv"

    mv "$i.mkv" ./convertis_xvid
    #déplace les fichiers convertis

    mv "$i" ./originaux
    #déplace les fichiers originaux

    done

convertion_vers_mkv_par_lot

#!/bin/bash
# conversion par lot de fichiers vers mkv - mofifier l'extension si nécessaire - supprimer les extensions d'origine avec krename ensuite. Attention, s'il y a déjà des fichiers MKV, ils seront reconvertis en MKV

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_mkv
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do


#    autre chose trouvé sur internet avec bug : ffmpeg -flags +genpts -i "$i" -c copy -sn "$i.mkv"

nice -19 ffmpeg -y -i "$i" -c:v copy -c:a copy "$i.mkv"
  mv "$i.mkv" ./convertis_mkv
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux

done

convertion_videos_en_son_par_lot

#!/bin/bash
# conversion par lot de fichiers vers mkv - mofifier l'extension si nécessaire - supprimer les extensions d'origine avec krename ensuite. Attention, s'il y a déjà des fichiers MKV, ils seront reconvertis en MKV

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_mkv
#crée un répertoire où seront déplacés les fichiers convertis

    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do


#    autre chose trouvé sur internet avec bug : ffmpeg -flags +genpts -i "$i" -c copy -sn "$i.mkv"

nice -19 ffmpeg -y -i "$i" -c:v copy -c:a copy "$i.mkv"
  mv "$i.mkv" ./convertis_mkv
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux

done

convertir_son_en_mp3_garder_video

#!/bin/bash
echo -n "Ce script va convertir le son des videos en mp3 sans toucher la video et ajouter l'extension .MKV à la fin du fichier. Choisissez la qualité mp3 (256 recommandé) : "
read bitratemp3

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir convertis_mp3
#crée un répertoire où seront déplacés les fichiers convertis


for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do

    nice -19 ffmpeg -i "$i" -c:v copy -c:a libmp3lame -b:a "${bitratemp3}k" "$i.mkv"

    mv "$i.mkv" ./convertis_mp3
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
done

extraire_image_precise_d_une_video

#!/bin/bash


echo -n "Entrez le numéro de l'image que vous souhaitez extraire (attention, la numérotation commence à 0 donc si vous souhaitez la frame 536, il faut saisir 535) "
read num_frame


for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do



nice -19 ffmpeg -i "$i" -vf "select=eq(n\,$num_frame)" -vframes 1 screenshot_frame_"$num_frame"_"$i".png

done

recuperer_bitrate_video_par_lot

#!/bin/bash

#recherche le bitrate des videos de façon récursive
find . \( -iname "*.mkv" -or -iname "*.mov" -or -iname "*.mts" -or -iname "*.mp4" -or -iname "*.mpg" -or -iname "*.mpeg" -or -iname "*.flv" -or -iname "*.avi" -or -iname "*.webm" -or -iname "*.wmv" -or -iname "*.3gp" -or -iname "*.rm" -or -iname "*.asx" -or -iname "*.vob" -or -iname "*.f4v" -or -iname "*.mks" -or -iname "*.m4v" -or -iname "*.ogv" -or -iname "*.m2v"  -or -iname "*.mpv" -or -iname "*.ts" -or -iname "*.m2ts" -or -iname "*.avc" -or -iname "*.hevc" -or -iname "*.m1v" -or -iname "*.m2v" -or -iname "*.mpv" \) -print0 | xargs -0 -i{} sh -c " echo -n '{} ' && ffmpeg -i '{}' 2>&1 | sed -n -e 's/^.*bitrate: //p' " > result_bitrate.csv
#ecrit le bitrate de toutes les videos d'un dossier dans le fichier result_mts.csv.
# Ouvrir avec tableur et choisir séparateur ESPACE pour mieux visualiser les bitrate

recuperer_toutes_infos_video_par_lot

#!/bin/bash

#recherche les informations des videos
find . \( -iname "*.mkv" -or -iname "*.mov" -or -iname "*.mts" -or -iname "*.mp4" -or -iname "*.mpg" -or -iname "*.mpeg" -or -iname "*.flv" -or -iname "*.avi" -or -iname "*.webm" -or -iname "*.wmv" -or -iname "*.3gp" -or -iname "*.rm" -or -iname "*.asx" -or -iname "*.vob" -or -iname "*.f4v" -or -iname "*.mks" -or -iname "*.m4v" -or -iname "*.ogv" -or -iname "*.m2v"  -or -iname "*.mpv" -or -iname "*.ts" -or -iname "*.m2ts" -or -iname "*.avc" -or -iname "*.hevc" -or -iname "*.m1v" -or -iname "*.m2v" -or -iname "*.mpv" \) -print0 | xargs -0 -i{} sh -c " echo -n '{} ' && ffmpeg -i '{}' 2>&1 | sed -n -e 's/^.*Video: //p' " > result_toutes_les_infos.csv


#ecrit les informations toutes les videos d'un dossier dans le fichier result_toutes_les_infos.csv.
#Ouvrir avec tableur et choisir séparateur ESPACE pour mieux visualiser les bitrate

stabiliser_video_par_lot_version

#!/bin/bash
# stabiliser des videos par lot

echo -n "Sélectionnez la stabilité de la vidéo que vous souhaitez : 1 (très stable) jusqu'à 10 (très instable)  "
read stabilite

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir stabilisee
#crée un répertoire où seront déplacés les fichiers convertis

for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do

    nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$stabilite:accuracy=15 -f null - && \

#shakiness=10 peut etre modifié en mettant shakiness = nombre_entre_1_et_10 : 1 video stable, 10 video très instable

    nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$stabilite:accuracy=15 -f null -&& nice -19 ffmpeg -i "$i" -vf vidstabtransform=smoothing=30:input="transforms.trf" "stabilisee_$i"

rm transforms.trf

mv "stabilisee_$i" ./stabilisee
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux
done

creer_video_cote_a_cote_par_lot

#!/bin/bash
#ce script va créer une vidéo à partir de deux vidéos, l'une que l'on peut nommer ma_video.mkv et l'autre qui doit alors se nommer stabilisee_ma_video.mkv
#les deux vidéos seront côte à côte, ce qui permet de les comparer
for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB ; do


# la video d'origine correspond à $i et l'autre video doit commencer par "stabilisee" mais il suffit de changer le prefixe si necessaire

    ffmpeg -i "$i" -i "stabilisee_$i" -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w" "cote_a_cote_$i"


done

supprimer_bande_son_video

#!/bin/bash
#supprimer la bande son de toutes les videos (au format voir ci-dessous) d'un même répertoire et crée un fichier MKV sans bande son. Ne réencode pas la vidéo.

mkdir originaux
# crée un répertoire où seront déplacés les fichiers originaux après conversion
mkdir sans_son
#crée un répertoire où seront déplacés les fichiers convertis


    for i in *.mkv *.MKV *.mp4 *.MP4 *.mts *.MTS *.avi *.AVI *.mov *.MOV *.webm *.WEBM *.flv *.FLV *.mpg *.MPG *.mpeg *.MPEG *.wmv *.WMV *.3gp *.3GP *.rm *.RM *.asx *.ASX *.vob *.VOB *.f4v *.F4V *.mks *.MKS *.m4v *.M4V *.ogv *.OGV *.m2v *.M2V *.mpv *.MPV *.ts *.TS *.m2ts *.M2TS *.avc *.AVC *.hevc *.HEVC *.m1v *.M1V *.m2v *.M2V *.mpv *.MPV ; do
    nice -19 ffmpeg -i "$i" -c copy -an "$i.mkv"

    mv "$i.mkv" ./sans_son
    #déplace les fichiers convertis
    mv "$i" ./originaux
    #déplace les fichiers originaux


    done

stabiliser_video_par_lot_en_testant_les_10_qualites

#!/bin/bash
# test toutes les qualités de stabilisation pour un même fichier

# test les 10 qualités de stabilité

        for qualite in 1 2 3 4 5 6 7 8 9 10 ; do
            for i in *.mkv ; do

            # nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$qualite:accuracy=15 -f null - && \

            #shakiness=10 peut etre modifié en mettant shakiness = nombre_entre_1_et_10 : 1 video stable, 10 video très instable

            nice -19 ffmpeg -i "$i" -vf vidstabdetect=shakiness=$qualite:accuracy=15 -f null -&& nice -19 ffmpeg -i "$i" -vf vidstabtransform=smoothing=30:input="transforms.trf" "stabilisee_$i_$qualite.mp4"

            rm transforms.trf

            done


        done

En conclusion

Il faut du temps et de l’envie pour se lancer dans cette aventure, même si le CPU fait 80 % du travail. Mais les 20 % restant ne sont pas à négliger. Entre les copier-coller qu’il ne faut pas rater, le classement des vidéos par bitrate ou dimension, les vidéos réencondées qu’il faut visionner (en accéléré) pour s’assurer qu’elles sont correctes, etc. il faut vraiment rester concentré pour éviter d’oublier une vidéo ou, pire, de l’effacer alors qu’elle n’a pas été réencondée.

Les avantages

Mais je ne regrette pas tout ce temps, surtout pour avoir revisionné quasiment toutes mes vidéos, celle de mes enfants bébé (le coup de vieux en pleine figure), les moments en famille, les grands-parents disparus… Cela a été des moments vraiment agréables.

Cela m’a également permis de ranger des vidéos qui n’étaient pas dans le bon répertoire ou de renommer celles qui comportaient une erreur dans leur nom.

J’ai maintenant toutes mes vidéos avec le même format de conteneur (MKV), et les mêmes codec vidéo et audio, ce qui facilitera grandement un réencodage ultérieur.

Et puis – c’était l’un des objectifs – le gain de place est très important puisque mon disque dur est passé de 90 % à 48 % d’occupation (j’ai fait aussi un peu de ménage donc ce gain ne provient pas que du réencodage des vidéos).

Les inconvénients

Est-ce une bonne idée de mettre tous ses œufs dans le même panier (un seul format de conteneur, un seul codec video, un seul codec audio) , même si ces formats sont libres et, pour H265, lisible avec des logiciels libres, ce qui est tout de même une bonne assurance pour l’avenir ?

Du temps, du temps, et encore du temps : il faut en avoir pour ce projet (mais j’espère que les scripts vous permettront d’en gagner)

Cela consomme de l’énergie et, si beaucoup de gens veulent réencoder leurs vidéos, l’impact environnemental ne sera pas négligeable.

L’opération monopolise un ordinateur (nice -19 ne m’a pas paru très efficace quand je lançais trois encodages simultanément!). Mais cela peut être l’occasion d’en utiliser un qui dort dans un placard et qui pourrait ainsi resservir.

Si c’était à refaire…

• Je le referai, sans aucun doute !
• J’essaierai de conserver les métadonnées (date, heure, coordonnées GPS) de mes vidéos (même si les informations les plus importantes sont dans leur nom) ;
• Je tenterai d’utiliser le GPU pour le réencodage, ce qui réduirait le temps de calcul.

Note pour le prochain confinement :

• convertir les vidéos en AV1 ;
• convertir les photos en AVIF ;
• créer des fichiers PAR2 pour sécuriser mes sauvegardes

[1] : je n'ai pas réussi à trouver l'équivalent de la commande jhead -autorot -nf%Y_%m_%d_%H%M_%S_ *.jpg pour les videos

🦆 VS 😈 : Let’s take back some ground from the tech giants !

Thanks to your donations to our not-for-profit, Framasoft is taking action to advance the ethical, user-friendly web. Find a summary of our progress in 2023 on our Support Framasoft page.

➡️ Read the series of articles from this campaign (Nov. – Dec. 2023)

Click to support us and help push back Videoraptor – Illustration CC-By David Revoy

Click to support us and help Sepia reach their potential – Illustration CC-By David Revoy

Click to support us and help push Yetube back – CC-By Illustration David Revoy

Click to support us and help Sepia push back Videoraptor – Illustration CC-By David Revoy

🦆 VS 😈 : Reprenons du terrain aux géants du web !

Grâce à vos dons (défiscalisables à 66 %), l’association Framasoft agit pour faire avancer le web éthique et convivial. Retrouvez un résumé de nos avancées en 2023 sur le site Soutenir Framasoft.

➡️ Lire la série d’articles de cette campagne (nov. – déc. 2023)

Nous sommes tellement impatient·es de vous présenter tout le travail que nous avons accompli que nous allons le faire sans introduction... mais pensez à nous suivre  ! Dans deux semaines, nous prendrons plus de temps pour parler de l’histoire de PeerTube, de l’état actuel de ce projet et des grands projets que nous avons pour son avenir !

Cliquez pour nous soutenir et aider à repousser Videoraptor – Illustration CC-By David Revoy

Cette année : deux mises à jour mineures et une avancée majeure

Mars 2023 : PeerTube v5.1

Vous trouverez plus de détails dans la news dédiée à la version 5.1, donc pour faire court, cette version apporte :

• une fonctionnalité « demander un compte », où les modérateurices d’instance peuvent gérer et modérer les nouvelles demandes de compte ;
• un bouton de retour au direct, qui vous permet de revenir au direct lorsque vous êtes à la traîne lors d’un direct ;
• Améliorations du plugin d’identification, pour faciliter la connexion avec des identifiants externes.

Juin 2023 : PeerTube 5.2…

Comme vous le découvrirez dans notre article de blog sur la version 5.2, il y a eu quelques nouvelles fonctionnalités plus petites mais importantes telles que :

• L’adaptation des flux RSS aux standards de podcast, de sorte que n’importe quel logiciel de podcast puisse être capable de lire une chaîne PeerTube, par exemple ;
• L’option permettant de définir la confidentialité de la rediffusion d’un direct, afin que les vidéastes puissent choisir à l’avance si la rediffusion de leur live sera Publique, Non listée, Privée ou Interne ;
• Amélioration de la navigation sans souris : pour celles qui préfèrent ou ceux qui doivent naviguer à l’aide de leur clavier ;
• Et des améliorations de notre documentation (elle est très complète : consultez-la !).

…avec une fonctionnalité majeure : le transcodage distant

Mais ce qui a changé la donne dans cette version 5.2, c’est la nouvelle fonctionnalité de transcodage à distance.

Lorsqu’une vidéaste télécharge une vidéo (ou lorsqu’elle diffuse en direct), PeerTube doit transformer son fichier vidéo dans un format efficace. Cette tâche est appelée transcodage vidéo et consomme beaucoup de puissance de calcul (CPU). Les administratrices de PeerTube avaient besoin de gros serveurs CPU (coûteux) pour une tâche qui n’était pas permanente… jusqu’au transcodage à distance.

Le transcodage à distance permet aux administrateurs de PeerTube de déporter tout ou partie de leurs tâches de transcodage sur un autre serveur, plus puissant, qui peut être partagé avec d’autres administratrices, par exemple.

Cela rend l’ensemble de l’administration PeerTube moins chère, plus résiliente, plus économe en énergie… et ouvre une voie de partage des ressources entre les communautés !

Nous voulons, une fois de plus, remercier le programme NGI Entrust et la fondation NLnet pour la bourse qui nous a permis de réaliser une telle amélioration technique !

Cliquez pour nous soutenir et aider Sepia à atteindre son potentiel – Illustration CC-By David Revoy

PeerTube v6 est frais… grâce aux idées que vous nous avez soufflées !

Assez parlé du passé, détaillons les fonctionnalités de cette nouvelle version majeure. Notez que, pour toute cette feuille de route 2023, nous avons développé des fonctionnalités suggérées et votées par… vous ! Ou du moins par celles et ceux d’entre vous qui ont partagé leurs idées sur notre site de suggestions (en anglais)).

Protégez vos vidéos avec des mots de passe !

Cette fonctionnalité était très attendue. Les vidéos protégées par un mot de passe peuvent être utilisées dans de nombreuses situations : pour créer un contenu exclusif, marquer une étape dans un parcours pédagogique, partager des vidéos avec des personnes de confiance…

Sur leur compte PeerTube, les vidéastes peuvent désormais définir un mot de passe unique lorsqu’iels téléchargent, importent ou mettent à jour les paramètres de leurs vidéos.

Mais avec notre API REST, les administrateurs et les développeuses peuvent aller plus loin. Iels peuvent définir et stocker autant de mots de passe qu’elles le souhaitent, ce qui leur permet de donner et de révoquer facilement l’accès aux vidéos.

Cette fonctionnalité est le fruit du travail de Wicklow, pendant son stage chez nous.

Storyboard vidéo : prévisualisez ce qui va suivre !

Si vous aimez regarder vos vidéos en ligne, vous avez peut-être l’habitude de survoler la barre de progression avec votre souris ou votre doigt. Habituellement, un aperçu de l’image apparaît sous forme de vignette : c’est ce qu’on appelle le storyboard, et c’est maintenant disponible dans PeerTube !

Veuillez noter que comme les storyboards ne sont générés que lors du téléchargement (ou de l’importation) d’une vidéo, ils ne seront donc disponibles que pour les nouvelles vidéos des instances qui sont passées à la v6…

Ou vous pouvez demander, très gentiment, à vos administrateurs d’utiliser la commande magique npm run create-generate-storyboard-job (attention : cette tâche peut nécessiter un peu de puissance CPU), afin de générer des storyboards pour les anciennes vidéos.

Téléchargez une nouvelle version de votre vidéo !

Parfois, les créateurs de vidéos veulent mettre à jour une vidéo, pour corriger une erreur, offrir de nouvelles informations… ou simplement pour proposer un meilleur montage de leur travail !

Désormais, avec PeerTube, elles peuvent télécharger et remplacer une ancienne version de leur vidéo. Bien que l’ancien fichier vidéo soit définitivement effacé (pas de retour en arrière !), les créatrices conservent la même URL, le titre et les informations, les commentaires, les statistiques, etc.

Il est évident qu’une telle fonctionnalité nécessite de la confiance des vidéastes et des administrateurs, qui ne veulent pas être responsables de la « mise à jour » d’une adorable vidéo de chatons en une horrible publicité pour des groupes de discrimination contre les chats.

C’est pourquoi une telle fonctionnalité ne sera disponible que si les administratrices choisissent de l’activer sur leurs plateformes PeerTube, et affichera la date où le fichier a été remplacé sur les vidéos mises à jour..

Ajoutez des chapitres à vos vidéos !

Les vidéastes peuvent désormais ajouter des chapitres à leurs vidéos sur PeerTube. Dans la page des paramètres de la vidéo, ils obtiendront un nouvel onglet « chapitres » où ils n’auront qu’à spécifier le timecode et le titre de chaque chapitre pour que PeerTube l’ajoute.

S’ils importent leur vidéo depuis une autre plateforme (*tousse* YouTube *tousse*), PeerTube devrait automatiquement reconnaître et importer les chapitres définis sur cette vidéo distante.

Lorsque des chapitres sont définis, des marqueurs apparaissent et segmentent la barre de progression. Les titres des chapitres s’affichent lorsque vous survolez ou touchez l’un de ces segments.

Tests de charge, performances et recommandations de configuration

L’année dernière, grâce à l’émission « Au Poste ! » du journaliste français David Dufresne et à son hébergeur Octopuce, nous avons eu droit à un test de charge du direct avec plus de 400 spectateurices simultanés : voir le rapport ici sur le blog d’Octopuce.

De tels tests sont vraiment utiles pour comprendre où nous pouvons améliorer PeerTube pour réduire les goulots d’étranglement, améliorer les performances, et donner des conseils sur la meilleure configuration pour un serveur PeerTube si un administrateur prévoit d’avoir beaucoup de trafic.

C’est pourquoi cette année, nous avons décidé de réaliser plus de tests, avec un millier d’utilisateurs simultanés simulés à la fois dans des conditions de direct et de diffusion de vidéo classique. Nous remercions Octopuce de nous avoir aidé·es à déployer notre infrastructure de test. 

Nous publierons bientôt un rapport avec nos conclusions et les configurations de serveurs recommandées en fonction des cas d’utilisation (fin 2023, début 2024). En attendant, les premiers tests nous ont motivés à ajouter de nombreuses améliorations de performances dans cette v6, telles que (préparez-vous aux termes techniques) :

• Traiter les tâches HTTP unicast dans les worker threads
• Signer les requêtes ActivityPub dans les worker threads
• Optimisation des requêtes HTTP pour les vidéos recommandées
• Optimisation des requêtes SQL pour les vidéos lors du filtrage sur les directs ou les tags
• Optimiser les endpoints /videos/{id}/views avec de nombreux spectateurs
• Ajout de la possibilité de désactiver les journaux HTTP de PeerTube

…et il y en a toujours plus !

Une nouvelle version majeure s’accompagne toujours de son lot de changements, d’améliorations, de corrections de bogues, etc. Vous pouvez lire le journal complet ici (en Anglais), mais en voici les grandes lignes :

• Nous avions besoin de régler une dette technique : la version 6 supprime la prise en charge de WebTorrent pour se concentrer sur HLS (avec P2P via WebRTC). Les deux sont des briques techniques utilisées pour diffuser en pair à pair dans les navigateurs web, mais HLS est plus adapté à ce que nous faisons (et prévoyons de faire) avec PeerTube
• Le lecteur vidéo est plus efficace
  • Il n’est plus reconstruit à chaque fois que la vidéo change ;
  • Il conserve vos paramètres de visionnage (vitesse, plein écran, etc.) lorsque la vidéo change ;
  • Il ajuste automatiquement sa taille en fonction du ratio de la vidéo ;
• Nous avons amélioré le référencement, pour aider les vidéos hébergées sur une plateforme PeerTube à apparaître plus haut dans les résultats des moteurs de recherche ;
• Nous avons beaucoup travaillé sur l’amélioration de l’accessibilité de PeerTube à plusieurs niveaux, afin de simplifier l’expérience des personnes en situation de handicap.

Cliquez pour nous soutenir et repousser Yetube – CC-By Illustration David Revoy

Qu’en est-il de l’avenir de PeerTube ?

Alors que YouTube fait la guerre aux bloqueurs de publicité, que Twitch exploite de plus en plus les vidéastes et que tout le monde est de plus en plus conscient de la toxicité de ce système, PeerTube est en train de gagner du terrain, est de plus en plus reconnu et voit sa communauté grandir.

Nous avons tellement d’annonces à faire sur l’avenir que nous prévoyons pour PeerTube, que nous publierons une annonce séparée, dans deux semaines. Nous prévoyons également d’organiser un direct, afin de répondre aux questions que vous vous posez sur PeerTube. 

Vous resterez au courant en vous abonnant à la Lettre d’information de PeerTube, en suivant le compte Mastodon de PeerTube ou en surveillant le Framablog.

Cliquez pour nous soutenir et aider Sepia à repousser Videoraptor – Illustration CC-By David Revoy

Merci de soutenir PeerTube et Framasoft

En attendant, nous voulons vous rappeler que tous ces développements ont été réalisés par un seul développeur rémunéré, un stagiaire, et une fabuleuse communauté (beaucoup de datalove à Chocobozzz, Wicklow, et les nombreuses, nombreux contributeurs : vous êtes toustes incroyables !)

Framasoft étant une association française à but non lucratif principalement financée par des dons (75 % de nos revenus annuels proviennent de personnes comme vous et nous), le développement de PeerTube a été financé par deux sources principales :

• les francophones sensibilisées aulogiciel libre
• Les subventions de l’initiative Next Generation Internet, par l’intermédiaire de NLnet (en 2021 et 2023).

Si vous êtes un afficionado non francophone de PeerTube, merci de soutenir notre travail en faisant un don à Framasoft. Cela nous aidera grandement à financer nos très nombreux projets, et à équilibrer notre budget 2024.