"On" explique des tas de choses
"Comme pour" la consommation responsable d'après les "khmers-verts" (manger local, préférer le vélo au SUV…)
"Comme pour" défendre la liberté d'entreprendre et relancer la croissance d'après d'autres
"Comme pour" protéger l'identité nationale selon encore d'autres
J'ai une préférence dans le lot, mais je respecte que d'autres aient des convictions différentes, et qu'on évite de les considérer comme des idiots
Heureusement que les communautés nextcloud, cozycloud & cie n'ont pas lâché !
La domination du monde, non bien sûr, mais dans des cercles réceptifs (ma famille, mes assos, mon boulot), tout le monde est content !
Quant à la notion de bullshits job (qui est ici utilisé sans en comprendre le sens), il faut vraiment faire attention parce qu'il y en a qui disent la même chose de nous.
On a tous raison de se sentir concerné par la remise en question générale !
J'ai lu différents trucs sur les bullshit job, pour moi ce n'est pas une simple perception de l'employé (problème de motivation ? ;P ), c'est un questionnement sur l'utilité pour la société /l'humanité/la vie.
En dehors de produire de la nourriture (durablement), des habitats (bien isolés), et des soins (pour les malades, les petits, les anciens), et tous les outils de support de ces fonctions (c'est là que ça devient large), qu'est ce qui est utile à la bonne marche du monde ?
Moi aussi je suis spécialisé dans les hautes technologies, je m'y amuse bien, mais quand je prends du recul j'ai des dilemmes…
Je ne crois pas, pour des satellites basse orbite au moins nous avons envoyé du 28nm (en SOI, vendu pour son épaisseur de silicium active bien inférieure aux longueurs d'ondes des rayonnements présents à des puissances non négligeables)
Qu'un tel lien (HS ? cf le journal-qui-dénonce) n'atteigne pas une note très positive OK, mais qu'il se fasse descendre en note et en commentaire me fait douter si je suis toujours en phase avec la communauté linuxfr ?!
Je n'étais pas retourné voir les commentaires, ton journal renvoyant à celui-ci m'y a ramené :)
Kdenlive a vraiment pour objectif de répondre aux attentes des pros, dont certains dévoués guident le développement.
Donc : la gestion de toutes les pistes son est en cours, déjà fonctionnelle cette semaine (mais reste des soucis quand on veut faire des remapping complexes).
Juste après on compte intégrer les cross-fades sur une seule piste, et dans la foulée étoffer les outils de trimming (roll, ripple etc).
Et enfin (fin d'année ?) s'attaquer au multi-timeline.
Pour l'instant, pour tourner autour du pot, ce que je fais c'est plein d'essais à la queue-leu-leu sur la même timeline (à coup de copier-coller), avec des repères pour les reconnaître vite.
Enfin, pour les effets audio, il y en a des tas via les plugins LADSPA : compresseurs, limiteurs, equalizers ! Sous Debian/Ubuntu, il faut installer ladspa-swh, ladspa-cmt par exemple (je n'ai pas essayé d'autres, ces 2 là me suffisent). Ah, par contre sous Windows, je n'ai pas encore réussi à faire comprendre à Jack que je voulais le compiler avec MinGW (waf s'obstine à chercher MSVC, et je m'obstine à ne pas vouloir de ça), donc pas encore de LADSPA…
Bref, j'espère que pour Noël toute ta liste de souhaits sera exaucée ?!
Flowblade étant basé sur MLT comme Kdenlive et Shotcut, tout ce que tu dis peut être fait dans les deux autres (titres SVG, synchro audio, filtres identiques, FFmpeg), hormis le "roll/slide" = changer la position d'un cut dans le clip source sans le bouger dans la timeline : ce bête petit bout d'UI n'est pas réintégré dans Kdenlive 19.x, il devrait venir vite (on peut juste éditer les propriétés du clip et changer le timecode à la main, mais pas top intuitif).
Ahhh, la doc, là où ça pêche pour tant de projets :(
Shotcut se positionne comme OpenShot, plus sur le créneau amateurs que pros.
Il commence à être bien rôdé mais son ergonomie m'a aussi un peu surpris (ça fait un moment que je n'ai pas ré-essayé, et j'ai des habitudes ancrées).
Son titreur, étant basé sur HTML+JavaScript, offre des possibilités infinies (bien que l'interface ne le laisse pas deviner : il faut copier du code externe)…
Et c'est dommage, notre sprint annuel (couplé au Libre Graphics Meeting dans quelques semaines) devait rassembler plusieurs monteurs dans le but de produire cette documentation et plein de petits tutos/démos à jour… Annulé vu les circonstances (désolé d'en reparler !), peut-être un télé-sprint ?
Tu as reporté un problème de performances sur ce site comme sur le forum, mais je tiens à rappeler que ce n'est pas une généralité : chez la grande majorité des gens (et les queques développeurs) le logiciel est resté tout à fait fluide (j'ai un i5 de 8 ans et 6Go de RAM, je fais de la HD).
La version 20.04 apporte le "monitor scaling" qui doit gagner fortement en performance même avec de lourds effets, sans plus nécessiter d'intermédiaires basse résolution.
Concernant l'évolution de l'ergonomie, un débutant peut toujours faire les montages de base exactement de la même façon simple que depuis 10 ans. Il y a un gros travail depuis 2 ans piloté par plusieurs monteurs pro pour leur permettre de travailler très efficacement (tout au clavier, inspiré de Avid, Première, FinalCut…), mais tout cela n'est que des fonctions ajoutées, rien de retiré : KDE c'est "simple par défaut, puissant si besoin". On aurait peut-être juste dû cacher par défaut le nouveau mixeur son…
Sur ces aspects, la doc reste en retard, ça c'est dommage pour ceux qui veulent bénéficier de ces dernières optimisations, mais pour l'amateur occasionnel, les tutos historiques restent valables et c'est l'approche recommandée.
restaurer (recompiler) une version de l'archive (par exemple Debian, je ne connais pas assez Arch ou autres) telle qu'elle était exactement disons le 14 juillet 2017.
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…
Je vois l'intérêt d'en débattre : c'est à dire discuter de manière ouverte, en étant à l'écoute des besoins de l'autre, en exprimant clairement ses propres besoins, sans se poser en victime ni se moquer de l'autre.
Je les soutiens.
Elles écrivent des bios sur des inconnues… qui justement resteront inconnues tant qu'on ne les fera pas connaître, ça me semble logique.
Elles n'effacent pas l'encyclopédie, elles la complètent sur des sujets où elles pensent pouvoir apporter, c'est tout à fait le but de Wikipedia.
Tracim progresse vraiment à une vitesse impressionnante.
Le partage public est bien pratique, et l'édition collaborative (CODE) va vraiment débloquer les choses pour que je puisse le proposer dans les cercles où j'évolue… Par contre niveau auto-hébergement ça doit commencer à devenir compliqué ?!
Je ne manquerais pas de suggérer l'option payante pour vous soutenir :)
Les fondeurs font des efforts depuis longtemps pour se rendre plus indépendants des éditeurs de CAO, en se basant sur des PDK a décliner automatiquement vers divers outils. Même l'industrie CAO essaye de mettre en place des formats "standards" je crois (genre UPF).
Par ailleurs, Tim Edwards travaille pour efabless (pendant des décennies il faisait ça sur son boulot de prof+consultant je crois), c'est son job de fournir cet environnement fonctionnel. La c'est la démo que tout est prêt.
efabless semble dépendre de Xfab comme unique fonderie, ils ont probablement des accords pour avoir accès aux DK et autres corelibs (a moins qu'il n'utilise des DK & corelibs "génériques", non optimisées, comme ils le proposent dans les bouquins)…
C'est gagnant-gagnant ? La CAO devient accessible, et Xfab enrichit son catalogue d'IPs compatibles…
mais cette libéra(lisa)tion ne va-t-elle pas aussi vers une "uberisation" de la conception ?
quelques "artisans" utilisant Kdenlive :
- Purism : avec toutes les explications sur la démarche et les outils !
- Gunga (Brésil)
- ma chérie
- et plein de contributions dans la rubrique "vitrine" du site Kdenlive
Depuis 2012, plusieurs monteurs indépendants ont choisi Kdenlive comme outil de montage principal, et ont sorti des longs métrages : un en salles je crois, sur la POC21, mais assez confidentiel, et de nombreux en DVD/BlueRay (documentaires, captations de spectacles commercialisées).
Mais aussi de nombreux formats courts, diffusés sur des TV locales, en France (Rhône-Alpes, Bretagne) mais aussi au Brésil, en Estonie ; des lives sur des gros festivals…
En Inde et au Pakistan, 2 chaînes TV font (pré?-)monter leurs journalistes sous Kdenlive, mais ce ne sont pas vraiment des pros de la discipline et c'est probablement retravaillé derrière.
En 2015, Kdenlive a travaillé comme d'autres projets KDE à clarifier sa vision et ses missions (article sur l'ancien site… aux oubliettes :( ) ; résultat, il vise une utilisation pro (pour les petites structures c'est sûr, pas les gros studios).
Cette clarification a amené d'autres professionnels à s'investir dans le projet, justement pour informer les développeurs sur ce qu'il leur manque en priorité, ce qui les aiderait à améliorer l'efficacité du logiciel…
Ça commence juste à porter ses fruits, et les derniers retours sont très positifs !
Concernant MLT, c'est sûr que l'architecture est vieillotte et comporte de graves goulots d'étranglement concernant la performance (rendu multi-coeurs et sur puce graphique), des discussions sont en cours pour lui donner un bon coup de jeune, quitte à en faire un nouveau projet ?
Mais c'est aussi à la base un outil professionnel, qui a rapporté de l'argent à son auteur en prestation chez des diffuseurs.
Et un ASIC permet aussi de d'intégrer des fonctions analogiques, des périphériques et interfaces spécifiques (USB, lien RF ou NFC, contrôle de moteur…)
Un jour en marge de mon boulot j'ai cherché à faire l'inverse de websockify (bridge TCP vers WebSocket), cet outil étant en python je suis d'abord parti de ce code… et je ne m'en suis pas sorti, car pour éviter les dépendances il recode le protocole, mais juste ce qu'il lui faut.
Alors j'ai cherché dans d'autres implémentations, j'ai même essayé du perl !
Et puis j'ai dégaîné Qt, auquel je suis un peu plus habitué, et en 15 lignes j'avais mon outil qui marche, et il tourne depuis plusieurs années maintenant.
Issu de la communauté KDE, si je cherche quelque chose qui n'est pas encore dans Qt & KF5, je fais un tour sur inqlude et normalement ça s'intègre bien.
Et comme gestionnaire de paquet, "fatalement" je suis passé à Craft, et même si j'ai dû participer à pas mal d'empaquetage je suis bien content !
Pas mal de membres de la communauté KDE ont opté pour les Slimbooks, car la boîte avait demandé les specs voulues avant de sortir un modèle avec le logo KDE sérigraphié ; elle est sponsors de divers événements, offre du matos en cadeau (exemple : concours de fond d'écran en cours)…
[^] # Re: pourquoi sans gui ?
Posté par vpinon . En réponse au message virtualiser sans GUI une Ubuntu sur une debian buster. Évalué à 1.
Pour compiler moi j'utilise schroot
LXC aussi c'est simple pour jongler entre distributions
[^] # Re: Il faut écouter les scientifiques, pas les politiques ou les animateurs TV
Posté par vpinon . En réponse au journal Masques pour lutter contre le Covid : les journalistes disent stop !. Évalué à 0.
"On" explique des tas de choses
"Comme pour" la consommation responsable d'après les "khmers-verts" (manger local, préférer le vélo au SUV…)
"Comme pour" défendre la liberté d'entreprendre et relancer la croissance d'après d'autres
"Comme pour" protéger l'identité nationale selon encore d'autres
J'ai une préférence dans le lot, mais je respecte que d'autres aient des convictions différentes, et qu'on évite de les considérer comme des idiots
[^] # Re: Abandonne tout espoir
Posté par vpinon . En réponse au journal Besoin d'aide pour finir la dépêche sur les alternatives pour un réseau social familial. Évalué à 1.
Heureusement que les communautés nextcloud, cozycloud & cie n'ont pas lâché !
La domination du monde, non bien sûr, mais dans des cercles réceptifs (ma famille, mes assos, mon boulot), tout le monde est content !
[^] # Re: N'importe quoi…
Posté par vpinon . En réponse au lien Électricité bas carbone et vision politique en cette période de canicule. Évalué à 3. Dernière modification le 11 août 2020 à 10:59.
On a tous raison de se sentir concerné par la remise en question générale !
J'ai lu différents trucs sur les bullshit job, pour moi ce n'est pas une simple perception de l'employé (problème de motivation ? ;P ), c'est un questionnement sur l'utilité pour la société /l'humanité/la vie.
En dehors de produire de la nourriture (durablement), des habitats (bien isolés), et des soins (pour les malades, les petits, les anciens), et tous les outils de support de ces fonctions (c'est là que ça devient large), qu'est ce qui est utile à la bonne marche du monde ?
Moi aussi je suis spécialisé dans les hautes technologies, je m'y amuse bien, mais quand je prends du recul j'ai des dilemmes…
[^] # Re: La taille ça compte (ou pas)
Posté par vpinon . En réponse à la dépêche Google libère les ASIC avec un PDK open source en 130 nm. Évalué à 7.
Je ne crois pas, pour des satellites basse orbite au moins nous avons envoyé du 28nm (en SOI, vendu pour son épaisseur de silicium active bien inférieure aux longueurs d'ondes des rayonnements présents à des puissances non négligeables)
# Moi j'aime bien les liens d'actu d'antistress!
Posté par vpinon . En réponse au lien Floyd/Traore : l'expression d'une génération déjà mobilisée pour le climat et l’égalité des genres. Évalué à 0.
Qu'un tel lien (HS ? cf le journal-qui-dénonce) n'atteigne pas une note très positive OK, mais qu'il se fasse descendre en note et en commentaire me fait douter si je suis toujours en phase avec la communauté linuxfr ?!
[^] # Re: Les fonctions qui me manquent le plus
Posté par vpinon . En réponse au journal Comparatif des logiciels de montage vidéo libres, le retour !. Évalué à 4.
Hello,
Je n'étais pas retourné voir les commentaires, ton journal renvoyant à celui-ci m'y a ramené :)
Kdenlive a vraiment pour objectif de répondre aux attentes des pros, dont certains dévoués guident le développement.
Donc : la gestion de toutes les pistes son est en cours, déjà fonctionnelle cette semaine (mais reste des soucis quand on veut faire des remapping complexes).
Juste après on compte intégrer les cross-fades sur une seule piste, et dans la foulée étoffer les outils de trimming (roll, ripple etc).
Et enfin (fin d'année ?) s'attaquer au multi-timeline.
Pour l'instant, pour tourner autour du pot, ce que je fais c'est plein d'essais à la queue-leu-leu sur la même timeline (à coup de copier-coller), avec des repères pour les reconnaître vite.
Enfin, pour les effets audio, il y en a des tas via les plugins LADSPA : compresseurs, limiteurs, equalizers ! Sous Debian/Ubuntu, il faut installer ladspa-swh, ladspa-cmt par exemple (je n'ai pas essayé d'autres, ces 2 là me suffisent). Ah, par contre sous Windows, je n'ai pas encore réussi à faire comprendre à Jack que je voulais le compiler avec MinGW (waf s'obstine à chercher MSVC, et je m'obstine à ne pas vouloir de ça), donc pas encore de LADSPA…
Bref, j'espère que pour Noël toute ta liste de souhaits sera exaucée ?!
[^] # Re: Un autre : NATRON
Posté par vpinon . En réponse au journal Comparaison des logiciels de montage vidéo. Évalué à 1.
Natron n'est pas vraiment un logiciel de montage mais de composition / effets… et il n'est malheureusement plus maintenu (pour l'instant)
[^] # Re: Flowblade
Posté par vpinon . En réponse au journal OpenShot Video Editor vs Kdenlive. Évalué à 4.
Flowblade étant basé sur MLT comme Kdenlive et Shotcut, tout ce que tu dis peut être fait dans les deux autres (titres SVG, synchro audio, filtres identiques, FFmpeg), hormis le "roll/slide" = changer la position d'un cut dans le clip source sans le bouger dans la timeline : ce bête petit bout d'UI n'est pas réintégré dans Kdenlive 19.x, il devrait venir vite (on peut juste éditer les propriétés du clip et changer le timecode à la main, mais pas top intuitif).
Ahhh, la doc, là où ça pêche pour tant de projets :(
[^] # Re: Édition 4K
Posté par vpinon . En réponse au journal OpenShot Video Editor vs Kdenlive. Évalué à 2.
Hors Qt, on peut parler de PiTiVi (GTK+Python), ou Cinelerra…
[^] # Re: Shotcut
Posté par vpinon . En réponse au journal OpenShot Video Editor vs Kdenlive. Évalué à 6.
Shotcut se positionne comme OpenShot, plus sur le créneau amateurs que pros.
Il commence à être bien rôdé mais son ergonomie m'a aussi un peu surpris (ça fait un moment que je n'ai pas ré-essayé, et j'ai des habitudes ancrées).
Son titreur, étant basé sur HTML+JavaScript, offre des possibilités infinies (bien que l'interface ne le laisse pas deviner : il faut copier du code externe)…
[^] # Re: Non, Kdenlive n'est pas un monstre
Posté par vpinon . En réponse au journal OpenShot Video Editor vs Kdenlive. Évalué à 6.
(peux plus modifier, je me réponds)
Et c'est dommage, notre sprint annuel (couplé au Libre Graphics Meeting dans quelques semaines) devait rassembler plusieurs monteurs dans le but de produire cette documentation et plein de petits tutos/démos à jour… Annulé vu les circonstances (désolé d'en reparler !), peut-être un télé-sprint ?
# Non, Kdenlive n'est pas un monstre
Posté par vpinon . En réponse au journal OpenShot Video Editor vs Kdenlive. Évalué à 9.
Salut Funix, salut tout le monde,
Tu as reporté un problème de performances sur ce site comme sur le forum, mais je tiens à rappeler que ce n'est pas une généralité : chez la grande majorité des gens (et les queques développeurs) le logiciel est resté tout à fait fluide (j'ai un i5 de 8 ans et 6Go de RAM, je fais de la HD).
La version 20.04 apporte le "monitor scaling" qui doit gagner fortement en performance même avec de lourds effets, sans plus nécessiter d'intermédiaires basse résolution.
Concernant l'évolution de l'ergonomie, un débutant peut toujours faire les montages de base exactement de la même façon simple que depuis 10 ans. Il y a un gros travail depuis 2 ans piloté par plusieurs monteurs pro pour leur permettre de travailler très efficacement (tout au clavier, inspiré de Avid, Première, FinalCut…), mais tout cela n'est que des fonctions ajoutées, rien de retiré : KDE c'est "simple par défaut, puissant si besoin". On aurait peut-être juste dû cacher par défaut le nouveau mixeur son…
Sur ces aspects, la doc reste en retard, ça c'est dommage pour ceux qui veulent bénéficier de ces dernières optimisations, mais pour l'amateur occasionnel, les tutos historiques restent valables et c'est l'approche recommandée.
[^] # Re: Quelques "killer features"
Posté par vpinon . En réponse à la dépêche Guix : un outil pour les remplacer tous. Évalué à 3.
http://snapshot.debian.org/
[^] # Re: Précisions
Posté par vpinon . En réponse au journal kdenlive 19.12.0 et accélération matérielle. Évalué à 9.
Aussi :
# Précisions
Posté par vpinon . En réponse au journal kdenlive 19.12.0 et accélération matérielle. É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: Réponse éclairée faite à 2h du mat
Posté par vpinon . En réponse au journal Écriture inclusive, féministes et Wikipédia. Évalué à 0.
Je vois l'intérêt d'en débattre : c'est à dire discuter de manière ouverte, en étant à l'écoute des besoins de l'autre, en exprimant clairement ses propres besoins, sans se poser en victime ni se moquer de l'autre.
Je les soutiens.
Elles écrivent des bios sur des inconnues… qui justement resteront inconnues tant qu'on ne les fera pas connaître, ça me semble logique.
Elles n'effacent pas l'encyclopédie, elles la complètent sur des sujets où elles pensent pouvoir apporter, c'est tout à fait le but de Wikipedia.
# Bravo !
Posté par vpinon . En réponse à la dépêche Plus d’excuse pour ne plus collaborer (avec Tracim 2.5) !. Évalué à 4.
Tracim progresse vraiment à une vitesse impressionnante.
Le partage public est bien pratique, et l'édition collaborative (CODE) va vraiment débloquer les choses pour que je puisse le proposer dans les cercles où j'évolue… Par contre niveau auto-hébergement ça doit commencer à devenir compliqué ?!
Je ne manquerais pas de suggérer l'option payante pour vous soutenir :)
Courage et à bientôt !
[^] # Re: Blagues du vendredi
Posté par vpinon . En réponse au journal Blagues Friday. Évalué à 10.
Pour les geeks (vu il y a peu au tableau d'une salle de réunion) :
« Un homme azerty en vaut é »
[^] # Re: cout logiciel
Posté par vpinon . En réponse à la dépêche Un ASIC conçu intégralement avec des logiciels libres. Évalué à 4.
Les fondeurs font des efforts depuis longtemps pour se rendre plus indépendants des éditeurs de CAO, en se basant sur des PDK a décliner automatiquement vers divers outils. Même l'industrie CAO essaye de mettre en place des formats "standards" je crois (genre UPF).
Par ailleurs, Tim Edwards travaille pour efabless (pendant des décennies il faisait ça sur son boulot de prof+consultant je crois), c'est son job de fournir cet environnement fonctionnel. La c'est la démo que tout est prêt.
efabless semble dépendre de Xfab comme unique fonderie, ils ont probablement des accords pour avoir accès aux DK et autres corelibs (a moins qu'il n'utilise des DK & corelibs "génériques", non optimisées, comme ils le proposent dans les bouquins)…
C'est gagnant-gagnant ? La CAO devient accessible, et Xfab enrichit son catalogue d'IPs compatibles…
mais cette libéra(lisa)tion ne va-t-elle pas aussi vers une "uberisation" de la conception ?
[^] # Re: Kdenlive?
Posté par vpinon . En réponse à la dépêche Cinéma, logiciels libres ou non : état des lieux. Évalué à 6. Dernière modification le 05 juillet 2019 à 12:28.
quelques "artisans" utilisant Kdenlive :
- Purism : avec toutes les explications sur la démarche et les outils !
- Gunga (Brésil)
- ma chérie
- et plein de contributions dans la rubrique "vitrine" du site Kdenlive
[^] # Re: Kdenlive?
Posté par vpinon . En réponse à la dépêche Cinéma, logiciels libres ou non : état des lieux. Évalué à 10.
Pas d'accord :)
Depuis 2012, plusieurs monteurs indépendants ont choisi Kdenlive comme outil de montage principal, et ont sorti des longs métrages : un en salles je crois, sur la POC21, mais assez confidentiel, et de nombreux en DVD/BlueRay (documentaires, captations de spectacles commercialisées).
Mais aussi de nombreux formats courts, diffusés sur des TV locales, en France (Rhône-Alpes, Bretagne) mais aussi au Brésil, en Estonie ; des lives sur des gros festivals…
En Inde et au Pakistan, 2 chaînes TV font (pré?-)monter leurs journalistes sous Kdenlive, mais ce ne sont pas vraiment des pros de la discipline et c'est probablement retravaillé derrière.
En 2015, Kdenlive a travaillé comme d'autres projets KDE à clarifier sa vision et ses missions (article sur l'ancien site… aux oubliettes :( ) ; résultat, il vise une utilisation pro (pour les petites structures c'est sûr, pas les gros studios).
Cette clarification a amené d'autres professionnels à s'investir dans le projet, justement pour informer les développeurs sur ce qu'il leur manque en priorité, ce qui les aiderait à améliorer l'efficacité du logiciel…
Ça commence juste à porter ses fruits, et les derniers retours sont très positifs !
Concernant MLT, c'est sûr que l'architecture est vieillotte et comporte de graves goulots d'étranglement concernant la performance (rendu multi-coeurs et sur puce graphique), des discussions sont en cours pour lui donner un bon coup de jeune, quitte à en faire un nouveau projet ?
Mais c'est aussi à la base un outil professionnel, qui a rapporté de l'argent à son auteur en prestation chez des diffuseurs.
[^] # Re: Avantages de l'ASIC
Posté par vpinon . En réponse à la dépêche Un ASIC conçu intégralement avec des logiciels libres. Évalué à 8.
Et un ASIC permet aussi de d'intégrer des fonctions analogiques, des périphériques et interfaces spécifiques (USB, lien RF ou NFC, contrôle de moteur…)
# Qt ça aide bien
Posté par vpinon . En réponse à la dépêche Moi, expert C++, j’abandonne le C++. Évalué à 7.
Un jour en marge de mon boulot j'ai cherché à faire l'inverse de websockify (bridge TCP vers WebSocket), cet outil étant en python je suis d'abord parti de ce code… et je ne m'en suis pas sorti, car pour éviter les dépendances il recode le protocole, mais juste ce qu'il lui faut.
Alors j'ai cherché dans d'autres implémentations, j'ai même essayé du perl !
Et puis j'ai dégaîné Qt, auquel je suis un peu plus habitué, et en 15 lignes j'avais mon outil qui marche, et il tourne depuis plusieurs années maintenant.
Issu de la communauté KDE, si je cherche quelque chose qui n'est pas encore dans Qt & KF5, je fais un tour sur inqlude et normalement ça s'intègre bien.
Et comme gestionnaire de paquet, "fatalement" je suis passé à Craft, et même si j'ai dû participer à pas mal d'empaquetage je suis bien content !
[^] # Re: Slimbook
Posté par vpinon . En réponse au journal Sélection d'un PC libre. Évalué à 2.
Pas mal de membres de la communauté KDE ont opté pour les Slimbooks, car la boîte avait demandé les specs voulues avant de sortir un modèle avec le logo KDE sérigraphié ; elle est sponsors de divers événements, offre du matos en cadeau (exemple : concours de fond d'écran en cours)…