Mon utilisation accidentelle de Blender VSE

 (aras-p.info)
1 points par GN⁺ 2024-02-09 | 1 commentaires | Partager sur WhatsApp
  • Aras ne savait même pas que Blender disposait d’un Video Sequence Editor (VSE), mais après une visite au Blender HQ, il a contribué pendant environ deux mois à temps partiel à des améliorations de performances et de qualité pour Blender 4.1
  • Le changement le plus visible concerne la réactivité de la timeline : dans le projet Sprite Fright, avec environ 3 000 strips visibles, l’UI de défilement et de panoramique est passée d’environ 15 fps à plus de 60 fps
  • Du multithreading, du SIMD et des simplifications mathématiques ont été appliqués à la conversion RGB↔YUV basée sur ffmpeg, au rééchantillonnage audio Audaspace, aux transformations et filtres d’image, ainsi qu’au traitement des effets VSE
  • Sur trois jeux de données de Blender Studio, le temps de rendu final des films VSE sur le PC de l’auteur a été accéléré d’environ 2×, et le rendu de Sprite Fright est passé de presque 13 minutes à 7 minutes
  • Au total, 37 pull requests ont été relues et fusionnées ; les changements sont actuellement intégrés à Blender 4.1, et le travail sur VSE devrait se poursuivre à partir de Blender 4.2

Comment il en est venu à contribuer à Blender VSE

  • Aras s’est rendu à Amsterdam pour assister à Unite 2023 de Unity, puis a profité de son temps libre pour visiter le Blender HQ
  • Sur place, Francesco et Sergey lui ont demandé s’il voulait contribuer à VSE, et il a ensuite commencé à toucher au Video Sequence Editor de Blender
  • Même s’il connaissait mal le montage vidéo, les timelines, les séquenceurs, l’étalonnage colorimétrique, ffmpeg et le mixage audio, il a commencé par des optimisations de performances, moins sujettes à controverse
  • Après environ deux mois de travail à temps partiel, un ensemble d’améliorations destinées à Blender 4.1 a vu le jour
    • Blender 4.1 est passé en bêta et peut être téléchargé via les daily builds classiques

Dessin de la timeline et réactivité de l’UI

  • La timeline VSE se trouve dans la partie inférieure de l’écran, et lorsqu’on dézoome sur l’ensemble du projet Sprite Fright edit, environ 3 000 strips sont visibles en même temps
  • Auparavant, le simple défilement ou panoramique dans cette timeline limitait le rafraîchissement de l’UI à environ 15 fps
  • Après les changements, elle fonctionne à plus de 60 fps
  • Le goulot d’étranglement venait d’une architecture qui soumettait les draw calls de l’API graphique par groupes de deux triangles ; dans le profiler Superluminal, la majeure partie du temps était passée dans les fonctions « démarrer le dessin d’un quad » et « terminer le dessin d’un quad »
  • Au passage, le comportement anormal de l’affichage des waveforms audio a aussi été corrigé et l’UI affinée ; l’affichage des waveforms est désormais activé par défaut

Amélioration de la qualité et de la vitesse d’affichage des scopes

  • VSE propose des options d’affichage de scopes classiques comme l’histogramme d’image, la waveform et le vectorscope
  • L’histogramme était dessiné sous forme d’image pixelisée avec une saturation très forte ; il s’affiche désormais avec des polygones plus lisses, une grille et une saturation plus faible
  • L’option parade de la waveform avait tendance à saturer trop vite et est devenue 15× plus rapide après l’ajout du multithreading
  • L’hexagone coloré extérieur du vectorscope était très pixelisé ; le design mis à jour du vectorscope de l’éditeur d’images a été repris
  • L’option zebra stripes, qui sert à afficher les zones surexposées, est également devenue 2 à 3× plus rapide
  • Il ajoute aussi qu’à terme, tous les scopes, y compris ceux de l’éditeur d’images, devraient être traités par des compute shaders GPU

Optimisation de la conversion RGB↔YUV de ffmpeg

  • Blender utilise principalement la bibliothèque ffmpeg pour lire et écrire l’audio et la vidéo
  • En interne, Blender n’utilise pas l’outil en ligne de commande ffmpeg, mais des bibliothèques de code comme libavcodec, tandis que libswscale se charge de la conversion RGB↔YUV des images de film
  • libswscale prend en charge la conversion multithread, mais si l’on utilise simplement sws_getContext() et sws_scale(), tout s’exécute en mono-thread
  • Pour utiliser le multithreading, il faut définir le paramètre "threads" lors de l’initialisation, ce qui impose d’utiliser directement sws_alloc_context(), av_opt_set_int() et sws_init_context()
  • De plus, sws_scale() n’effectue pas de multithreading en interne, il a donc fallu utiliser sws_scale_frame(), ce qui a aussi révélé un problème dans la façon de créer les AVFrame
  • Résultat : lors de l’écriture de fichiers vidéo, la conversion RGB→YUV est devenue nettement plus rapide
  • Pour la lecture de fichiers vidéo, une conversion YUV→RGB multithread est également utilisée, et le vertical flip a été fusionné dans la même opération

Rééchantillonnage audio

  • Lors du rendu vidéo dans VSE, il est apparu que près de la moitié du temps passé à « générer une frame vidéo ou audio » l’était dans Audaspace, la bibliothèque audio utilisée par Blender
  • Le goulot d’étranglement n’était pas l’encodage audio, mais le mixage avant encodage ; l’essentiel du temps était consacré au rééchantillonnage lorsque des strips audio, par exemple en 44,1 kHz, étaient mélangés dans un film à 48 kHz
  • Audaspace proposait deux modes de rééchantillonnage
    • Lecture interne de Blender : Linear resampler, qui interpole linéairement entre les échantillons
    • Rendu vidéo : rééchantillonneur basé sur l’algorithme de Julius O Smith
  • La qualité des rééchantillonneurs a été comparée en rééchantillonnant un son synthétique dont la fréquence unique augmente, puis en observant le spectrogramme
    • L’objectif est d’obtenir un résultat avec le moins possible de fréquences supplémentaires, comme avec le réglage « best » d’Audacity
  • Le rééchantillonnage de preview d’Audaspace était rapide à calculer, mais créait de nombreuses fréquences supplémentaires, tandis que le rééchantillonnage de rendu donnait un spectrogramme de bonne qualité
  • Une nouvelle qualité de rééchantillonnage medium a été ajoutée à Audaspace ; selon l’auteur, elle produit un résultat presque identique tout en étant environ 3× plus rapide à calculer
  • Blender utilise désormais ce réglage medium lors du rendu
    • Sur un PC Windows Ryzen 5950X, le rendu de 2 000 frames de Sprite Fright est passé de 92 secondes à 73 secondes
    • PR associée : #116059

Transformations et filtrage d’image

  • Dans VSE, les strips qui produisent un résultat visuel — image, film, texte, scene, etc. — peuvent se voir appliquer une position, une rotation, une échelle et un crop
  • Ces transformations consistent à transformer l’image produite par le strip en une nouvelle image ; elles étaient déjà traitées en multithread sur CPU
  • La raison pour laquelle cela se fait sur CPU plutôt que sur GPU est qu’il n’existe pas encore d’implémentation GPU, et qu’un fallback CPU reste pour l’instant nécessaire pour les cas d’usage où l’on veut rendre sur des render farms dépourvues de GPU

  • Correction des erreurs d’un demi-pixel

    • Le code existant contenait plusieurs erreurs de type off by half a pixel ; dans de nombreux cas, elles se compensaient ou restaient invisibles, mais elles apparaissaient dans certaines situations
    • Lorsqu’une petite image était agrandie 16×, le filtre Bilinear décalait l’image d’un demi-pixel d’origine, et la couleur d’arrière-plan magenta venait aussi s’incruster
    • À l’inverse, lors d’une réduction exacte d’une image par 2, le filtre Bilinear n’effectuait aucun filtrage
    • Les erreurs « off by something » de Bilinear et d’autres filtres ont été corrigées
    • PR associée : #116628

  • Gestion des bords transparents avec Bilinear

    • Avant Blender 4.0, VSE proposait trois options de filtre : Nearest, Bilinear et Subsampled3x3, et seul Bilinear ajoutait autour de l’image résultante une transparence d’une largeur équivalente à un demi-texel source
    • Ce comportement se voyait lors de l’agrandissement de médias, et plus personne ne se souvenait pourquoi cette différence existait
    • Le comportement consistant à « blender vers la transparence » a été retiré du code du filtre Bilinear de VSE
    • Toutefois, lorsqu’une simple rotation est appliquée, l’ancien traitement de la transparence produisait une forme d’anticrénelage sur les bords ; à la place, un anticrénelage de transparence est appliqué aux pixels de bord de l’image de destination
    • PR associée : #117717

  • Filtres Cubic, Box et Auto

    • Les transformations de strips VSE classiques ne proposaient pas d’option de filtre cubic, celle-ci n’existait que dans le strip spécial Transform Effect
    • Dans Blender, « Bicubic » désigne en réalité un filtre Cubic B-Spline, équivalent au filtre de Mitchell-Netravali avec les coefficients B=1, C=0
    • L’auteur le résume comme un choix « sans ringing, mais avec beaucoup de flou »
    • Deux types d’options de filtrage cubic ont été ajoutés à VSE
    • PR associées : #117100, #117517
    • Le filtre « Subsampled 3x3 » de Blender 3.5 était en réalité un box filter codé en dur en taille 3x3, et commençait à s’effondrer lors des réductions avec un ratio différent de 3x3
    • Ce filtre a été remplacé par un Box filter ajusté plutôt que fixé à 3x3
    • PR associée : #117584
    • Comme les utilisateurs ont désormais davantage de filtres à choisir, une option de filtre Auto a été ajoutée comme valeur par défaut des strips VSE
    • PR associée : #117853
    • S’il n’y a ni mise à l’échelle ni rotation : Nearest
    • Si l’agrandissement dépasse 2× : Cubic Mitchell
    • Si la réduction dépasse 2× : Box
    • Sinon : Bilinear

  • Amélioration des performances du filtrage

    • Le processus de filtrage d’image est lui aussi devenu plus rapide
    • Suppression de virtual functions dans la boucle interne, application partielle de SIMD au filtrage Bilinear : #115653
    • Simplification du filtrage Cubic et ajout de SIMD : #117100
    • Simplification mathématique du Box filter : #117125
    • Correction d’un problème empêchant une optimisation de fonctionner avec du scale, alors qu’elle permet de sauter les éléments situés sous une image pleine couvrant tout l’écran : #117786
    • Sur le PC de l’auteur, dans un projet 3840x2160 avec une seule image 1920x1080 agrandie 2× et un filtrage Bilinear, le dessin complet de la preview du séquenceur est passé de 36,8 ms à 15,9 ms
    • Une page interactive de comparaison des filtres d’upsampling est également proposée : aras-p.info/img/misc/upsample_filter_comp_2024

Optimisation des effets VSE

  • Les jeux de données de films réels de Blender Studio utilisaient peu d’effets, mais les effets VSE ont aussi été optimisés en se concentrant sur les parties visibles dans le code
  • La plupart des changements consistent à appliquer du multithreading
    • Glow effect : multithreading appliqué, 6 à 10× plus rapide #115818
    • Wipe effect : multithreading appliqué, simplification des calculs trigonométriques excessifs du Clock wipe, 6 à 20× plus rapide #115837
    • Gamma Cross effect : remplacement d’une approche complexe utilisant une table et de l’interpolation pour éviter un appel à la racine carrée, ce qui l’a rendu 4× plus rapide #115801
    • Gaussian Blur effect : évitement de calculs redondants, 1,5× plus rapide #116089

Évolution du temps de rendu final

  • Sur la base de trois jeux de données fournis par Blender Studio, le temps de rendu final des films VSE sur le PC de l’auteur est devenu environ 2× plus rapide
  • Le rendu de Sprite Fright edit est passé de presque 13 minutes à 7 minutes
  • L’auteur espère d’autres gains de vitesse, formulant l’idée que « trois accélérations de 2× supplémentaires, ce serait pas mal »

Méthode de travail et prochaines étapes

  • En plus des changements visibles par les utilisateurs, des pull requests ont été consacrées à l’ajout de tests, au refactoring et au nettoyage ; au total, 37 pull requests ont été terminées, relues et fusionnées
  • L’auteur estime qu’un tel travail aurait probablement été difficile à accomplir dans un « vrai travail »
    • Il indique qu’entre 2015 et 2022 chez Unity, il aurait sans doute réalisé environ 30 % de ce travail dans le même temps, voire moins
    • Il ajoute que cela aurait peut-être été possible dans l’Unity « antique » des environs de 2010
  • Il estime que lorsque la taille de l’entreprise, les processus, les attentes, la communication et la politique s’entremêlent, le même travail peut devenir plus lent, voire être annulé en cours de route, dans un environnement d’entreprise rémunéré
  • Il espère que Blender n’évoluera pas vers une taille, une complexité ou un workflow où les processus découragent et ralentissent les gens plutôt que de les aider
  • Blender 4.1 étant passé en bêta, son périmètre fonctionnel est finalisé, et les changements VSE de la version 4.1 sont actuellement intégrés aux release notes
  • Le travail sur Blender 4.2 commence, et il compte continuer à toucher à VSE sans plan précis par la suite
    • L’avancement peut être suivi dans la section Weekly Updates du forum

À lire aussi

1 commentaires

 
GN⁺ 2024-02-09
Avis sur Hacker News

  • Je pense que je n’aurais pas pu faire ce genre de chose si cela avait été un « vrai travail »
    S’il y a quelque chose qui n’a pas bien tourné dans ma carrière, c’est cette scission : sur des projets non rémunérés où je résous moi-même des problèmes mathématiques pas du tout ordinaires, j’arrive en deux mois à faire plus que ce que je fais d’habitude en deux ans, tandis que sur des projets payés, mes résultats sont globalement moyens.
    J’ai vraiment essayé dur de trouver un entre-deux, sans y parvenir ; et l’an dernier, quand la possibilité d’être payé pour un travail que je faisais gratuitement est apparue, j’ai fini par ne plus réussir à y toucher du tout.

    • Tu n’es pas seul. J’ai vécu des choses similaires toute ma vie, et cela m’a amené à remettre en question tout ce que les gens disent sur la motivation, par exemple l’idée que seuls le profit et le salaire permettent de mener un travail à son terme.
      Puis j’ai découvert la théorie de l’aliénation de Marx, et les choses ont commencé à avoir beaucoup plus de sens. Il partait de l’observation que le travail est une activité principalement pratiquée par des personnes en bonne santé, mais estimait qu’il ne fallait pas confondre cela avec le fait de travailler pour autrui et d’être aliéné du produit de son propre travail.
      https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
    • Aucun des travaux les plus remarquables ou intéressants que j’aie faits jusqu’ici n’a été rémunéré.
    • La gestion de projet tue complètement ce genre de travail.
      Certains endroits ont un bon système qui prévoit une zone tampon d’une ou deux semaines pendant laquelle on peut faire ce qu’on veut, et cela atténue ce problème.
    • Les travaux les plus gratifiants et les plus influents que j’aie faits ont tous été très peu rémunérés, voire pas du tout. J’ai désormais l’impression que c’est difficile à éviter, et cela rend le travail logiciel un peu déprimant.
    • C’est un phénomène assez intéressant, et je pense qu’il vient surtout de la taille des équipes et de la nécessité de gagner de l’argent.
      Dans un projet passion, comme on n’est pas payé, les attentes sont faibles, on n’a pas vraiment d’obligation de produire quelque chose, et on est en pratique libre de faire ce qu’on veut. On choisit donc des tâches intéressantes et utiles pour soi, comme explorer de nouvelles technologies ou de nouveaux outils qui nous attirent.
      Dès que l’argent entre en jeu, les attentes de la personne qui paie entrent aussi en jeu, et les tentatives nouvelles et inconnues deviennent plus difficiles parce qu’elles ont davantage de chances d’échouer.
      Au bout du compte, quand il y a de l’argent en jeu, les gens évitent les pistes risquées même s’il existe potentiellement de meilleures solutions, et préfèrent des résultats prévisibles.

  • C’est vraiment impressionnant, et il est clair que l’auteur du billet n’est pas simplement entré par hasard dans les locaux de Blender. Sa longue expérience chez Unity a probablement beaucoup aidé à comprendre ce domaine.
    J’ai particulièrement aimé ce changement [1]. En optimisant l’étape de traitement d’image, il a supprimé beaucoup d’« optimisations » à base de tables pour les remplacer simplement par des calculs en virgule flottante, ce qui a rendu l’opération environ 4 fois plus rapide sur la machine de l’auteur. Excellent.
    [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

    • Et ce n’est pas tout : si on regarde le diff, il a remplacé 100 à 150 lignes de code par 3 lignes. C’est le genre de pull request qu’on ne peut imaginer faire qu’en rêve.
    • C’est une bonne optimisation, mais je me demande si return c * c; est vraiment une bonne approximation du gamma sRGB.

  • Ce que je préfère depuis quelques années, c’est de voir Aras débarquer dans divers projets graphiques open source, y apporter d’énormes gains de performance et améliorations, puis passer à un autre projet graphique au hasard et recommencer.

  • J’aimerais faire ce genre de chose avec le lecteur de musique que j’utilise, MusicBee.
    S’il était open source, en tout cas. Son créateur n’y touche presque plus désormais ; il a toujours été entièrement gratuit, alors je ne comprends pas pourquoi il n’est pas open source.
    Il y a tellement de petits problèmes agaçants, de détails cassés, lents ou bizarres, que j’aimerais vraiment les corriger sur mon temps libre.
    Et passer maintenant à autre chose comme FooBar représenterait beaucoup trop de travail. J’ai aussi essayé HQPlayer, mais son UI/UX est tellement épouvantable que je n’ai pas pu faire la transition.

    • Comme Steven l’a déjà dit à plusieurs reprises en 2013, il n’avait pas l’intention de rendre MusicBee open source dans un avenir proche.
      Il disait que publier le code source ferait partie des options envisageables s’il n’avait plus envie de poursuivre le projet, mais que c’était un projet personnel fait par plaisir de programmer, et qu’il ne serait jamais géré de manière professionnelle.
      Il ajoutait qu’il passait déjà assez de temps à gérer des gens dans son travail principal et ne voulait pas faire la même chose ici ; et que les personnes préoccupées par des scénarios du type « et s’il se faisait renverser par un bus ? » feraient mieux d’utiliser une autre application.
      https://web.archive.org/web/20170721042120/https://getmusicb...
    • Parce qu’au moment où l’on rend un projet logiciel open source, il devient un projet de gestion de personnes.
    • Écrire du code pour en faire un projet open source exige un niveau de finition bien plus élevé que ce que les gens imaginent. C’est beaucoup plus de travail que de simplement faire en sorte que le programme fonctionne bien.
    • Il existe une alternative : tout réécrire en open source.
    • MusicBee a été le seul logiciel qui m’a vraiment manqué après avoir arrêté d’utiliser Windows.
      S’il était maintenu, j’aurais envisagé de le faire tourner avec Wine, mais aujourd’hui j’ai abandonné l’idée même de gestionnaire de musique et je lance simplement les albums que j’écoute avec mpv. Et j’écoute toujours par album. Les playlists, très peu pour moi.

  • Depuis 2020, j’utilise Blender VSE pour tout mon montage vidéo, et c’est vraiment agréable de le voir s’améliorer.
    Vu sa stabilité et son ensemble de fonctionnalités, je le considérais déjà comme le meilleur éditeur vidéo sous Linux. Le fait de pouvoir utiliser tous les outils d’animation existants de Blender est aussi un avantage.

  • VSE a vraiment besoin de beaucoup d’amour. Je voulais utiliser uniquement des outils open source pour mon podcast, mais le rendu d’une séquence mp4 avec chroma key dans Blender a pris 10 heures pour une vidéo de 1,5 heure
    J’ai finalement basculé vers la version gratuite de DaVinci Resolve

    • Blender VSE ne dispose actuellement d’aucune accélération GPU pour le rendu vidéo, donc le CPU traite toute la tâche
      De plus, même quand aucun réencodage n’est nécessaire, il ne sait pas sauter cette étape comme DaVinci Resolve et rend chaque frame une par une. Si ce point était amélioré, cela aiderait beaucoup les performances et l’efficacité de Blender
    • Le rendu multithread de Blender a le problème de ne pas bien s’adapter aux tâches VSE. Il se concentre sur le découpage de chaque frame, ce qui exploite mal plusieurs cœurs
      Il y a quelque temps, j’ai expérimenté un plugin [1] qui lançait plusieurs tâches de rendu comme processus séparés à différents endroits de la timeline, et cela pouvait fortement accélérer le rendu
      Aujourd’hui, même sous Linux, je suis passé à Resolve, car j’utilise des caméras Blackmagic et cela convient mieux à mon workflow
      [1] https://github.com/AkBKukU/blenderSubprocessRender
    • J’ai utilisé VSE sur un projet. C’était pénible, mais j’ai obtenu un résultat, et à l’époque c’était clairement le meilleur éditeur vidéo logiciel gratuit
      Maintenant, je travaille sur la nouvelle version avec Final Cut Pro

  • Rendre plus rapide n’importe quelle partie du programme 3D Blender me semble assez difficile. C’est déjà de loin l’application 3D qui démarre le plus vite, et son GUI est aussi le plus réactif
    Houdini arrive bien en deuxième, mais pas vraiment tout près

    • Étonnamment, il reste encore beaucoup de fruits à portée de main
      Il y a quelques années, en touchant au code du générateur « blobby », j’ai ajouté du multithreading et je l’ai rendu beaucoup plus lent. Une fois l’overhead du multithreading dépassé, cela devenait plus rapide, mais de mémoire cela n’entrait pas vraiment dans les cas d’usage courants, donc j’ai abandonné. J’ai sûrement aussi fait quelques erreurs
    • J’ai regardé une partie du code et je pense qu’il reste beaucoup de marge d’amélioration. Comme dans l’article, il y a une quantité surprenante de code qui, sous couvert d’optimisation, adopte une approche très complexe mais a en réalité autant de chances de ralentir les choses
      Par exemple, le texture painting fait quelque chose comme trois indirections de pointeur par pixel, et ça saccade pas mal même sur mon PC
    • Il y a énormément de marge d’amélioration dans les outils d’animation, et il semble qu’un travail soit effectivement en cours. La transition vers Vulkan semble aussi pouvoir beaucoup aider

  • L’article disait : « Saviez-vous que Blender contient une suite d’outils de montage vidéo ? Moi non plus :) », mais je pense que la plupart des gens qui créent des animations avec Blender le savent
    Parce que c’est la méthode de base pour transformer les frames rendues en fichier vidéo

    • On peut rendre directement les frames en fichier vidéo (options ffmpeg), et je pense que beaucoup de débutants ou d’utilisateurs occasionnels font comme ça
      On peut aussi utiliser le compositeur pour transformer une séquence de frames prérendues en fichier vidéo
      Cela dit, la plupart préfèrent sans doute faire le montage vidéo dans un autre programme comme Resolve, et VSE semble cantonné à un créneau étroit du type « j’ai besoin de coupes basiques, mais pas de transformations, titres ni effets », donc il n’est pas beaucoup utilisé
      Ce serait bien que quelqu’un continue d’améliorer les transformations et les effets, et ajoute un jour le montage en trois points

  • Ah, c’était Aras. Il est excellent. Il me semble que son nom complet était Really Great Aras
    Il est très fort en programmation graphique, entre autres, et semble aussi avoir un bon état de flow quand il code
    Ses articles sont agréables et amusants à lire. On a l’impression d’écouter quelqu’un parler. Même des phrases comme « However! » au milieu donnent cet effet
    Je comprends aussi la partie finale, où il dit que dans une entreprise classique, quand on est écrasé par les attentes de culture et de processus standards, la productivité tombe à 30 %. Le coût de garder les employés attachés à « leur travail » inclut réellement une énorme perte de productivité
    J’aimerais qu’en voyant sans cesse ce genre d’exemples, les techniciens apprennent à mieux organiser les personnes et les activités, fassent confiance à ces apprentissages, et commencent à intégrer la haute productivité / forte immersion dans les modes d’organisation réels
    Comme le suggère l’article, cela pourrait rendre le travail dans la tech plus agréable. Presque aussi amusant que de jouer avec la technologie

  • Pour ajouter quelque chose à propos de https://projects.blender.org/blender/blender/pulls/116089, inline affecte avant tout la règle de définition unique
    En bref, si vous définissez une fonction dans un header et l’appelez depuis plusieurs fichiers .cc, vous aurez une erreur de l’éditeur de liens à moins de la marquer inline
    Son effet sur la véritable optimisation d’inlining varie de « aucun » à « le compilateur peut pondérer différemment à cause du mode de liaison », voire « il le prend réellement comme indice », et des considérations similaires existent aussi avec l’optimisation au moment de l’édition de liens
    Pour donner au compilateur un signal d’inlining beaucoup plus fort, surtout s’il s’agit d’une fonction utilisée uniquement dans le fichier où elle est définie, il vaut mieux la définir dans un namespace anonyme
    L’intention initiale derrière l’ajout de inline à cette fonction était peut-être d’essayer d’obtenir une véritable inline expansion. Le gain mesurable n’est pas évident, mais ce n’est pas impossible