PROJET AUTOBLOG


®om's blog

Site original : ®om's blog

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Modifier la luminosité d'une vidéo dans avconv (ffmpeg)

mardi 14 août 2012 à 12:26

Pour partager des vidéos capturées par mon appareil photo, je les convertissais jusqu’alors en Ogg/Theora grâce à ffmpeg2theora. Ce format (contrairement au H264) est libre et lisible nativement par Firefox, y compris par la version mobile.

Mais j’envisage depuis longtemps de passer à WebM (le format libéré par Google il y a un peu plus de deux ans), plus performant, lui aussi lu nativement par Firefox (et par d’autres). Pour cela, je vais utiliser avconv.

avconv

Qu’est-ce qu’avconv ? Le meilleur moyen de le savoir est d’exécuter ffmpeg sans arguments :

$ ffmpeg
…
*** THIS PROGRAM IS DEPRECATED ***
This program is only provided for compatibility and will be removed in a future release. Please use avconv instead.

EDIT : En fait, c’est plus compliqué que ça.

J’ai précisé ffmpeg dans le titre du billet car je pense que c’est encore sous ce nom que l’outil est le plus connu. Le contenu de ce billet s’applique aussi bien à ffmpeg qu’à avconv.

Filtres

Il m’arrive d’avoir besoin d’appliquer des filtres très simples : typiquement, augmenter la luminosité d’une vidéo. ffmpeg2theora permet de le faire directement grâce à l’option -B.

Mais on a beau chercher dans man avconv, on ne trouve rien.

frei0r

C’est là qu’intervient le projet frei0r. Il s’agit d’une API permettant d’appliquer des filtres vidéo que chaque application pourra utiliser. Et ça tombe bien, l’application avconv peut l’utiliser si elle a été compilée avec l’option --enable-frei0r.

La bonne nouvelle, c’est que la version distribuée par Debian wheezy est compilée avec cette option. La mauvaise, c’est que celle fournie dans Ubuntu 12.04 ne l’est pas.

frei0r a besoin de plugins permettant d’appliquer les filtres. Il est nécessaire pour cela d’installer frei0r-plugins :

sudo apt-get install frei0r-plugins

avconv + frei0r

La syntaxe pour utiliser frei0r dans avconv est la suivante :

-vf frei0r=<filter_name>[{:|=}<param1>:<param2>:...:<paramN>]

Mais comment connaître les filter_names disponibles et leurs paramètres ? Je n’ai trouvé aucune documentation à ce sujet. J’ai donc consulté les sources.

À partir de là, on comprend facilement que la luminosité est modifiée par le filtre brightness comportant un paramètre de type double (voir notamment la fonction f0r_get_param_info) compris entre 0 (sombre) et 1 (clair) (0.5 étant la luminosité de la vidéo d’origine).

En respectant la syntaxe, cela donne par exemple :

avconv -i video.mts -s 640x360 -ac 1 -q:a 2 -b:v 600k \
    -vf frei0r=brightness:0.6 output.webm

Il existe plein d’autres filtres. Par exemple pour le contraste, c’est contrast0r :

-vf frei0r=contrast0r:0.4

Pour les combiner, il suffit de concaténer plusieurs blocs -vf :

-vf frei0r=brightness:0.6,frei0r=contrast0r:0.4

Conclusion

Malgré les apparences, avconv permet, pour peu qu’il soit compilé avec l’option-qui-va-bien, d’encoder des vidéos en modifiant la luminosité, le contraste, et d’appliquer bien d’autres filtres… ce qui est très pratique.

Utiliser Wireshark sous Debian

samedi 2 juin 2012 à 12:48

Wireshark est un outil incontournable pour connaître les paquets qui transitent sur le réseau. Mais on se retrouve vite bloqué à cause d’un problème de droits.

En effet, en démarrant wireshark avec un compte utilisateur non-root, l’interface graphique s’affiche, mais il est impossible de capturer les trames : aucune interface réseau n’est disponible.

Devant ce problème, que fait l’utilisateur pressé ? Il démarre wireshark en root, bien sûr (c’est ce que je faisais sous Ubuntu) ! Eh bien pas de chance :

$ sudo wireshark
No protocol specified

(wireshark:27210): Gtk-WARNING **: cannot open display: :0

Déjà, c’est bien fait pour lui : on n’essaie pas de démarrer une interface graphique en root !

Mais comment faire alors ? En non-root on ne peut pas capturer, en root on ne peut pas démarrer…

Alors on lit la doc, qui propose deux solutions :

less /usr/share/doc/wireshark/README.Debian

EDIT : Une troisième solution, donnée en commentaire, me semble encore meilleure :

sudo tcpdump -pni eth0 -s0 -U -w - | wireshark -k -i -

Utiliser dumpcap pour capturer

Avec cette méthode, il faut d’abord capturer les paquets réseau et les sauver dans un fichier, grâce à dumpcat (en root), puis ouvrir ce fichier dans wireshark (non-root).

Pour démarrer la capture de l’interface eth0 dans le fichier /tmp/mycapture :

sudo dumpcap -i eth0 -w /tmp/mycapture

Pour connaître la liste des interfaces réseau capturables :

$ sudo dumpcap -D 
1. eth0
2. wlan0
3. nflog (Linux netfilter log (NFLOG) interface)
4. any (Pseudo-device that captures on all interfaces)
5. lo

Ctrl+C arrête la capture.

Le fichier généré n’est lisible que par root. Avant de l’ouvrir dans Wireshark, il faut donc changer ses droits :

sudo chmod +r /tmp/mycapture

C’est la méthode configurée par défaut sous Debian.

Autoriser les utilisateurs non-root

Si on souhaite à la fois capturer et analyser à partir de Wireshark (et permettre les captures “en live”), sans passer par dumpcap en ligne de commande, il faut autoriser les utilisateur non-root à capturer des paquets.

Pour cela :

sudo dpkg-reconfigure wireshark-common

Ce qui affiche :

 ┌─────────────────────┤ Configuration de wireshark-common ├──────────────────────┐
 │                                                                                │
 │ Dumpcap peut être installé afin d'autoriser les membres du groupe              │
 │ « wireshark » à capturer des paquets. Cette méthode de capture est préférable  │
 │ à l'exécution de Wireshark ou Tshark avec les droits du superutilisateur, car  │
 │ elle permet d'exécuter moins de code avec des droits importants.               │
 │                                                                                │
 │ Pour plus d'informations, veuillez consulter                                   │
 │ /usr/share/doc/wireshark-common/README.Debian.                                 │
 │                                                                                │
 │ Cette fonctionnalité constitue un risque pour la sécurité, c'est pourquoi      │
 │ elle est désactivée par défaut. En cas de doute, il est suggéré de la laisser  │
 │ désactivée.                                                                    │
 │                                                                                │
 │ Autoriser les utilisateurs non privilégiés à capturer des paquets ?            │
 │                                                                                │
 │                      <Oui>                         <Non>                       │
 │                                                                                │
 └────────────────────────────────────────────────────────────────────────────────┘

Après avoir répondu Oui, tous les utilisateurs du groupe wireshark (aucun, par défaut) seront autorisés à capturer les paquets.

Remarque : un programme non-root sera donc en théorie capable de savoir tout ce qui passe sur le réseau (déjà qu’il est capable de connaître tout ce qui est tapé au clavier).

Il ne reste donc plus qu’à ajouter son compte utilisateur au groupe wireshark :

sudo addgroup $USER wireshark

Cette modification ne sera prise en compte qu’après une reconnexion du compte utilisateur (il faut donc fermer la session et en démarrer une nouvelle).

Se connecter à un téléphone Android depuis Debian

jeudi 24 mai 2012 à 22:41

Je décrivais récemment la marche à suivre pour se connecter à un téléphone Android à partir d’une distribution GNU/Linux (qui correspond à ce que dit la documentation officielle).

Pour résumer, il s’agit de créer un fichier /etc/udev/rules.d/51-android.rules contenant :

SUBSYSTEM=="usb", MODE="0666", GROUP="plugdev"

Mais ceci ne fonctionne pas sur Debian (en tout cas ni sur testing ni sur sid) :

$ adb devices
List of devices attached 
????????????    no permissions

En effet, contrairement aux autres distributions, Debian possède un fichier /lib/udev/rules.d/91-permissions.rules qui contient, entre autres :

# usbfs-like devices
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", \
                                MODE="0664"

Comme 91 > 51, ce fichier est parsé après notre fichier 51-android.rules.

La solution est donc très simple : renommer 51-android.rules en 92-android.rules afin que les permissions ne soient pas écrasées :

sudo mv /etc/udev/rules.d/{51,92}-android.rules

(ou en utilisant n’importe quel entier entre 92 et 99)

Après cette modification, udev doit être redémarré :

sudo service udev restart

et le téléphone débranché puis rebranché.

Et là, ça fonctionne :

$ adb devices
List of devices attached 
040140621600C00D        device

Merci à unforgiven512 qui m’a donné la solution (en anglais).

Configurer le thème des applications GTK sous KDE

mardi 15 mai 2012 à 20:08

Après être passé de KDE à Gnome il y a un peu plus de 4 ans, j’ai décidé de revenir à KDE. Mais de la même manière que les applications prévues pour KDE ne s’intègrent pas correctement à Gnome, les applications prévues pour Gnome sont horribles sur KDE : elles n’ont pas de thème du tout (sauf si vous appelez “thème” l’apparence de Windows 95).

Voici par exemple à quoi ressemble GIMP :

gimp-moche

Le problème doit être résolu deux fois : une première pour les applications utilisant GTK2 et une seconde pour celles utilisant GTK3.

GTK2

Pour GTK2, c’est facile. Sous Debian :

sudo apt-get install gtk2-engines-oxygen gtk-chtheme

(le nom des paquets peut varier selon votre distribution)

Il ne reste alors plus qu’à exécuter :

gtk-chtheme

et choisir le thème oxygen-gtk :

gtk-chtheme

Le thème des applications telles que Firefox/Iceweasel, GIMP, Ario ou Eclipse sera alors totalement cohérent avec celui des applications prévues pour KDE :

gimp-oxygen

Pour pousser plus loin l’intégration de Firefox/Iceweasel, il y a même un module complémentaire.

GTK3

Pour GTK3, ce devrait être presque pareil… sauf que le paquet gtk3-engines-oxygen (ou oxygen-gtk3) n’est pas encore dans les dépôts Debian (il est par contre dans d’autres distributions, comme Ubuntu ou Arch Linux).

Il est bien sûr possible de télécharger les sources pour l’installer manuellement.

Mais nous pouvons nous contenter du thème natif de Gnome. Pour le configurer, il suffit d’installer gnome-themes-standard :

sudo apt-get install gnome-themes-standard

et de créer un fichier ~/.config/gtk-3.0/settings.ini contenant :

[Settings]
gtk-theme-name=Adwaita
gtk-fallback-icon-theme=gnome

(voir GtkSettings)

Gedit avant :

gedit-moche

Gedit après :

gedit-adwaita

En attendant qu’Oxygen GTK3 soit disponible dans les dépôts, c’est mieux que rien…

EDIT : oxygen-gtk3 est maintenant disponible dans les dépôts.

Lire des images et des vidéos sans serveur X (dans un TTY)

samedi 7 avril 2012 à 23:01

Saviez-vous qu’il était possible de lire des images et des vidéos dans un TTY, sans serveur X ? Je ne parle pas de les afficher en ASCII-art, mais bien de les afficher “graphiquement” :

bbb-tty

Je ne le savais pas jusqu’à aujourd’hui. En fait, c’est possible grâce à des programmes qui écrivent directement dans le framebuffer.

Pour tester les outils suivants, lancez un TTY grâce aux raccourcis Ctrl+Alt+F[1-6]. Pour revenir à votre session graphique, faites Ctrl+Alt+F7 (sur certaines distributions, par défaut la session graphique est plutôt accessible avec Ctrl+Alt+F1, Ctrl+Alt+F8 ou Ctrl+Alt+F9, essayez…).

Images

Pour afficher des images, il faut installer le paquet fbi (framebuffer imageviewer) :

sudo apt-get install fbi

Puis simplement exécuter :

fbi monimage.jpg

ou même

fbi *.jpg

(PgUp et PgDown permettent de naviguer entre les images)

Cet outil est vraiment très rapide (sauf pour le zoom). C’est un peu l’équivalent de feh qui, lui, fonctionne en mode graphique.

Vidéos

Pour les vidéos, nous avons besoin de MPlayer :

sudo apt-get install mplayer

En lançant dans un TTY :

mplayer mavidéo.avi

MPlayer choisit le pilote fbdev. Nous pouvons aussi le choisir explicitement :

mplayer -vo fbdev mavidéo.avi

Par contre, la vidéo s’affiche à sa taille originale, alors que nous la voulons en plein écran. Il faut donc la mettre à l’échelle, grâce aux paramètres de mplayer. Sur un écran 1680×1050 par exemple :

mplayer -fs -vf scale=1680:-3 mavidéo.avi

-3 permet de calculer la seconde composante à partir de la première et de l’aspect-ratio. C’est dans le man :

 0: largeur/hauteur dimmensionnées à d_width/d_height
-1: largeur/hauteur originales
-2: Calcule l/h en utilisant l'autre dimension et le rapport hauteur/largeur
    redimensionné.
-3: Calcule l/h en utilisant l'autre dimension et le rapport hauteur/largeur
    original.
-(n+8): Comme -n ci-dessus, mais en arrondissant les dimensions au plus
        proche multiple de 16.

Sur mon pc portable, j’arrive sans problème à lire dans un TTY une vidéo 1080p (j’ai testé avec Big Buck Bunny en MP4, redimensionnée lors de la lecture à la taille de mon écran, 1680×1050).

Par contre, sur une machine moins puissante (une EeeBox, qui hébergeait ce blog par le passé), MPlayer saccade, même sur des vidéos basse définition, que VLC lit sans problèmes. Pour améliorer les performances de lecture de MPlayer, il est possible de changer l’algorithme de zoom logiciel, grâce à l’option -sws. Par exemple, pour utiliser bilinéaire rapide au lieu de bicubique :

mplayer -fs -vf scale=1680:-3 -sws 0 mavidéo.avi

Avec ce paramètre, ça ne saccade plus.

Cependant, sur la EeeBox, dans ce cas les couleurs sont incorrectes apparemment à cause d’un bug de pilote vidéo Intel. J’ai donc quand même installé un serveur X avec un gestionnaire de fenêtres minimaliste, awesome. Mais c’est une autre histoire…

ASCII-art

Je vous parlais d’ASCII-art au début du billet, il est également possible de lire les images ou les vidéos en ASCII (c’est juste moins joli), grâce à des commandes d’une élégance toute particulière.

Pour les images, nous pouvons installer le paquet caca-utils

sudo apt-get install caca-utils

Puis utiliser cacaview :

cacaview monimage.jpg

Pour les vidéos :

mplayer -vo caca mavidéo.avi

bbb-ascii

Conclusion

Je n’en revenais pas qu’il soit possible de lire des vidéos sans serveur X. Sur une machine destinée à une utilisation multimédia (branchée sur la TV par exemple), il n’y a donc nullement besoin d’un serveur X (paradoxalement).

Error happened! 0 - Call to undefined function simplexml_load_string() In: /var/www/Projet-Autoblog/autoblogs/autoblog.php:364 http://www.couturat.fr/Projet-Autoblog/autoblogs/blogrom1vcom_4af8d17d34d978843ff2ff40339aa5760e6458bc/?11 #0 /var/www/Projet-Autoblog/autoblogs/autoblog.php(932): VroumVroum_Blog->update() #1 /var/www/Projet-Autoblog/autoblogs/blogrom1vcom_4af8d17d34d978843ff2ff40339aa5760e6458bc/index.php(1): require_once('/var/www/Projet...') #2 {main}