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:
J'aimerai faire du montage 4K
[...]
c'est 10 ans de retour en arrière...
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é):
FullHD: 2048×ばつかける1080 =わ 2 211 840 pixels
4K: 4096×ばつかける2160 =わ 8 847 360 pixels
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).
Il faut passer par des dégradations de la vidéo initiale... C'est juste fou.
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.
Je trouve totalement aberrant d'avoir des cartes graphiques ultra-puissantes mais exploités que pour des trucs de type "jeux"...
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 Jehan (site web personnel, Mastodon) . En réponse au journal kdenlive 19.12.0 et accélération matérielle. É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 ]