Avec l'apparition du Raspberry Pi et de son GPU Broadcom VideoCore IV intégré, les logiciels de "media center", c'est à dire les systèmes permettant de connecter directement un PC à une télévision pour exploiter sa bibliothèque vidéo, se sont rapidement intéressés à ce nouvel OVNI technologique. Ainsi plusieurs distributions Linux orientés "media center" ont vus le jour pour nous permettre et permettent, pour moins de 30€, de disposer d'un système intégré pour lire des vidéos HD téléchargés plus ou moins légalement sur le Internet.

Nous allons dans ce billet nous intéresser à l'une d'entre elle: OpenElec (Open Embedded Linux Entertainment Center) qui dispose d'un bonne notoriété sur les réseaux sociaux, notamment grâce à une interface de navigation fluide et à une documentation bien fournie (notamment leur Wiki). Il faut juste garder en tête que toutes ces distributions "media center" se base sur le même noyau composé de Raspbian (le système d'exploitation Debian adapté au Raspberry Pi) et XBMC pour le logiciel.

Installation d'OpenElec

Pour installer OpenElec, les auteurs du projet ont eu la bonne idée de créer un script qui va partitionner et graver la dernière version du système (3.0.1 au moment de l'écriture de cet article) sur une carte SD que vous n'aurez plus qu'à insérer dans votre Raspberry Pi.

Voici les lignes de commandes à saisir sur votre machine GNU/Linux pour installer la version 3.0.1 d'OpenElec sur une carte SD disponible via l'identifiant système /dev/sdb (c'est bien sûr à contrôler avec la commande "fdisk -l" pour être sûr que /dev/sdb correspond bien à votre carte SD histoire de ne pas effacer un autre disque dur):

wget -O OpenELEC-RPi.arm-3.0.1.tar.bz2 http://openelec.tv/get-openelec/download/finish/10-raspberry-pi-builds/87-openelec-stable-raspberry-pi-arm
bzip2 -d OpenELEC-RPi.arm-3.0.1.tar.bz2
tar xvf OpenELEC-RPi.arm-3.0.1.tar
cd OpenELEC-RPi.arm-3.0.1/
sudo ./create_sdcard /dev/sdb

Installation de votre Raspberry Pi

Voici la configuration que j'ai utilisé pour le test:

• Un téléviseur Samsung UE46B6000 (pour une description de mon système home cinéma avant l'arrivée de mon Raspberry, cliquez ici !)
• Un Raspberry Pi model B (j'ai ensuite utilisé un model A)
• Une carte SD 4 Go (mais une de 2 Go suffit) avec OpenELec 3.0.1 (voir le premier paragraphe pour l'installation)
• Un disque dur USB contenant mes vidéos (attention de bien alimenter le disque par une source externe car le Raspberry Pi n'y arrive pas).
• Un câble HDMI pour la liaison numérique avec le téléviseur (vidéo, son et télécommande avec la norme HDMI CEC).
• Une souris pour manipuler l'interface d'OpenElec ou mieux encore votre télécommande si votre téléviseur est compatible avec la norme HDMI CEC (comme c'est le cas pour mon téléviseur Samsung via l'implémentation de la fonction Anynet+)
• Un câble réseau (pour l'accès distant et l'accès au NAS) (optionnel et seulement pour le model B)

Après branchement, le système devrait démarrer automatiquement et l'interface va apparaître sur votre téléviseur. Si vous avez un modèle B, l'accés en SSH (l'adresse IP de votre Raspberry Pi est donnée dans le menu configuration) se fait à l'aide de l'utilisateur root et du mot de passe openelec.

Test de la bête

J'ai d'abord testé OpenElec avec un Raspberry Pi model B puis quand j'ai reçu mon model A j'ai basculé vers ce boîtier car je n'utilise pas mon NAS pour stocker mes films mais un simple disque dur portable connecté directement au Raspberry Pi.

Le démarrage du système est assez rapide (entre 1 minute et 1 minute 30), on arrive directement sur l'interface XMBC customisée à la sauce OpenElec. La navigation dans les différents menus se fait de manière relativement fluide. Le "relativement" n'est pas vraiment un problème quand comme moi vous utilisez une télécommande. Par contre on ressent une certaine difficulté du Raspberry Pi à suivre le rythme quand on utilise une souris. A noter que l'utilisation direct de la télécommande est assez blufante, une vraie bonne idée cette norme HDMI CEC.

Sur ma configuration, je n'ai presque pas eu de configuration à faire mis à part un calibrage de l'écran. En effet, je perdais des petites bandes d'image sur les cotés. Le plus simple pour faire cela est de lire un film et de cliquer sur le bouton "Vidéos - Paramétrage" puis "Étalonnage de l'écran". Vous aurez alors droit à un wizard qui va vous permettre de bien redimensionner la vidéo par rapport à votre télévision.

On peut ensuite passer au test de lecture vidéo qui est l'objectif principal de notre boîtier.  Pour cela j'ai fait tourner pendant une journée entière OpenElec en lecture d'un rip HD Xvid 720p de "The art of flying" qui avec ses traveling n'est pas une vidéo facile à décoder.

Le résultat est très concluant, aucune saccade constatée de la vidéo lors de la lecture (mais bon je suis pas non plus resté toutes la journée devant l'écran ). Le son 5.1, récupéré directement via la liaison HDMI, est bon. J'ai également fait des tests avec des trailers en HD 1080p et il n'y a également aucun problème de lecture. Le GPU fait vraiment bien son boulot.

Le Raspberry Pi ne chauffe presque pas (j'ai mis la carte dans un boîtier transparent que l'on peut trouver pour quelques € pour que la carte ne prenne pas la poussière et pour éviter que mes enfants mettent les doigts dessus, c'est curieux ces bêtes là...).

A noter qu'avant la rédaction de ce billet, j'avais demandé à mon copain Twitter des retours d'expériences sur les "media center" du Raspberry PI. De nombreux followers m'avaient signalés qu'il avait des problèmes de lags lors de la lecture de vidéo HD 1080p sur OpenElec. Je n'ai pas constaté de problème sur ma configuration et je pense que leurs problèmes viennent du fait qu'il utilise des vidéos stockées sur un NAS. Il faut donc regarder du coté du réseau et notamment si vous utilisez un dongle Wifi sur votre Raspberry Pi.

Problème d'avance et de retour rapide

Lors des tests, j'ai constaté un problème au niveau de l'avance et du retour rapide lors de la lecture des vidéos. C'est un problème connu au niveau de XBMC.

Il existe heureusement une solution de contournement qui consiste à remplacer le "fast forward" (& rewind) par le "step forward" (& rewind). Pour cela, il faut éditer le fichier remote.xml (à chercher sur votre configuration via la commande "find / -name remote.xml"), puis à éditer la section FullscreenVideo:

    
      
      Stop
      StepBack
      StepForward
    
  

Le pas par défaut est de 30 secondes, pour le changer il faut éditer un autre fichier nommé advancedsettings.xml qui est à créer pour l'occasion (cliquer ici pour voir comment créer ce fichier selon la documentation de XBMC) puis à l'éditer avec le contenu suivant:

Conclusion

Le Raspberry Pi est vraiment un joujou surprenant par ses capacités à faire des choses habituellement réservées à du matériel beaucoup plus cher. Avec les solutions intégrées comme OpenElec, on n'a même plus la complexité de configuration et ces solutions de "media center" deviennent à la porté de n'importe quel bidouilleur.

... pour faire la fine bouche

Il manque encore le support du HDMI Ethernet Channel qui permettrait au Raspberry d'utiliser via le câble HDMI la liaison Internet de la télé. C'est prévue dans la norme HDMI 1.4 mais pas implémenté dans les modèles actuels du Raspberry Pi (voir la page suivante pour les explications).

---

Allez, à vos claviers, parlez moi de votre configuration "media center". Utilisez-vous OpenElec ou bien une autre distribution ? Si oui pourquoi ?

---

Cet article Test d’OpenElec sur Raspberry Pi est apparu en premier sur Le blog de NicoLargo.

Original post of Nicolargo.Votez pour ce billet sur Planet Libre.

Introduction

Pendant un moment j'utilisais mutt puis j'avais arrêté, je m'étais laissé séduire par une interface dont je vais taire le nom. Finalement, je reviens à mutt c'est vraiment ce qui se fait de mieux. Je pense que l'une des raisons à la base de mon changement était du au fait que je ne l'avais pas spécialement configuré correctement cette fois-ci j'ai pris le temps et je vais certainement continuer à ajouter des choses, je vais d'ailleurs faire je pense une série d'article sur ma configuration, les différents outil que j'utilise avec, et les raisons de mon retour sur mutt.

Goobook

Il est pratique de pouvoir avoir sa liste de contact et pouvoir bénéficier de completion lors de l'écriture de mail. Goobook est un petit projet développé en Python et disponible sur pypi. Il permet d'accèder à sa liste de contacts google en ligne de commande, il est donc possible facilement de l'intégrer et l'utiliser avec mutt. Il permet aussi d'ajouter de nouveaux contacts.

Installation

Le projet est disponible sur pypi, il suffit donc d'utiliser pip:

sudo pip install goobook

Pour le coup je l'installe sur le système et pas dans un virtualenv, c'est pour cette raison que j'utilise la commande sudo.

Configuration

Il y a un petit fichier de configuration pour indiquer notamment son adresse et mot de passe:

[DEFAULT]
email: user@gmail_or_your_domain.com
password: mot_de_passe
cache_filename: $HOME/.goobook_cache
cache_expiry_hours: 2400

Insérer ces lignes dans le fichier $HOME/.goobookrc.

Utilisation en ligne de commande

La commande reload permet de mettre à jour le cache goobook et récupérer sa liste de contact google:

goobook reload

Pour chercher un contact il faut utiliser la commande query:

goobook query nom

Il est aussi possible d'ajouter un contact:

goobook add "nom prénom" adresse@nom_de_domaine.com

Utilisation dans mutt

L'intérêt maintenant c'est de l'utiliser avec mutt, pour chercher un contact il faut ajouter ceci dans le fichier muttrc:

set query_command="goobook query '%s'"
bind editor  complete-query

Maintenant lors de l'envoi d'un mail, il est possible d'utiliser la tabulation pour completer l'adresse mail.

Il est aussi possible d'ajouter un contact:

macro index,pager a "goobook add" "add the sender address to Google contacts"

Sur la liste de mail, placer le curseur sur un mail et appuyer sur a pour ajouter l'adresse aux contacts google.

Problème avec certaines adresse

Lorsque j'ai commencé à utiliser goobook, j'ai eu un problème. Certaines adresses étaient bien dans le cache goobook, mais je n'arrivais pas à les avoir avec la commande query par exemple. Google a ajouté une notion de tri pour les adresses mail, fonctionnalités que je n'utilise pas. Les contacts se trouvant dans Autres contacts1 tant-donné qu'ils ne sont pas triés ne sont pas accessible. Pour résoudre le problème il faut trier les contacts pour ma part j'ajoute tout dans Mes contacts2. Merci à marcel3 pour son article qui m'a permis de résoudre mon problème.

Conclusion

Un outil vraiment pratique qui me manquer dans mutt, c'est pratique d'avoir la complétion de ses conctats.

Original post of Hobbestigrou.Votez pour ce billet sur Planet Libre.

Cette semaine, deux mockups ont retenus mon attention. Le premier, déniché sur Google+, est le mockup d’une calculette. Très coloré mais pas forcement laid, voilà un mockup qui pourrait inciter un développeur à reprendre le projet pantheon-calculator qui sait…

 

Quand DanRabbit imagine ce que à quoi Scratch (l’éditeur de texte d’ElementrayOS) avec ses extensions pourrait ressembler, cela donne cela et ça a de la gueule !

 

À la prochaine !

Original post of Devil505.Votez pour ce billet sur Planet Libre.

Récemment, je me suis acheté un mini-clavier pour contrôller le futur XBMC de mon RaspberryPi... J'ai pris le iClever RII en version Bluetooth, parce que je le vaut bien

Pour l'utiliser, rien de bien compliqué, on installe 3 paquets, on associe le clavier au Raspberry, et le tour est joué !

Allez, installons les paquets suivants via apt :

apt-get install bluetooth bluez-utils blueman

Cela étant fait, on branche notre dongle Bluetooth (fourni avec le mini-clavier), et on vérifie qu'il est bien là :

pi@raspberrypi ~ $ lsusb
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 005: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Ce qui nous intéresse ici est la dernière ligne. Nous pouvons passer à l'étape suivante !

Appuyez maintenant sur la touche "Bluetooth" de votre clavier. Elle se trouve en haut à gauche. Maintenant, on essaye de trouver notre clavier :

hcitool scan

Si votre clavier s'affiche, notez bien son adresse MAC (ex AC:4F:48:78:A2:B3).

Maintenant, nous allons associer notre clavier au Raspberry Pi. La commande suivante va vous demander de saisir un code PIN. Saisissez "0000" puis entrée. Saissez ce même code sur votre clavier (à l'aveugle), puis entrée.

bluez-simple-agent hci0 AC:4F:48:78:A2:B3

Normalement, ça doit être bon. Il ne nous reste plus qu'à valider définitivement notre clavier via les 2 commandes suivantes :

bluez-test-device trusted AC:4F:48:78:A2:B3 yes
bluez-test-input connect AC:4F:48:78:A2:B3

Testez, votre clavier est maintenant fonctionnel. Bonne utilisation !

Original post of Jeoffrey Bauvin.Votez pour ce billet sur Planet Libre.

De retour de vacances et après une semaine chargée (le temps de tout remettre en ordre, c’était la jungle chez moi!!!), il est temps pour moi de faire un bilan de la 1ere campagne KickStarter du projet Openshot. J’en profite aussi pour faire un 1er point d’informations sur le début du travail qui a commencé entre temps. Mais avant de commencer cette campagne, nous n’imaginions pas du tout obtenir un tel succès, ce qui nous conforte aussi dans tout le travail effectué mais aussi dans l’espoir qu’apporte la nouvelle version de ce projet et dont les objectifs sont très attendues par la communauté des amoureux de la vidéo. Un grand merci aux 1463 donneurs qui ont permis de récolter la somme inattendue mais incroyable de 45 028 $US. Et un grand merci à toutes celles et tout ceux qui ont diffusé la nouvelle dans toutes les communautés. Merci à vous de croire en ce projet autant que nous y croyons nous-même.

Les donateurs

Les donateurs (pour un montant supérieur ou égal à 25$) vont recevoir un sondage qui collectera les informations de bases (email adresse, taille du T-Shirt, …..)  nécessaires pour l’envoie de leur « cadeaux » (enfin bref, ceux qui ont droit). Ensuite des certificats de contributions signés par Jonathan seront ensuite envoyés. Plus vite, vous répondrez, plus vite nous pourrons commencer la nouvelle version.

Parmi tous ces donateurs, MediaCollege est le plus important avec une promesse de  don de 1500 $US. Si comme moi, vous ne connaissiez pas ce site, il propose des centaines de tutoriels dans les domaines de l’audio, de la production vidéo et télévisuelle, la photographie, le graphisme, le design web, internet et plus……. Vraiment très intéressant ce site.

D’ailleurs voici un aperçu de ce qui est proposé sur OpenShot.

A ce jour, Jonathan attends encore le transfert des fonds de KickStarter afin de pouvoir commencer à acheter tous les « cadeaux »pour les contributeurs qui y ont droit.

Le plan de développement

Nous publierons prochainement sur le blog officiel (que je communiquerai aussi pour la communauté francophone) un plan de développement comprenant un calendrier pour les dates clés et les milestones envisagées. Bien que l’ajout des 5 nouveaux objectifs  (et de leur succès!) a chamboulé notre plan initial, nous comptons toujours réaliser celle-ci pour Décembre.  Pour les plus curieux d’entre vous, Jonathan essaiera, dans la mesure du possible, de publier un calendrier détaillé avec les MAJ quotidienne (dans la mesure du possible). Nous mettons un point d’honneur à tenir le plus informé notre communauté dans son ensemble (donateurs bien entendu mais aussi simple utilisateurs) des progrès et des difficultés que nous traverserons jusqu’à la réalisation de la version 2.0.0.

D’ailleurs, voici une nouvelle qui va en surprendre plus d’un, lié à des difficultés que nous avons avec  GTK3. Nous avons pris l’une de nos plus grandes décisions à ce jour pour le projet : le passage de GTK à QT. Nous (l’équipe d’Openshot bien entendu!) avons étudié consciencieusement toutes les options s’offrant à nous et nous pensons qu’il s’agit de la meilleur solution. Vous vous doutez bien que nous avons mûrement réfléchi car cela entraîne avec le nouveau framework (i.e libopenshot) et la nouvelle timeline (utilisant HTML5, CSS3 et Javascript) et maintenant QT une refonte totale du projet. Un des facteurs majeur qui a entraîne ce choix est la très grande qualité de ses widgets pour l’utilisation avec HTLM et Javascript (pour notre timeline et le widget pour  les courbes), pour son très bon support multi-plateforme (Linux, Mac OSX et Windows), pour  une facilité d’utilisation d’OpenCL (qui affichera notre prévisualisateur de vidéo). Cela nous permettra aussi d’envisager et d’explorer des possibilités auquel nous ne pouvions répondre jusqu’à présent (exp: avoir des fenêtres détaches à volonté). Il est vrai que l’on y pense. Mais rien n’est moins sur pour l’instant et surtout pour la version en question (i.e la 2.0.0) avec un travail énorme et 7 mois pour y parvenir. Mais qui sait, plus tard………. au moins tout sera en place pour ……………..le bon moment. En faisant ces choix, nous mettons pas mal de choses en place pour maintenant et surtout pour plus tard.

Le passage à QT 5.0 va nous permettre aussi de simplifier le code. Nous enlèverons des centaines de lignes de codes lié à GTK désormais inutiles et qui seront remplacées soit par du Javascript soit par une API plus simple. Cela diminuera la complexité du code du projet et donc améliorera aussi à sa stabilité. Eh oui, même si nous faisons de grands bouleversements, les mots d’ordre du projet sont toujours les même, à savoir Stabilité, Simplicité d’installation et d’utilisation et Performance de tout ordre.

Une précision s’impose pour les non-initiés. Le fait de passer de GTK à QT est juste un changement de toolkit pour  créer les interfaces (vous savez vos belles fenêtres) mais cela ne signifie pas que nous  quittons des environnements GTK (Gnome3, Unity, XFCE, LXDE) à KDE. Il n’en n’est rien. Il n’y a pas de corrélation/d’obligation d’utiliser KDE pour utiliser QT. QT s’installe partout y compris sur vos téléphones.  D’ailleurs, en parlant de QT, le développeur principal de l’environnement ultra léger LXDE Hong Jen Hey développé en GTK2 a exploré avec un certain succès le passage à QT comme le confirme ce post en français mais aussi sur le blog officiel. Les deux branches vont coexister pour l’instant.

D’ailleurs, une très belle vidéo démontrant les fonctionnalités de QT 5.0.

Et maintenant ?

Nous nous réunirons dans la semaine afin de discuter de tous ça entre nous et de prendre les décisions finales pour le plan de développement final. Bien entendu, nous vous tiendrons au courant dès que possible notament sur les plans au niveau de l’accélération Hardware, l’édition distribuée (avec le serveur), des prototypes et MAJ ainsi que des améliorations de notre interface. Stay tuned.

Classé dans:Edition Vidéo, framework, Logiciels, Multimédia, News, OpenShot, Planet-Libre Tagged: Hardware, Libopenshot, Multimédia, News Logiciels, OpenShot, QT

Original post of Cenwen.Votez pour ce billet sur Planet Libre.