Planet

05 Avril 2012 à 01:22

Prompt Bash pour GIT via Rom1

J’utilise GIT depuis quelques mois, et je trouve ça vraiment génial. Si vous ne connaissez pas, ou peu, vous ne pouvez pas ne pas lire le livre Pro Git (sous licence cc-by-nc-sa). Les explications très claires permettent en quelques heures de maîtriser toutes les fonctions de base, et d’être à l’aise avec la gestion des branches (et bien plus encore).

Branches visibles

Le but de ce billet est de répondre à un problème particulier : par manque d’inattention, il m’est arrivé plusieurs fois de commiter des changements sur une mauvaise branche (j’étais persuadé d’être sur une branche, en fait j’étais sur une autre). Ce n’est pas très grave (on peut s’en sortir), mais c’est pénible.

Je souhaiterais donc avoir le nom de la branche dans le prompt bash.

Des solutions existent déjà : le paquet git embarque même un script qui répond au besoin. Certains utilisent aussi des scripts personnalisés. Mais aucun de ceux que j’ai trouvés ne me convenait. J’ai donc écrit mon propre script.

Mes prompts

Version simple

J’ai commencé par une version simple, qui ajoute en couleur @nomdelabranche à la fin du prompt. Un exemple vaut mieux qu’un long discours :

rom@rom-laptop:~/dev$ cd myproject/ rom@rom-laptop:~/dev/myproject@master$ git checkout testing Switched to branch 'testing' rom@rom-laptop:~/dev/myproject@testing$ cd img rom@rom-laptop:~/dev/myproject/img@testing$

Dans une arborescence ayant plusieurs projets GIT imbriqués (dans le cas de l’utilisation de sous-modules), la branche des projets parents n’est pas affichée :

rom@rom-laptop:~/dev$ cd mybigproject/ rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/ rom@rom-laptop:~/dev/mybigproject/submodule@master$ git checkout exp Switched to branch 'exp' rom@rom-laptop:~/dev/mybigproject/submodule@exp$ cd .. rom@rom-laptop:~/dev/mybigproject@master$

Version améliorée

Dans cette version simple, le nom de la branche est toujours affiché à la fin. Cela ne me convient pas, je le voudrais toujours à la racine du projet en question. C’est ce que permet la version améliorée.

Voici le résultat avec les mêmes commandes :

rom@rom-laptop:~/dev$ cd myproject/ rom@rom-laptop:~/dev/myproject@master$ git checkout testing Switched to branch 'testing' rom@rom-laptop:~/dev/myproject@testing$ cd img rom@rom-laptop:~/dev/myproject@testing/img$

Et avec des sous-modules, la branche des projets parents est affichée :

rom@rom-laptop:~/dev$ cd mybigproject/ rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/ rom@rom-laptop:~/dev/mybigproject@master/submodule@master$ git checkout exp Switched to branch 'exp' rom@rom-laptop:~/dev/mybigproject@master/submodule@exp$ cd .. rom@rom-laptop:~/dev/mybigproject@master$

En image :

Script

Voici le script, sous licence WTFPL : gitbashprompt.

wget http://dl.rom1v.com/gitbashprompt/gitbashprompt

Une fois téléchargé, éditez le fichier ~/.bashrc pour remplacer l’initialisation de la variable PS1 :

PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

par :

. gitbashprompt

Pour tester, ouvrir un nouveau terminal.

Par défaut, le script utilise la version améliorée. Pour utiliser la version simple, changer la variable gpb_style au début du script.

Conclusion

Tout d’abord, je suis content d’avoir exactement le comportement que je souhaitais pour mon GIT.

Ensuite, j’ai découvert le fonctionnement du prompt, avec notamment les subtilités d’échappement de caractères de la variable PS1 et la prise en compte des caractères de contrôle « \[ » et « \] ».

Enfin, je me suis enfin décidé à étudier la gestion des couleurs de Bash (qui, à première vue, est assez repoussante, il faut bien l’avouer). Mes scripts seront donc plus jolis à l’avenir ;-)

Annexe

Voici le code du script, pour les fainéants qui veulent le lire sans cliquer sur le lien :

#!/bin/bash # Git bash prompt v0.1 (2012-04-04) # By Romain Vimont (®om) <rom@rom1v.com> # # Save this file to ~/gitbashprompt and replace 'PS1' initialization by: # . gitbashprompt # # See <http://blog.rom1v.com/2012/04/prompt-bash-pour-git/> # Styles (end or exact) # end: ~/any/myproject/subfolder@branch # exact: ~/any/myproject@branch/subfolder gbp_style=exact # Colors nocol='\[\e[0m\]' col='\[\e[34m\]' # blue if [ "$gbp_style" = end ] then PS1='\u@\h:\w$( gitinfo="$(git branch 2>/dev/null | grep "^*" | cut -c3-)"; if [ "$gitinfo" ] then printf '$col'@"$gitinfo"'$nocol' fi )\$ ' elif [ "$gbp_style" = exact ] then PS1='\u@\h:$( SFI="$IFS" IFS=/ path="\w" tokens=($path) IFS="$SFI" i=0 curpath= token="${tokens[$i]}" while [ "$token" ] do etoken="$token" if [ $i = 0 ] then if [ "$token" = "~" ] then etoken="'$HOME'" fi else printf / curpath="$curpath/" fi curpath="$curpath$etoken" printf "$token" cd "$etoken" if [ -d ".git" ] then gitinfo="$(git branch 2>/dev/null | grep "^*" | cut -c3-)" if [ "$gitinfo" ] then printf '$col'@"$gitinfo"'$nocol' fi fi i=$(($i+1)) token="${tokens[$i]}" done )\$ ' else PS1='\u@\h:(incorrect git bash prompt style)\$' fi
04 Avril 2012 à 23:22

Prompt Bash pour GIT via Rom1

J’utilise git depuis quelques mois, et je trouve ça vraiment génial. Si vous ne connaissez pas, ou peu, vous ne pouvez pas ne pas lire le livre Pro Git (sous licence cc-by-nc-sa). Les explications très claires permettent en quelques heures de maîtriser toutes les fonctions de base, et d’être à l’aise avec la gestion des branches (et bien plus encore).

Branches visibles

Le but de ce billet est de répondre à un problème particulier : par manque d’attention, il m’est arrivé plusieurs fois de commiter des changements sur une mauvaise branche (j’étais persuadé d’être sur une branche, en fait j’étais sur une autre). Ce n’est pas très grave (on peut s’en sortir), mais c’est pénible.

Je souhaiterais donc avoir le nom de la branche dans le prompt bash.

Des solutions existent déjà : le paquet git embarque même un script qui répond au besoin. Certains utilisent aussi des scripts personnalisés. Mais aucun de ceux que j’ai trouvés ne me convenait. J’ai donc écrit mon propre script.

Mes prompts

Version simple

J’ai commencé par une version simple, qui ajoute en couleur @nomdelabranche à la fin du prompt. Un exemple vaut mieux qu’un long discours :

rom@rom-laptop:~/dev$ cd myproject/ rom@rom-laptop:~/dev/myproject@master$ git checkout testing Switched to branch 'testing' rom@rom-laptop:~/dev/myproject@testing$ cd img rom@rom-laptop:~/dev/myproject/img@testing$

Dans une arborescence ayant plusieurs projets GIT imbriqués (dans le cas de l’utilisation de sous-modules), la branche des projets parents n’est pas affichée :

rom@rom-laptop:~/dev$ cd mybigproject/ rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/ rom@rom-laptop:~/dev/mybigproject/submodule@master$ git checkout exp Switched to branch 'exp' rom@rom-laptop:~/dev/mybigproject/submodule@exp$ cd .. rom@rom-laptop:~/dev/mybigproject@master$

Version améliorée

Dans cette version simple, le nom de la branche est toujours affiché à la fin. Cela ne me convient pas, je le voudrais toujours à la racine du projet en question. C’est ce que permet la version améliorée.

Voici le résultat avec les mêmes commandes :

rom@rom-laptop:~/dev$ cd myproject/ rom@rom-laptop:~/dev/myproject@master$ git checkout testing Switched to branch 'testing' rom@rom-laptop:~/dev/myproject@testing$ cd img rom@rom-laptop:~/dev/myproject@testing/img$

Et avec des sous-modules, la branche des projets parents est affichée :

rom@rom-laptop:~/dev$ cd mybigproject/ rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/ rom@rom-laptop:~/dev/mybigproject@master/submodule@master$ git checkout exp Switched to branch 'exp' rom@rom-laptop:~/dev/mybigproject@master/submodule@exp$ cd .. rom@rom-laptop:~/dev/mybigproject@master$

En image :

gitbashprompt

Script

Le script, sous licence WTFPL, est disponible sur un dépôt git :

git clone http://git.rom1v.com/gitbashprompt.git

(ou sur github)

Une fois cloné, éditez le fichier ~/.bashrc pour remplacer l’initialisation de la variable PS1 :

PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

par :

. full/path/to/your/gitbashprompt

Pour tester, ouvrir un nouveau terminal.

Conclusion

Tout d’abord, je suis content d’avoir exactement le comportement que je souhaitais pour mon git.

Ensuite, j’ai découvert le fonctionnement du prompt, avec notamment les subtilités d’échappement de caractères de la variable PS1 et la prise en compte des caractères de contrôle \[ et \].

Enfin, je me suis enfin décidé à étudier la gestion des couleurs de Bash (qui, à première vue, est assez repoussante, il faut bien l’avouer). Mes scripts seront donc plus jolis à l’avenir ;-)

04 Avril 2012 à 23:22

Prompt Bash pour GIT via Rom1

J’utilise git depuis quelques mois, et je trouve ça vraiment génial. Si vous ne connaissez pas, ou peu, vous ne pouvez pas ne pas lire le livre Pro Git (sous licence cc-by-nc-sa). Les explications très claires permettent en quelques heures de maîtriser toutes les fonctions de base, et d’être à l’aise avec la gestion des branches (et bien plus encore).

Branches visibles

Le but de ce billet est de répondre à un problème particulier : par manque d’attention, il m’est arrivé plusieurs fois de commiter des changements sur une mauvaise branche (j’étais persuadé d’être sur une branche, en fait j’étais sur une autre). Ce n’est pas très grave (on peut s’en sortir), mais c’est pénible.

Je souhaiterais donc avoir le nom de la branche dans le prompt bash.

Des solutions existent déjà : le paquet git embarque même un script qui répond au besoin. Certains utilisent aussi des scripts personnalisés. Mais aucun de ceux que j’ai trouvés ne me convenait. J’ai donc écrit mon propre script.

Mes prompts

Version simple

J’ai commencé par une version simple, qui ajoute en couleur @nomdelabranche à la fin du prompt. Un exemple vaut mieux qu’un long discours :

rom@rom-laptop:~/dev$ cd myproject/ rom@rom-laptop:~/dev/myproject@master$ git checkout testing Switched to branch 'testing' rom@rom-laptop:~/dev/myproject@testing$ cd img rom@rom-laptop:~/dev/myproject/img@testing$

Dans une arborescence ayant plusieurs projets GIT imbriqués (dans le cas de l’utilisation de sous-modules), la branche des projets parents n’est pas affichée :

rom@rom-laptop:~/dev$ cd mybigproject/ rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/ rom@rom-laptop:~/dev/mybigproject/submodule@master$ git checkout exp Switched to branch 'exp' rom@rom-laptop:~/dev/mybigproject/submodule@exp$ cd .. rom@rom-laptop:~/dev/mybigproject@master$

Version améliorée

Dans cette version simple, le nom de la branche est toujours affiché à la fin. Cela ne me convient pas, je le voudrais toujours à la racine du projet en question. C’est ce que permet la version améliorée.

Voici le résultat avec les mêmes commandes :

rom@rom-laptop:~/dev$ cd myproject/ rom@rom-laptop:~/dev/myproject@master$ git checkout testing Switched to branch 'testing' rom@rom-laptop:~/dev/myproject@testing$ cd img rom@rom-laptop:~/dev/myproject@testing/img$

Et avec des sous-modules, la branche des projets parents est affichée :

rom@rom-laptop:~/dev$ cd mybigproject/ rom@rom-laptop:~/dev/mybigproject@master$ cd submodule/ rom@rom-laptop:~/dev/mybigproject@master/submodule@master$ git checkout exp Switched to branch 'exp' rom@rom-laptop:~/dev/mybigproject@master/submodule@exp$ cd .. rom@rom-laptop:~/dev/mybigproject@master$

En image :

gitbashprompt

Script

Le script, sous licence WTFPL, est disponible sur un dépôt git :

git clone http://git.rom1v.com/gitbashprompt.git

(ou sur github)

Une fois cloné, éditez le fichier ~/.bashrc pour remplacer l’initialisation de la variable PS1 :

PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

par :

. full/path/to/your/gitbashprompt

Pour tester, ouvrir un nouveau terminal.

Conclusion

Tout d’abord, je suis content d’avoir exactement le comportement que je souhaitais pour mon git.

Ensuite, j’ai découvert le fonctionnement du prompt, avec notamment les subtilités d’échappement de caractères de la variable PS1 et la prise en compte des caractères de contrôle \[ et \].

Enfin, je me suis enfin décidé à étudier la gestion des couleurs de Bash (qui, à première vue, est assez repoussante, il faut bien l’avouer). Mes scripts seront donc plus jolis à l’avenir ;-)

L’équipe parisienne d’Ubuntu-fr.org organise leur 13ème Ubuntu Party, pour promouvoir les logiciels libres et la culture libre et plus particulièrement Ubuntu, les samedi 12 et dimanche 13 mai 2012.

Ces rencontres, très grand public, se déroulent à la Cité des sciences et de l’industrie, à Paris (Porte de la Villette). L’entrée est libre et gratuite, il en est de même pour les nombreuses conférences, démonstrations et les ateliers.

Pour accueillir convenablement et aider efficacement les quelques milliers de visiteurs qui se rendent, comme tous les six mois, à ce grand rendez-vous du libre, nous avons besoin de vous !

Vous vous débrouillez bien avec Ubuntu ? Vous avez réussi à initier au moins un membre de votre famille ou un collègue aux logiciels libres ? Soyez bénévole les 12 et 13 mai prochains, vous ne le regretterez pas :)

Faites-vous connaître en remplissant ce court formulaire : http://participer.ubuntu-paris.org/?appel=benevole

Merci !

Bonjour !

La date limite des réponses à cette question étant le dimanche, 8 avril, 2012, il faudra faire vite !

La question que Ronnie nous pose dans le dernier numéro du FCM est :

« Ubuntu 12.04 sortira le 26 avril. Comptez-vous faire la mise à niveau ? »

Les réponses sont à donner ici : http://goo.gl/Ms7jI. Vous y trouverez, d'abord, la question avec un menu déroulant de réponses possibles : Maybe (peut-être), Yes, No. Ensuite, vous pouvez répondre brièvement à « If not, why not ? » (Si vous n'allez pas le faire, quelles en sont vos raisons ?)

Comme toujours, nous sommes à votre disposition pour traduire vos remarques si vous le désirez. Il suffit de nous les faire parvenir à webmaster@fullcirclemag.fr et nous vous enverrons une suggestion de traduction aussi rapidement que possible. Notez bien, cependant, que c'est à vous de mettre votre réponse sur le site ad hoc.

À bientôt !

Dans les semaines qui arrivent Objectif Libre, la société que j'ai fondé, va proposer plusieurs formations autour de Linux et des logiciels libres. Et en particulier une formation sur la virtualisation KVM/LibVirt et une autre formation OpenLDAP à Toulouse. Il y a plusieurs points commun à ces formations : déjà elles vont avoir lieu à Toulouse dans nos bureaux, mais surtout vous pouvez gagner une place gratuite pour y participer !

La formation KVM/LibVirt dure 3 jours et va se dérouler du 18 au 20 Avril 2012. Après une présentation de l'historique de la virtualisation, vous découvrirez les avantages de l'utilisation de QEMU, de KVM et de la LibVirt avant de vous intéresser à OpenStack, la solution de Cloud Computing libre qui n'en finit pas de monter !Vous pourrez trouver plus de détails sur la fiche de cette formation.

Concernant la formation OpenLDAP de 3 jours, du 14 au 16 Mai 2012, elle va bien sur vous permettre de découvrir OpenLDAP. Mais également de passer en détail son fonctionnement, sa configuration et son utilisation avec d'autres applications. Une fois encore plus de détails sont disponibles sur la fiche de cette formation.

Même si ces formations seront effectuées dans un environnement Ubuntu Server, tous les thèmes et techniques abordés sont également communs à d'autres distributions comme Debian, Red Hat ou CentOS. Les formation seront encadrées par des experts Linux qui sont également développeurs Ubuntu officiel.

Il existe 2 moyens pour suivre cette formation. Tout d'abord Comme cela est toujours le cas chez nos amis de Free Electrons, spécialistes de Linux Embarqué, pour remercier les contributeurs aux logiciels libres, nous sommes heureux de proposer une place gratuite à chacune de ces formations. Ainsi si vous avez réalisé une contribution significative au sein d'une communauté du Libre, n'hésitez pas à nous contacter pour candidater. La date limite des dépôts de candidature étant fixée au 8 Avril 2012 pour la formation KVM et au 21 avril pour la formation OpenLDAP. Chaque lauréat sera tiré au sort parmi les 10 contributeurs les plus méritants à nos yeux. Bien sur nous acceptons aussi bien les personnes sans emplois, que les étudiants ou les professionnels du moment qui contribuent au Libre. Les frais de déplacement et de logement éventuels pour venir à Toulouse, restent à la charge du lauréat (ou de sa société s'il s'agit d'un professionnel et que cette dernière est d'accord pour participer).

L'autre moyen pour y participer à ces formations étant tout simplement de prendre une place payante puisqu'il nous reste des places disponibles. Si vous êtes intéressés n'hésitez pas à nous contacter en utilisant notre formulaire de contact ou au 05 82 95 65 36 !

29 Mars 2012 à 08:58

Voici le 57 ! via Full Circle Mag FR

Bonjour à toutes et à tous !

L'équipe du FCM-fr est fière de vous présenter le numéro 57, celui de janvier 2012 ! Vous le trouverez, comme d'habitude, ici ou en cliquant directement sur la photo ci-dessous. Petit à petit, nous arrivons à rattraper le temps perdu, sauf pour ce qui concerne les numéros spéciaux et les anciens numéros et .........

Issue57-fr

Ce mois-ci, les nouveautés comprennent :

  • Une présentation d'Enlightenment 17, un environnement de bureau zen ;
  • outre les séries de tutoriels habituelles, vous y trouverez comment créer une clé USB cryptée et comment utiliser le cache Web Varnish ;
  • il y a une critique d'openArtist 5th incarnation qui vous mettra l'eau à la bouche ;
  • dans Linux Lab, vous apprendrez à créer un serveur, et devenir Maître du jeu, avec TMW, The Mana World ;
  • en plus, il y a trois - oui, trois ! - articles concernant les jeux sous Ubuntu ;
  • un des courriers parle de l'utilisation de Garmin avec Ubuntu ;
  • et puis, et puis ...

Avec plus de 53 pages, il y a vraiment trop de choses à mentionner dans cette brève présentation du numéro - à vous de découvrir le reste par vous-même. Nous sommes certains que vous en serez ravis.

D'ailleurs, le numéro 56 a été téléchargé plus de 7000 fois - c'est dire combien nous vous sommes utiles. Tous ceux qui veulent vraiment nous aider seront les bienvenus. Apparemment, vous en profitez - à vous d'y contribuer selon vous moyens et le temps que vous avez.
Pas besoin de connaître l'anglais pour relire le PDF en français. Mais cette relecture, par plusieurs personnes différentes, est vraiment nécessaire pour un numéro de qualité.

Rendez-vous sur le Wiki pour les instructions sur comment participer et comment vous inscrire aussi sur le Forum, lieu de discussions, sur notre travail, mais aussi sur le jardinage, le temps et pas mal d'autres choses : nous sommes non seulement des « collègues », mais également des copains !

En espérant vous accueillir très bientôt parmi nous et en vous souhaitant bonne lecture de ce numéro bien fourni,

Toute l'équipe du FCM-fr et notamment FredPhil91, le scribeur de ce numéro, Bab, Frangi, Shinichi, Azenor et moi-même, AuntieE.

Je fais régulièrement des vidéos (comme beaucoup d’entre vous sûrement) avec mon camescope HD et les transfère ensuite sur mon PC afin d’en faire une sauvegarde ou de les retravailler pour y ajouter de la musique et des textes.

J’utilise pour cela 2 principaux logiciels : Openshot et FFdiaporama. Chacun a ses avantages et ses inconvénients, mais ce n’est pas le propos de cet article. Les vidéos faites avec les camescopes compacts peuvent se révéler tremblantes suivant les conditions dans lesquelles vous avez fait la prise de vues (marche, course, vélo, etc ..) . Même si le stabilisateur est enclenché, on peut voir le tremblement de façon plus ou moins prononcé.

Dans cet article je vais vous présenter comment on peut rendre un film fluide sans tremblements afin de le rendre agréable à regarder, surtout pour des clips vidéos.

Pour celà je vais partir d’une séquence vidéo sur la cote de granit rose.

Voici par exemple, un bout de vidéo avant et après la stabilisation. le résultat est assez parlant.

J’ai donc chercher comment faire de la stabilisation sous Linux. D’après ce que j’ai vu,il y a trois méthodes dont 2 qui partent de la même base. Il existe un plugin de stabilisation Vid.Stab qui peut etre utilisé par le programme trancode et par le programme melt.

  1. Transcode avec le plugin Vid.stab
  2. Melt avec le plugin Vid.stab
  3. Virtualdub (sous wine) avec le plugin Deshaker.

1) Transcode avec le plugin Vid.stab

L’installation est relativement simple. Il suffit de télécharger le plugin sur la page Download du plugin et d’installer les fichiers contenus dans le zip dans le répertoire /usr/lib/transcode. Ensuite, il faut lancer 2 commandes transcode pour faire la stabilisation : une pour faire l’analyse du fichier vidéo et l’autre pour faire la stabilisation.

Vous pouvez consulter l’article suivant pour plus d’infos :

J’ai fait l’essai et ca n’a pas été vraiment concluant. En fait je pense que tout est une histoire de paramètres, et qu’il faut donc faire pas mal de test avant d’avoir une bonne configuration. Je pense qu’il faut que je refasse des essais.

2) Melt avec le plugin Vid.stab

Attention : les manipulations ci-dessous sont a faire en toute connaissance de cause du fait de l’ajout de repository pour les programmes.

Avant que vous ne vous lanciez dans cette manipulation (qui peut fonctionner pour certains) , je tiens a vous dire que de mon coté ça n’a pas fonctionné du tout et en plus que ça a un peu modifié ma config ubuntu en désinstallant pas mal de choses. Donc faites attention aux manipulations.

Je suis parti de l’article Ubuntu – Stabilize your camcorder video with MELT & vid.stab pour faire tout celà. Les conditions pour faire cette manipulation sont les suivantes :

  • Avoir FFMPEG en version 0.9 ou +
  • Avoir MLT en version 0.7.6 ou +

Voyons donc les version des outils présents sur la machine :

FFMPEG :

ffmpeg –version (attention 2 tirets)
ffmpeg version 0.7.3-4:0.7.3-0ubuntu0.11.10.1, Copyright (c) 2000-2011 the Libav developers

MELT

melt –version
MLT melt 0.7.4

Donc, on voit ici que les versions sont incorrectes pour ce que je veux faire. Il faut donc installer les nouvelles version avec un nouveau dépôt. Je me suis pris pas mal la tête entre les installations de paquets qui désinstallent d’autres, et ainsi de suite avant de tomber sur ce message sur le forum  : http://forum.ubuntu-fr.org/viewtopic.php?id=834251

Cependant, rien a faire, je n’y arrive pas, le programme melt m’indique une erreur de codecs etc …  et j’abandonne là dessus .

3) Virtualdub (sous wine) avec le plugin Deshaker.

Là c’est une manipulation carrément différente, car on utilise un programme Windows dans le moteur Wine bien connu des linuxiens. Le principe est d’utiliser Virtualdub avec un plugin de stabilisation (deshaker). Pour tout ceci , j’ai utilisé le didacticiel suivant : HowTo install VirtualDub under wine with deshaker plugin . Le principe est de faire les choses suivantes:

  • Installer Wine
  • Télécharger Virtualdub et l’installer
  • Télécharger et installer les codecs Vidéo/Audio pour Windows ffdshow
  • Télécharger et installer les codecs Xvid
  • Télécharger et installer le plugin de stabilisation(deshaker)

Je vous laisse le soin de suivre le tutoriel pour toute cette phase d’installation, ce n’est pas très compliqué à faire. Une fois ceci fait passons donc à la pratique.

Ce que je veux faire , c’est passer mes videos MTS (format HD) à travers une phase de stabilisation en vue d’en faire un petit clip vidéo par exemple. Je vais donc procéder de la suite dans un petit script shell unix.

  1. Convertir ma vidéo en fichier AVI pour virtualdub car celui ci n’accepte pas les fichiers MTS d’origine.
  2. Lancer une phase Virtualdub d’analyse de la vidéo (phase 1)
  3. Lancer la phase Virtualdub de stabilisation
  4. Le script final

1) Conversion MTS en AVI

Une commande très simple ffmpeg permet de faire le travail :

2) Analyse de la vidéo

Cette phase 1 est assez longue car Virtualdub teste la vidéo afin de déterminer les endroits où il y a tremblement. Pour ce faire, il suffit de charger la vidéo avec VirtualDub , d’appliquer le filtre Deshaker et de le configurer avec toutes les valeurs par défaut. Pour lancer , l’analyse il suffit de sélectionner le menu Vidéo :

Il faut aussi penser à configurer la compression Vidéo au format xvid, sinon le logiciel ne fera pas de compression et vous vous retrouverez avec un gros fichier en sortie (par exemple 2 go pour 6 secondes de vidéos …). Pour ce faire, dans le menu Vidéo , puis compression , il faut appliquer la compression Xvid

3) Stabilisation

Dans cette phase 2 qui est plus rapide que la précédente, Virtualdub va prendre ses informations saisies en phase 1) afin de générer une vidéo stabilisée. Cependant, pour faire ce travail, virtualdub réajuste chaque image de la vidéo afin d’éviter le tremblement. Ce qui conduit au final avec une vidéo avec des bords tremblants noirs. Il faut donc les supprimer de la vidéo finale. Pour ce faire il faut sélectionner le menu Edge compensation à la valeur : Adaptive zoom full

A noter : Je pense qu’il faut passer pas mal de temps pour bien configurer le plugin deshaker afin d’obtenir un résultat bien fluide. J’ai remarqué sur certaines séquences qu’il y avait des sauts du fait d’un gros tremblement ou sursaut de ma vidéo. Je pense qu’une configuration sur la sensibilité des sauts est sûrement possible pour parfaire le tout.

4) Le script

J’aime bien les scripts, je n’aime pas les choses répétitives donc je préfère passer un peu de temps a écrire et peaufiner les scripts pour en gagner plus tard.

Il faut d’abord enregistrer le travail que Virtualdub doit faire , c’est à dire les 2 passes du plugin deshaker ainsi que le compression xvid. Pour faire celà c’est très simple. On va créer 2 fichiers : un pour la phase 1 et un second pour la phase 2. Ces 2 fichiers ( process-ph1.vcf et process-ph2.vcf ) sont crées simplement par virtualdub avec la méthode suivante :

  • a) Ajouter et Configurer le plugin Deshaker. Positionner en phase 1.
  • b) Mettre la compression XVID
  • c) Dans le menu Fichier, sélectionner -> Save Processing Settings et enregistrer en donnant un nom de fichier.

d) Refaire la meme chose pour la phase 2 du plugin Deshaker.

Voilà qui est donc fait pour la configuration de Virtualdub. Maintenant je positionne ces scripts à l’endroit où son mes vidéos pour simplifier la chose.

La script (gen-stab.sh) devra donc faire les choses suivantes :

  • a) Convertir les fichiers MTS en AVI
  • b) Lancer la phase 1 de la stabilisation avec le fichier process-ph1.vcf
  • c) Lancer la phase 2 de la stabilisation avec le fichier process-ph2.vcf et créer le fichier « stabilisé »

Voici donc les script , rien de bien compliqué :

MTSDIR=/media/DDSVG/David/camescope/videos
WORKDIR=/work/ClipGranitRose2/AVI
WINDIR=/home/roozeec/Vidéos/VirtualDub

ffmpeg -y -i $MTSDIR/$1.MTS -f avi -aspect 16:9 -vcodec mpeg4 -b 8000000 -acodec ac3 -ab 128000 -s 704×384 $WORKDIR/$1-conv.avi

cd $WORKDIR
wine $WINDIR/VirtualDub.exe /c /s process-ph1.vcf /p $1-conv.avi temp.mp4 /r /x;
wine $WINDIR/VirtualDub.exe /c /s process-ph2.vcf /p $1-conv.avi $1-stab.avi /r /x;
rm temp.mp4

Pour le lancer, c’est très simple , il prend un paramètre donnant le numéro de la vidéo. Par exemple mon fichier MTS est 03102.MTS , je lance donc la script de cette facon : gen-stab.sh 03102 , il généra donc un fichier 03102-stab.avi

Maintenant, ca donne quoi au final ? Voici une vidéos de la cote de granit rose avec à gauche la vidéos stabilisée et à droit la vidéo originale :
Voilà vous savez tout , il faut passer quand même pas mal de temps , je pense , sur la configuration pour avoir un résultat satisfaisant pour les vidéos qui contiennent un tremblement prononcé.

Telecharger l'article au format PDF

Petite commande utile, pour voir quels sont les packages qui sont installés sur votre machine, pour générer un script de réinstall à l'arrache par exemple, ou pour avoir une base.

On va utiliser la commande dpkg-query, qui permet d'interroger la base de données des paquetages installés.

sudo dpkg-query -Wf '${Installed-Size} - ${Package} n' | sort -n

On prend tous les paquets installés, en filtrant la sortie avec un format, qui n'affichera que la taille installée, ainsi que le nom. Le sort permet de trier par ordre croissant de taille.

Source

Petite commande utile, pour voir quels sont les packages qui sont installés sur votre machine, pour générer un script de réinstall à l'arrache par exemple, ou pour avoir une base.

On va utiliser la commande dpkg-query, qui permet d'interroger la base de données des paquetages installés.

sudo dpkg-query -Wf '${Installed-Size} - ${Package} n' | sort -n

On prend tous les paquets installés, en filtrant la sortie avec un format, qui n'affichera que la taille installée, ainsi que le nom. Le sort permet de trier par ordre croissant de taille.

Source

Pages