vpinon a écrit 172 commentaires

On peut paramétrer kdenlive pour qu'à l'inclusion d'une vidéo dépassant certaines dimensions il génère un média de travail en basse résolution.

Ça se passe dans Projet > Configuration et Configuration > Configurer Kdenlive > Réglages par défaut, cocher Clips intermédiaires et éventuellement éditer le profil : par défaut il c'est un fichier MPEG2 TS en 480x270 400kb/s, très léger mais un peu juste en qualité du coup si on monte sur grand écran.

Les fichiers générés atterrissent dans ./proxy/ avec un identifiant propre.

J'oubliais : en restant sur squeeze (ou visiblement sur lucid) on est dans KDE 4.4 qui provoque un bug gênant (rapport d'après-dernière minute)… pour esquiver cela il faut ajouter un mini-patch à kdenlive (ou commenter soi-même la ligne 1611 de src/kdenlivedoc.cpp).

Malheureusement on ne peut pas faire de tests aussi étendus que quand une version sort et est installée par moult utilisateurs sur moult systèmes… d'où la nécessité de ressortir une sous-version corrigée : la 0.8.2.1 est prévue sous peu.

Dans la dépêche est proposée la méthode script MLT qui met tout dans un dossier $HOME/kdenlive/[date], ce qui peut faire un peu désordre (bazar dans $HOME, conflit avec des version installées, pas inclus dans les menus d'applications…).

Pour l'occasion je me suis me suis enfin motivé à regardé comment reconstruire un paquet .deb pour installer un programme proprement : bein ça peut être tout simple ?! (quand les dépendances sont pas trop exigeantes)

Juste après la sortie de la release, le paquet est apparu dans sid (merci le mainteneur - Patrick Matthäi).
Du coup j'ajoute les sources sid (alors que je reste en stable)

sudo echo deb-src http://ftp.fr.debian.org/debian/ sid main >> /etc/apt/sources.list

Je recompile mlt puis kdenlive

apt-get build-deb mlt
apt-get source mlt
cd mlt-*
debuild -us -uc
debi
cd ..

apt-get build-deb kdenlive
apt-get source kdenlive
cd kdenlive-*
debuild -us -uc
debi
cd ..

Tadam, c'est tout beau tout propre ! Ça vaut le coup d'ouvrir le manuel des fois…

On est à l'ère de la communication : même les papiers "scientifiques" (revues à comité de lecture) sont à prendre avec des pincettes (ma fac elle est 100 fois plus dynamique que toutes les autres, ma boîte elle détient des brevets super-killer)... Je le sais je trempe dedans ! Alors les instituts payés par les industriels, ils sont un peu là pour faire oracle de ce qu'on veut qu'il advienne.

Pour revenir au sujet : depuis etch j'ai jamais rien "configuré" dans les debian que j'installe un peu partout, que ce soit pour ceux qui préfèrent XFCE, KDE ou gnome (à part le fond d'écran ?), juste une seule ligne de apt-get classique à la place des 20 téléchargements d'utilitaires variés et autres SDK... je suis pas très exigent, mais y'a de quoi travailler directement.

Il me semble que ça utilise des résolutions avec les dérivées ("linéarisé" style Newton) uniquement entre 2 tentatives, mais à chaque coup il faut reprendre en compte les parties non-linéaires du circuit : tous les gains varient, voire des circuits commutent complètement. Les vendeurs de logiciels de CAO se battent justement sur leurs optimisations, dans les phases de calcul non linéaire entre autres (là ou est toute la lenteur des résolutions "équilibrage harmonique" par exemple).

C'est aussi la différence entre les simulateurs "FastSpice" qui remplacent les exponentielles et autres par des polynômes valides dans une zone prédéfinie, et les simulateurs "SpiceAccurate" qui gardent l'expression mathématique réelle... et ça se voit nettement sur les résultats, quand des signaux cohabitent avec plusieurs ordres de grandeur d'écart.

Par contre en dehors des réponses "linéaires" (type filtres RLC du 2ème à 8ème ordre) ou des réponses "statiques" de composants (I=f(V) d'un transistor), les fonctions sont vite trop compliquées pour utiliser des outils comme maxima (comme tout ce pourquoi on emploie du "calcul lourd") ?

Tu n'en dis pas beaucoup sur ce que tu veux vraiment faire, c'est dûr de faire une réponse précise...

Je ne sais pas ce que tu appelles "calcul lourd", mais en électronique on passe des journées à optimiser des circuits avec 36 boucles de filtres imbriquées... Ces "jolies courbes" intéressent au point de charger des fermes de calcul des nuits entières pour explorer toutes les variations de paramètres qui interviennent en production.

Concrètement l'expression dans l'arctangeante est rapidement bien plus compliquée, et résolue par des algorithmes chiadés...

Pour explorer plus loin sur les simulateurs électriques, il y a "gnucap", "ngspice", "qucs" ; concrètement ils résolvent d'une manière ou d'une autre des équations décrites dans les modèles de type "BSIM4", "EKV3", "HICUM", etc.

Besoin de pousser plus loin dans cet axe ?

unxutils.sf.net (y'a zsh dedans, +les commandes standards)
ou gnuwin32.sf.net (packagings autour)

Je confirme : par exemple en EDA (conception electronique), un marché pas négligeable...

Tous les softs de référence (proprios très très cher) sont qualifiés pour RedHat. Il y a une utilisation intensive du graphisme 2D et pas mal de modules 3D apparaissent.

De plus en plus les boîtes font basculer les employés sur des plate-formes virtualisées : PC de base "Office Productivity" pour Outlook... et faisons le coeur de notre métier dans une fenêtre (ça m'énerve !) !

Donc on peut deviner qu'un bon paquet de retours à propos des performances agaçant les utilisateurs sont liés au graphismes qui ne répondent pas de manière satisfaisante.

Selon les recommandations des fournisseurs de soft les services IT installaient régulièrement des nouveaux drivers proprios (nvidia), mais ça complique bien la vie... et toute la dernière gamme de PC commandée a en fait des cartes graphiques AMD ! Donc des gros clients industriels remontent bien à RedHat & VM* le besoin de drivers adaptés.

</mavie>

Au boulot on nous a fait passer de NX à VNC en nous expliquant que c'était bien mieux... Je ne connais pas les arguments techniques, mais en tout cas c'est un bon vieux protocole avec plein d'implémentations libres et multi-plateformes, et ça marche (NX nous faisait souvent des trucs bizarres).

C'est comme pour Mickey, je comprends pas qu'une antiquité de plus de 50 ans ne soit pas assimilée au patrimoine commun... bravo la loi US.
Sinon, je vois pas comment un "mainmise sur unix" pas MS ne déclancherait pas tous les mécanismes antitrust...
Et puis il y a une telle économie qui repose sur unix (serveurs, embarqué de tout poil : google, nokia...) que c'est impossible que tout s'effondre comme ça ?

Je suis d'accord.
Et je suis peut-être naïf, mais je ne vois pas le grave problème de sécurité à utiliser une vieille version de logiciel de navigation ou autre, du moment qu'on a les mises à jour mineures ?
Au boulot, la plupart des postes sont encore en RHEL3 avec Firefox 1.5 et un vieux flash (9 je crois), tout le monde va encore sans problème sur le site de sa banque, les actualités ou autres résultats sportifs sans être bloqué ou se faire hameçonner à tour de bras...
Un bureau Linux des années 2000 était déjà très utilisable et sécurisé (même pour des non informaticiens), rien ne sert de toujours courir en avant poussé par je ne sais quelle peur panique de ne pas être à la page ?
Bref, moi j'aime bien Debian stable.

Il me semble que les astuces sont un peu dans le kernel mais aussi beaucoup dans la config (scripts d'init, modes ACPI, drivers Xorg)... Du coup c'est un peu plus qu'il faut importer (et verouiller vis-à-vis du reste de la distribution "hôte") ?

Je me permets de profiter de la visibilité de cette dépêche pour reformuler ma question
https://linuxfr.org/forums/15/28545.html
le coeur optimisé pour netbook / atom est intéressant (démarrage, conso...), mais comment faire pour l'utiliser avec des "repos" d'applications plus généralistes (debian / fedora) ?
Faut-il pour ça reconstruire toute une distro ? Si oui, comment être propre et efficace ?
Si des packagers de briques de bases traînent par là...

J'ai déjà appliqué à ma Lenny la plupart des "tunings" recommandés

- pour accélérer le boot en général :
http://wiki.debian.org/BootProcessSpeedup
http://lgallardo.com/en/2009/07/08/arranque-rapido-debian-14-segundosfast-boot-on-debian-14-sec/

- pour utiliser au mieux le matériel (disque SSD, ACPI...)
http://wiki.archlinux.org/index.php/Acer_Aspire_One

Le démarrage est encore long à mon goût (au moins 25-30 secondes voire plus ?), certains accès disques bloquent tout plusieurs secondes, le ventilo tourne trop souvent... en tout cas plus en comparaison de l'OS installé par le constructeur (dont je tairais le nom par honte).

Bref, il reste à optimiser pour tirer pleinement partie du matériel !

Et puis il faut laisser allumé en permanence le proxy à la maison (ou ailleurs)...
On parle souvent par ici des mini-serveur qui consomment peu, mais peu ce n'est pas rien.

La fonction magnétoscope enregistre au format MPEG2-TS...
Je pose donc ce type de fichiers comme ça par FTP sur le disque de la HD.

Le MPEG2 a l'avantage de demander assez peu de puissance pour le décodage
(en l'encodage), au prix d'un peu plus de bande passante...
Partant d'un DVD, il n'y a qu'à re-multiplexer sans transcoder,
ce qui va très vite et ne perd pas de qualité.

VLC fait les transcodages très bien à travers «Média / Convertir» (Ctrl-R)
(et permet des manips complexes par ligne de commande).
Ce programme suffit complètement à lui tout seul pour toutes les tâches multimédia.

J'étais tombé sur [http://www.picotux.com/] : il a un ARM 7 à 55 MHz, 2Mo de Flash, 8Mo de RAM, et sort en port série. Ça fait pas une grosse bête (il tourne en uClinux 2.4), mais du coup c'est plus un défi de bricolo de l'embarqué... suffisant pour une petite passerelle SSH ou de la domotique ? Mais bon, je suis pas assez geek pour l'avoir essayé !

Beau travail du développeur... bien rendu par cette excellente dépêche !

Je trouve étonnant que la parallélisation des initialisations ne soit pas apparue plus tôt, ça ne semble pas une idée si farfelue pourtant...

Et combien de temps avant qu'un nombre significatif de pilotes soit mis à jour avec l'API ? Et quand on utilise du vieux matos avec des pilotes qui n'évoluent plus trop ?

J'étais dans les starting-blocks pour faire une dépêche dès la sortie 5.0 mais...
chezmoiçamarchepas(tm) :
1) mon OS est trop vieux au boulot (RHEL3 "corporate"), dommage, je m'en servirai qu'à la maison (pour quoi faire ??)
2) dans mon doux foyer, à peine installé j'essaye le nouveau look de plot() -> segfault !
J'ai attendu la 5.0.1 - rebelotte.

En plus télécharger 105Mo pour m'en servir comme calculatrice (graphique) programmable : je reste à la 2.7 qui pèse que 9Mo et répond à mes attentes (ok, mes collègues se moquent quand ils me voient dans ce vieux truc tout moche) !
J'avais cru comprendre qu'on aurait enfin sous linux la possibilité de n'installer que les toolboxes qu'on veut (comme sous mimi-crosoft) mais non, pas moyen de faire une petite install discrète dans un coin de compte utilisateur...

Je crois que ce serait plus constructif que je fasse un tour sur bugzilla plutôt qu'à raconter ma vie ici
--> []

Moi je n'ai pas du tout ces résultats :

grosso-modo, dans mes essais j'ai plutôt retenu que le théora était à peine 20% plus gros que le FLV (Sorenson/H.263, la vraie référence à mon avis comme codec de streaming), lui-même à peine 20% plus gros que H.264, soit Theora/H264=+44%, pas +600% comme tu laisses entendre!
Il est vrai que je n'ai pas cherché des bitrates extrêmement faibles (la force de H264), mais les vidéos timbre poste qualité irregardable je trouve pas que ça apporte grand chose à "l'internet"...

Et je signale au passage qu'il existe un plugin "universel" Apple/Cosoft/blablabla : c'est Cortado... qui demande quand même d'avoir Java (un peu long à démarrer il est vrai).

Sous Linux, j'ai trouvé QTOctave assez agréable à utiliser.
Le mode pour emacs respecte plus la philosophie "roots"
(le qualifie-je de "chatoyant ?)
http://www.chemie.fu-berlin.de/chemnet/use/info/octave/octave_31.html

Sous "les fenêtres", "octave workshop" sert d'illustration à l'article Wikipédia
(le projet est en pause, mais il fonctionnait pas mal quand j'ai essayé) :
http://www.math.mcgill.ca/loisel/octave-workshop/

Les "trophées du libre" 2007 citaient QTOctave
et donnaient une liste de projets similaires, mais assez anciens et peu avancés :
http://www.tropheesdulibre.org/QtOctave.html?lang=fr
-> Koctave http://athlone.ath.cx/~matti/kde/koctave/
-> Yaog http://yaog.sourceforge.net/
-> Octivate http://octivate.sourceforge.net/