'lut les gens,
Depuis quelque temps mon outil de montage vidéo kdenlive me déçoit de plus en plus, je le trouve de plus en plus lent et j'ai perdu les 3/4 des effets qui pouvaient exister par le passé (dont ceux apportés par frei0r). Il devient impossible de monter sans activer les clips intermédiaires, fonction qui permet de dégrader la vidéo lors du montage, mais qui préserve la qualité au rendu de la vidéo finale. Et encore ça reste très lent et laborieux dès qu'on rajoute des effets et transitions un tant soit peu compliqués. Et dire qu'avec les anciennes versions 0.9.X sous Qt4 c'était parfaitement fluide de monter en HD et on disposait d'un stock considérable d'effets (même si dans la pratique j'en utilisais à peine 10%). Il semblerait que mes problèmes avec kdenlive remontent au passage du moniteur SDL à OpenGL et à la migration de Qt4 (kdenlive <=0.9x) vers Qt5 (kdenlive >=15.x). J'ai constaté un ralentissement général, voire des régressions fonctionnelles et la réapparition de plantage qui avait totalement disparu avec les dernières versions sous Qt4. Il se trouve qu'il existe l'extension movit qui permet de faire bosser un peu plus la GPU et quand je l'activais tout revenait dans l'ordre, je retrouvais la fluidité perdue, sauf que ça plantait toutes les 5min :-( .
Il faut croire que tout le monde ne souffre pas du même problème, j'ai pensé à un problème de compatibilité matérielle mais j'ai quand même un i7 avec 16Go de RAM. J'ai également soupçonné ma carte NVIDIA GTX 760 d'être la source de mes ennuis, j'ai même songé à la changer. Finalement j'ai exploré la voie de l'accélération matérielle, ça permet de décharger le CPU et la mémoire principale et de solliciter davantage le GPU et la mémoire de la carte graphique, notamment pour tous les calculs d'encodage et de décodage vidéo et d'une manière générale de traitement vidéo. Concrètement, comme à mon habitude en vieux dinosaure que je suis, j'ai récupéré les sources et tout recompilé. J'ai donc activé toutes les fonctions d'accélérations matérielles des différentes bibliothèques sur lesquelles se repose directement et indirectement kdenlive. Pour une GPU NVIDIA il s'agit d'activer les bibliothèques et API suivantes :
- VDPAU (Video Decode and Presentation API for Unix) bibliothèque développée par NVIDIA,
- NVENC et NVDEC pour l'encodage et le décodage vidéo notamment des codecs H264 et HEVC, ils sont compris dans le package NVIDIA VIDEO CODEC SDK (ex CUVID) et utilisent CUDA (Compute Unified Device Architecture) qui pour simplifier est une boîte à outil de développement pour les GPU également développée par NVIDIA.
- OpenCL (OpenComputing Language) qui permet de faire des programmes qui vont utiliser à la fois des CPU multi cœurs et la GPU.
- OpenCV qui sert pour le traitement d'images en temps réel notamment pour faire du tracking d'éléments dans une vidéo.
Ensuite on compilera des outils comme ffmpeg, qui comme chacun le sait une boîte à outils de traitement de flux audio ou vidéo, avec les options d'accélération matérielle qui vont bien. Quand on tape ffmpeg -encoders on doit pouvoir retrouver cela :
V..... libx264 libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (codec h264)
V..... libx264rgb libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 RGB (codec h264)
V..... h264_nvenc NVIDIA NVENC H.264 encoder (codec h264)
V..... h264_v4l2m2m V4L2 mem2mem H.264 encoder wrapper (codec h264)
V..... h264_vaapi H.264/AVC (VAAPI) (codec h264)
V..... nvenc NVIDIA NVENC H.264 encoder (codec h264)
V..... nvenc_h264 NVIDIA NVENC H.264 encoder (codec h264)
V..... libx265 libx265 H.265 / HEVC (codec hevc)
V..... nvenc_hevc NVIDIA NVENC hevc encoder (codec hevc)
V..... hevc_nvenc NVIDIA NVENC hevc encoder (codec hevc)
V..... hevc_v4l2m2m V4L2 mem2mem HEVC encoder wrapper (codec hevc)
V..... hevc_vaapi H.265/HEVC (VAAPI) (codec hevc)
Certes je me focalise sur une GPU NVIDIA, mais j'imagine qu'il existe des bibliothèques et outils équivalents pour les GPU Intel ou AMD.
Revenons à kdenlive, je m'étais pris la tête avec un projet sur lequel je me cassais les dents avec des lenteurs et des plantages continuels. Mes problèmes de montage de ce projet ne se sont pas améliorés en tentant de changer de version ou en partant d'une configuration vierge (c'est à dire en supprimant le fichier kdenliverc). Finalement je suis parti d'un tout nouveau projet avec la dernière version 19.12.0 qui vient de sortir. Et là magique, j'ai retrouvé la fluidité de montage, même plus besoin d'activer les clips intermédiaires ! Je ne saurais dire si ça vient des évolutions de performances emmenées par cette nouvelle version ou la prise en compte de l'accélération matérielle, je penche quand même plutôt pour cette dernière option.
Tant qu'à faire un petit mot sur cette version 19.12.0 qui apporte son lot de nouvelles fonctionnalités qui sont détaillées là.
Tout d’abord on va retrouver un mixer audio (en haut à droite de l’image) avec des possibilités de réglage et d’enregistrement des voies audio. Il est également possible d’appliquer un effet à l’ensemble des pistes, il faut cliquer sur bouton Master, et glisser un effet dans la zone Master effects (ici effet Contraste). En se déplaçant sur la timeline on voit que l’effet est appliqué partout. On peut également comparer une séquence vidéo avec ou sans effet, dans l’effet Saturation ci-dessous j’ai cliqué sur la première icône à droite de GOPRO124.MP4 effets. On voit bien la différence sur la vidéo ci-dessous.
Alors certes il manque encore un paquet d'effets mais j'ose espérer qu'avec le temps, ça va s'enrichir de ce côté. Bref, j'ai mis à jour mon site FUNIX pour prendre en compte toutes ces modifications, voir en particulier la page sur l'installation des bibliothèques et celle sur les outils de montage vidéo. Côté utilisation mis à part les nouveautés ci-dessus le tutorial kdenlive est encore bien à jour.
Pour les curieux la vidéo qui m'a posé bien des soucis car le projet avait été entamé avec une version sans accélération matérielle est visible ici et ma première vidéo entièrement faite avec la 19.12.0 et l'accélération matérielle est par là.
# Sans recompiler?
Posté par tisaac (Mastodon) . Évalué à 3.
Merci pour ces infos.
Je me demandais si on pouvait activer ces différentes accélérations sans être un dinosaure qui aime tout recompiler.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Sans recompiler?
Posté par Funix (site web personnel, Mastodon) . Évalué à 4.
Ça va dépendre comment les packages par défaut ont été compilés, si de base l'accélération matérielle n'a pas été prise en compte il ne sera pas possible de l'activer après coup. Certains softs te permettent de savoir comment ils ont été compilés, exemple avec ffmpeg
ffmpeg version 4.2.1 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 8.3.1 (Mageia 8.3.1-0.20191101.1.mga7) 20191101
configuration: --enable-shared --enable-gpl --enable-postproc --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libxvid --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-nonfree --enable-frei0r --enable-libpulse --enable-version3 --enable-avresample --enable-opengl --enable-opencl --disable-stripping --enable-libgsm --enable-libvpx --enable-avfilter --enable-chromaprint --enable-libvidstab --enable-vdpau --enable-libnpp --enable-cuda-nvcc --enable-ffnvcodec --enable-libopencv --enable-libdc1394 --extra-ldflags=-L/usr/lib64
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...
https://www.funix.org mettez un manchot dans votre PC
# Package distribution ou AppImage ?
Posté par Frédéric COIFFIER . Évalué à 3.
Quand tu avais des problèmes de performance, utilisais-tu le package de ta distribution (et si oui, quelle distribution ?) ou les AppImage (ou autres) fournies par les développeurs ?
Et trouves-tu que cette nouvelle version est plus stable que les précédentes ?
[^] # Re: Package distribution ou AppImage ?
Posté par Funix (site web personnel, Mastodon) . Évalué à 1.
J'ai testé également les packages de la distribution ou les appimage fournies sur le site et même comportement, lenteur, ralentissement et plantage (voire des fonctionnalités absentes), de là à en conclure qu'elles sont packagées sans accélération matérielle pour pouvoir s'adapter à toutes les configurations…
Sinon avec cette 19.12.0 je peux enfin monter sans plantage (ce que j'arrivais très bien à faire avec les version 0.9.X sous QT4 et SDL) mais je ne saurais dire si c'est dû à la version elle même ou à l'utilisation de l'accélération matérielle.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Package distribution ou AppImage ?
Posté par Anonyme . Évalué à 2.
de mon coté je suis passé d'une old old stable sur un core2duo a une buster sur un I5 à 3,2GHZ, ca se traîne grave,compiler le noyau était plus rapide en 2004 :O, du coup après quelques recherche :
options du noyau :
https://make-linux-fast-again.com/
oui oui n'ayons pas peur de le dire, cela enlève TOUTE les sécurités. Reste plus cas recompiler le noyau pour désactiver l'entropie de random au démarrage et tout redeviens rapide !
[^] # Re: Package distribution ou AppImage ?
Posté par Funix (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 23 décembre 2019 à 15:04.
oulà, je n'ai pas recompilé un noyau depuis des lustres ! Mais ça me tente, juste pour le fun d'autant qu'il n'y a rien d'irréversible avec la possibilité de booter sur un noyau ou un autre.
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Package distribution ou AppImage ?
Posté par barmic 🦦 . Évalué à 2.
Ça ne demande pas de recompiler le noyau, c'est juste des paramètre à passer au boot.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Package distribution ou AppImage ?
Posté par Anonyme . Évalué à 3.
oui et non, il faut que l'option soit activé pour pouvoir la desactiver
[^] # Re: Package distribution ou AppImage ?
Posté par moi1392 . Évalué à 7.
Effectivement, mais d'un autre coté, ne pas pouvoir désactiver une option désactivée, je devrais pouvoir m'en remettre…
# Merci pour ça
Posté par Sébastien Rohaut . Évalué à 1.
Je trouve que c'est un beau journal, qui devrait être transformé en dépêche tant il serait utile pour tous ceux qui ont des soucis de performances.
# Ah !
Posté par AlexTérieur . Évalué à 4.
J'avais eu l'idée de faire un journal de ce type. Je trouve totalement aberrant d'avoir des cartes graphiques ultra-puissantes mais exploités que pour des trucs de type "jeux"…
Je m'explique.
J'aimerai faire du montage 4K depuis que j'ai acquis du matériel capable de filmer ainsi. Je me suis dit, il doit bien avoir un logiciel même sur Linux qui exploite le potentiel des machines actuelles… Je précise que j'ai investi en conséquence, 32 Go DDR4 et Ryzen 7, le tout sur SSD ! Donc non, je ne fais pas les choses à moitié. Las : que ce soit avec Cinelerra, Shotcut et encore un autre dont j'ai oublié le nom (j'ai dû désinstallé de suite), un bête filtre de chrominance ou luminance, c'est 10 ans de retour en arrière… Et non, je ne me moque pas de Linux, parce que ce qu'il parait, sur Windows, c'est pareil ! Il faut passer par des dégradations de la vidéo initiale… C'est juste fou. Il faudra vraiment un article qui fasse le point là dessus. Je veux bien m'y investir.
[^] # Re: Ah !
Posté par Stinouff . Évalué à 3.
J'en serai un lecteur attentionné. J'utilise Kdenlive, je monte des vidéos 4K, mais je dois bien avouer que je bricole beaucoup pour des choses qui me paraissent très modernes ou simples d'usage ailleurs…!
Par exemple, j'ai récemment voulu stabiliser une vidéo…j'ai mis 5 plombes à obtenir un résultat correct, avec que les librairies existent depuis longtemps…le smartphone d'un ami a une application qui s'en occupe…qui va plus vite, qui réfléchit toute seule…qui est claire…Ça piquait un peu !
Après, Kdenlive a beaucoup évolué ces dernières années, notamment l'interface qui s'est grandement améliorée et a gagné en clarté et en stabilité.
[^] # Re: Ah !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Tout est toujours plus facile quand on est de l'autre côté du logiciel. ;-)
On se dit alors "pourquoi ils font pas ci ou ça?! C'est pourtant facile, il paraît". La réalité, c'est que rien de ce que tu dis ne sont des choses simples (et ce, même si oui, ce sont peut-être des choses qu'on faisait déjà y a 10 ans, sûrement même bien avant).
Sans t'en rendre compte, tu compares simplement des choses différentes. Par exemple, tu dis:
Mais y a 10 ans, on ne faisait pas de montage 4K! Que dis-je encore de nos jours, même les pros ne font pas si souvent du montage 4K! Déjà la majorité des films sont encore filmés/distribués en 2K. Ensuite même quand les films sont filmés en 4K (les caméras 4K deviennent de plus en plus utilisés, surtout à Hollywood) et que le film sort en version 4K (bon pour le marketing!), il paraîtrait que beaucoup de films sont édités en 2K puis convertis en 4K juste pour la sortie (a priori on ne parle même pas de proxy editing avec un rendu final 4K, mais bien d'une édition en 2K et pis c'est tout; juste réagrandi en 4K à la fin pour faire bonne mesure mais la qualité de départ n'y est plus). C'est un sujet régulièrement discuté dans des articles (quelques liens parmi les premiers dans une recherche web; je trouve même une page qui liste tous plein de films pour dire lesquels sont du vrai ou faux 4K).
Enfin bon, tout ça pour dire: le 4K, ce n'est pas encore aussi répandu que le grand public le croit (même si le marketing des productions le laisse penser). Alors pourquoi? Comparons le nombre de pixels avec le 2K (DCI pour le cinéma, pas pour la télé):
C'est quadratique, on a multiplié le nombre de pixel par 4 en multipliant les dimensions par 2. Sans compter que de nos jours, on travaille en 16-bit ou 32 bit par canal (probablement pas y a 10 ans), ça veut dire que (dans le cas 32-bit, soit 4 octets pour 3 canaux par pixel) nos 8 millions de pixels tiennent sur 4 × 3 × 4096 × 2160 = 106 168 320 octets ~ 101 MiB pour une pauvre petite image! Sauf qu'en vrai, si tu fais un peu de composition, tu vas sans doute rajouter un canal alpha (multiplie par 4/3), et tu auras sans doute plusieurs pistes (multiplie par le nombre de pistes). En outre, lorsque tu lances tes filtres, tu vas garder en général plusieurs versions de tes sources en mémoire temporairement (et aussi pour l'historique).
Sans compter le fait que le logiciel essaie si possible de garder en mémoire les images précédentes/suivantes (pour la lecture en prévisualisation). Tu arrives rapidement aux GiB de données en mémoire.
Et ça non y a 10 ans, tu ne travaillais pas avec autant de données. En plus, les filtres ne sont pas forcément linéaires. S'ils ont une complexité exponentielle, multiplier tes données par X peut signifier du temps de calcul soudainement pharamineux (et pas juste multiplié par X, ce qui serait pourtant déjà beaucoup).
Ben ça c'est justement la partie où on essaie de revenir 10 ans en arrière. À l'époque, les gens travaillaient sur des données moins grosses, donc on fait de même, et on n'utilise les données de haute qualité que pour le rendu final. Comme tu le dis, ce n'est pas spécifique à Linux ou au libre. Que ce soit sous Windows, ou avec des logiciels propriétaires, c'est aussi ce que tout le monde fait. Parce qu'il y a des limites mathématiques à ce qu'on sait faire pour accélérer les temps de calcul.
On travaille donc sur une version proxy, puis on fait le rendu final sur la version originale.
Pourtant ça avance pas si mal, même dans le libre. Kdenlive fait des efforts. Blender aussi progresse de plus en plus et pour avoir moi-même fait des tests de comparaison sur le même rendu (de projet réel par un truc de test) avec et sans accélération matérielle, je peux dire que c'est le jour et la nuit. GIMP aussi a maintenant des filtres accélérés en OpenCL.
Ensuite cela reste normal de toujours implémenter d'abord un algorithme pour le processeur. Déjà pas tout le monde n'a de super carte 3D ou autre matériel dédié. En plus on s'expose à tout plein de nouvelles catégories de problèmes, notamment les problèmes de pilotes. Déjà on a déjà vu des pilotes buggués qui plantent (les cartes 3D ont en général une prise en charge OpenCL de nos jours dans les pilotes officiels, mais ce n'est pas forcément ce qu'ils ont peaufiné le plus, notamment quand le constructeur propose une solution concurrente; et y a le cas des pilotes libres parfois particulier). Ensuite dans certains pilotes, la prise en charge OpenCL est aussi parfois peu convaincante, au point d'avoir des calculs moins performants. Enfin même sans cela, le calcul GPU n'est pas forcément plus rapide, par design. Il y a beaucoup de littérature sur le sujet qui explique que dans certaines conditions, le calcul CPU peut être plus rapide (en plus d'être plus précis, c'est à dire avec moins d'erreurs de calcul). Sans compter que développer pour le GPU est différent voire plus complexe, donc il peut y avoir plus facilement des bugs, et de manière générale ce n'est pas ce qu'on voudra faire en première version.
Pour info, sur GIMP, on n'active pas le calcul OpenCL de base, et on déconseille parfois de l'utiliser. Dans certains cas, les filtres en version OpenCL prennent même plus de temps que la version standard CPU.
Enfin voilà, je sais qu'on aime bien se dire que c'était mieux avant et que ça va de mal en pis. Perso, je pense que Kdenlive est 100 fois mieux maintenant d'après mes critères. Je l'avais testé y a des années, et j'avais pas du tout été persuadé. Notamment il avait énormément de problèmes de stabilité (bien plus important pour moi que des problèmes de vitesse, même si ça compte aussi bien sûr). Depuis quelques années, ils ont vraiment donné un coup de boost et c'est l'un des projets d'éditeur vidéo libre parmi les plus actifs, et clairement le plus en vue maintenant.
Et il ne faut pas comparer les logiciels multimédia maintenant et y a 10 ans. Ce que fait (ou doit faire) un logiciel qui travaille sur de l'image de nos jours (pour être dans les critères qui le feront être considéré professionnellement) n'a plus rien à voir. On ne peut pas d'un côté demander à ces logiciels de travailler avec plus de précision (donc 16/32-bit par canal), sur de bien plus grosses images, tout en faisant du traitement colorimétrique (c'est aussi du calcul), tout ça en passant à travers des filtres super complexes (voire un graphe de plusieurs filtres), tout en demandant à ce que ça aille plus vite que quand on n'avait pas tout ça.
Je sais que sur GIMP aussi, certains se plaignent de choses qui vont moins vite dans certains cas, et notamment même de la peinture sur canevas. Le fait est que GIMP 2.10.x fait juste 100 fois plus de trucs sous le capot maintenant et est bien plus juste mathématiquement ou colorimétriquement qu'il ne l'étaient en 2.8 par exemple. Cela ne se voit même pas tant que cela en plus, car énormément de choses ont été super-optimisées. Y a eu un énorme travail sous le capot. En fait c'est donc l'inverse, le simple fait qu'on arrive à sembler aussi rapide qu'avant est parfois un exploit. :-)
Ensuite bien sûr qu'y a encore du travail. Y a toujours du travail! 😩
Mais les choses avancent vraiment dans le bon sens, d'après moi, pour beaucoup de logiciels libres multimédia.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ah !
Posté par AlexTérieur . Évalué à -10.
Trop long, désolé, je n'ai pas lu…
Mon post était là pour faire un constat, pas pour me moquer de qui que ce soit, surtout pas des développeurs. Juste que nous avons tous aujourd'hui une carte graphique qui est un véritable processeur qui se tourne les pouces pour des tâches qui s'avèrent définitivement établies dans le quotidien de la plupart.
Ce n'est pas évident certes… j'en suis le premier incapable ! Et j'aimerai bien pourtant y contribuer… Mes talents ont des limites.
Je répète bien : ceci est un constat. Pas de dire qu'un tel ou un tel est nul !!! J'ai même écris (relis-moi bien) que dans le monde Windows on ne savait pas faire… C'est qu'il y a un véritable problème. On préfère passer du temps à s'offusquer de la qualité d'un antialiasing en 3D (qui se valent tous plus ou moins aujourd'hui) que des trucs plus grands publics que les montages vidéos… Désolé, on ne m'enlèvera pas de la tête qu'un GPU n'est pas capable simplement d'appliquer des filtres à la volée.
[^] # Re: Ah !
Posté par barmic 🦦 . Évalué à 2.
Autant dans le cas général, je comprends autant dans le cas de l'édition vidéo, j'ai du mal à voir les cas. Là où un CPU est meilleur que le GPU c'est quand on a un traitement très "aléatoire" où la prédiction de branchement est très mauvaise ou quand le temps de calcul sera moins impactant que les temps de transfert sur le bus PCIe. Certains filtres demandant de l'aléatoire et tuant fortement le parallélisme pourraient donner ce genre de résultat, mais j'imagine que ça reste rare, non ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Ah !
Posté par groumly . Évalué à 1.
ya 10 ans, non, mais ça fait 5 ans qu’on fait du montage 4K sur des téléphones.
Alors, ok, ya du hardware dédié, mais ya du hardware dédié au décodage sur les cartes graphiques aussi. Et ya que 2Gb de ram.
Non pas que je tienne à dire que c’est facile à faire, mais clairement, c’est possible.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Ah !
Posté par barmic 🦦 . Évalué à 5. Dernière modification le 25 décembre 2019 à 16:53.
Il y a des dalles de téléphones 4k ? Si non ils font probablement du downsize au moins pour l'édition.
Que ça soit possible et qu'il faut entre autre repenser les algos (réévaluer le coût de chaque opération lorsque les images sont plus grosses), je n'en doute pas et c'est un avantage d'un nouveau logiciel que les plus anciens, mais de là à travailler entièrement en 4k sur téléphone ça m'étonnerait (rien que pour économiser la batterie).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Problème
Posté par arnauld . Évalué à 1.
Merci pour ces infos. J'essaye d'accéder à la page des outils de montage vidéo et celle du tuto avec Kdenlive mais impossible. Je retombe sans cesse sur https://www.funix.org/fr/linux/index.php
C'est normal ou c'est moi ? J'ai essayé avec Firefox et Chromium…
arnauld
[^] # Re: Problème
Posté par Funix (site web personnel, Mastodon) . Évalué à 2.
Ah!? Curieux, d'autres ont le même soucis, je constate pas cela.
https://www.funix.org mettez un manchot dans votre PC
# Précisions
Posté par vpinon . Évalué à 10.
Bonjour,
D'abord merci de faire passer des nouvelles sur Kdenlive…
Et j'ai quelques réactions :)
Tout d'abord, je trouve injuste de dire que ça s'est empiré depuis 2013, que ce soit en stabilité ou en performances.
Nous avons basculé sur l'affichage OpenGL dès la branche Qt4, quand est apparue l'intégration de Movit (effets calculés sur le GPU) qui était très prometteuse et requérait ce changement. Malheureusement l'intégration GPU / Multithreading est compliquée (pour MLT, mais pas que), toujours instable depuis 5 ans, et nous avons donc dû désactiver cette option car trop d'utilisateurs se cassaient les dents là dessus. Nous cherchons toujours des contributeurs maîtrisant ces domaines : ce n'est pas vraiment à la portée du premier bricoleur venu (comme moi :-P)
Hormis les effets, l'affichage via OpenGL a visiblement causé des ralentissements chez certains utilisateurs, minoritaires et malheureusement sans qu'on trouve jamais l'explication. En tout cas chez les développeurs, les testeurs réguliers et d'après le bug tracker, rien n'a justifié un retour en arrière, qui serait compliqué maintenant. Moi-même j'ai un vieux i5 (3ème génération ?) avec 4Go de RAM, GPU Intel intégré : ça roule toujours !
Le passage à Qt5 en 2015 (indispensable car Qt4 en fin de vie) a engendré des régressions et instabilités, gommées au bout d'environ un an alors que le distributions opéraient la transition.
Un autre facteur qui a engendré des ralentissements est l'activation de la transparence sur les pistes par défaut (une requête d'un célèbre graphiste sur ce site je crois !). Dans certains cas (tailles de clips), la moteur s'est mis à appliquer des compositions continuellement. Ca a été corrigé progressivement… Par dessus le marché, nous sommes passés à des compositions plus fines (RGB vs YUV), ce qui implique des conversions qui ont un coût (surtout qu'on ne le fait toujours pas sur le GPU :-( )
De 2016 à 2019, presque tous les efforts étaient sur la réécriture sortie cette année (19.04) : depuis le début, la gestion du montage avait grossi dans quelques énormes classes, avec des imbrications indémêlables, au point que le debug et les évolutions étaient un affreux casse-tête. En repartant sur des modèles (avec tests) + vues (en qml), JB a reconstruit des bases propres, qui font que depuis on ne reçoit presque plus de rapport de crash sur cette partie, les petits bugs sont vite repérés et corrigé, et plein de nouvelles fonctions sont ajoutées pour permettre aux monteurs réguliers d'être plus rapides.
Il y avait encore quelques surcharges mémoires (avec les miniatures audio & vidéo), corrigées dans la 19.12, qui de l'avis de nombreux testeurs est plus réactive que jamais (Qt4 compris).
Concernant les effets disparus : comme MLT propose tous les plugins qu'il trouve, on se retrouvait avec une liste d'effets effrayante pour beaucoup, et la plupart mal gérés. Nous avons délégué la tâche de trier ces effets à nos utilisateurs (lors de plusieurs "cafés", nos discussions mensuelles sur IRC). Ils les ont testés un par un, et éliminé tous ceux qui étaient redondants ou qu'ils n'arrivaient pas à faire marcher. Ils ont aussi proposé une présélection des effets les plus attendus ; on affiche ceux-ci par défaut tout en laissant les liste plus étoffées dans les différentes catégories. Ce point est toujours en discussion !
Retour sur le point GPU : l'intégration de Movit (traitement d'image) est toujours aussi bugguée donc désactivée (l'option est même cachée), je crois que jouer ce jeu risque pour l'instant de vous exposer à quelques frustrations. Mais l'auteur de MLT l'a annoncé comme son chantier de 2020, espérons que ça change bientôt ! Après, certains ont suggéré que la technologie employée (GLSL) n'était peut-être pas très pertinente aujourd'hui, d'autres pistes pourraient être explorées.
Par contre, on constate souvent en profilant ce qui se passe pendant l'export que l'encodage (H264/5, VP8/9) reste la plupart du temps un contributeur majeur.
MLT peut tout à fait utiliser le GPU pour ça, rien à voir avec le traitement (c'est FFmpeg/libavcodec qui fait tout).
Des profils d'export via VAAPI (Intel, AMD) ou NVENC (Nvidia) sont disponibles à télécharger dans le magasin KDE ou même directement depuis le dialogue de rendu. Il faudrait les tester un peu mieux et les intégrer dans les releases…
Pour cela il faut que FFmpeg soit compilé avec les bonnes options, la plupart des distributions récentes proposent au moins VAAPI ; pour NVidia il faut voir, là peut-être qu'il faut chercher dans des dépôts tiers ou recompiler.
Ouf, ça en fait des choses à raconter !
Et dire que des nouveautés se préparent encore pour 2020…
Bon montage à tous !
[^] # Re: Précisions
Posté par vpinon . Évalué à 9.
Aussi :
[^] # Re: Précisions
Posté par ʭ ☯ . Évalué à 3.
Ah, merci pour ces précisions, notamment les profils d'export VAAPI à télécharger depuis Kdenlive, je les avais pas trouvés!
Pour ma part, je félicite ce projet qui ne fait que s'améliorer. Dire qu'il m'a permis de réaliser en 2010 un court-métrage d'animation en 2K sur un portable de 2005 ( Pentium-M 740 avec 512Mo de RAM ). C'était à l'époque en faisant le montage avec un dossier contenant les images réduites au quart, puis en renommant ce dossier pour qu'il pointe vers la haute résolution. Environ 12 heures de rendu pour un film de 10 minutes, avec une mémoire virtuelle de 2Go…
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Précisions
Posté par Funix (site web personnel, Mastodon) . Évalué à 4.
Super, merci Vincent pour ce point très éclairant et bon courage à tous les développeurs.
https://www.funix.org mettez un manchot dans votre PC
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.