Hello,
actuellement il n’y a aucune version de GeeXboX 2.0, simplement parce que la prochaine interface graphique (Enna) n’est pas encore assez mature pour être intégrée dans la distribution. Mais ceci dit, rien ne vous empêche de la tester. Cela concerne uniquement les utilisateurs de Linux, et plus particulièrement ceux d’Ubuntu si vous désirez suivre le HOWTO à cette adresse. Je vous conseil d’utiliser le nouveau dépôt Mercurial de Enna à la place du Subversion (obsolète) mentionné dans l’article (hg clone http://hg.geexbox.org/enna).
Enna étant avant tout une interface pour l’utilisateur, le décodage vidéo et audio est transmis à un backend, qui, dans le cas de GeeXboX sera uniquement libplayer. Il est également possible d’utiliser un backend basé sur Emotion mais dont les performances sont bien en-dessous de libplayer/MPlayer. Le fait d’utiliser libplayer permet également d’accéder à xine, GStreamer et VLC pour autant qu’ils soient suffisamment implémentés (actuellement seul MPlayer et xine sont vraiment exploitables).
Le diagramme suivant résume trivialement le fonctionnement, depuis les actions de l’utilisateur jusqu’aux sorties audio/vidéo.
Et Freevo dans tout ça?
En référence à cette news en fin 2006 avec son ISO de démonstration
Aucun développeur de GeeXboX n’étions vraiment intéressé par l’écriture d’un GUI, à part Benjamin Zores qui avait lancé un projet nommé OMC basé sur les EFL pour répondre à ce manque (bien qu’il y ait eu le projet MPUI bien avant). Régulièrement des utilisateurs ouvrent différents postes dans les forums afin de demander un nouveau GUI qui permettrait d’afficher les pochettes par exemple. Ou alors en mettant des copies d’écran de Freevo, MythTV, XBMC ou que sais-je. Tout ceci est bien joli et nous avait finalement conduit sur Freevo.
Un enfer même pour un Paladin bien entrainé... (Diablo II)
Pourquoi Freevo? Et bien parce qu’il est très complet, il peut exploiter MPlayer, il est skinnable, plugable et à pleins d’avantages. La raison était avant tout de nous décharger du travail sur l’interface utilisateur. Ainsi on ne ferait "que" (et j’insiste sur les guillemets) adapter Freevo pour la GeeXboX.
Mais Freevo a un gros inconvénient, et je pèse mes mots.. Etant programmé en Python, la cross-compilation devient un enfer au fur et à mesure qu’on progresse. Il est nécessaire de créer deux fois Python, une fois pour compiler les éléments de Freevo qui sont en Python, et un second pour être intégré dans la distribution afin d’exécuter le code Python. Mais Freevo c’est aussi du code C, et là ou le bas blaisse se sont les dépendances. Il y a par exemple l’utilisation de la GLib (de GTK+) qui était utilisée uniquement pour exploiter les tables de hachage. Il y a d’autres exemples mais ce que je tenais à vous dire se sont quelques raisons qui nous ont forcés à abandonner l’utilisation de Freevo. Leur projet est très actif et en une semaine tout pouvait basculer. Dans le sens où ce n’était plus du tout compilable de notre côté (nouvelles dépendances?) ou alors plus du tout exécutable. Cela prenait tellement de temps à réparer qu’il valait mieux écrire soit même le GUI en C. En toute franchise, j’en avais marre de me battre à le faire fonctionner, quitte à installer une Debian avec Freevo, c’est plus simple et ça marche beaucoup mieux.
la démo de la news (citée plus haut) est en réalité une des rare fois ou Freevo a bien voulu se cross-compiler et s’exécuter à la fois ;-)
Retour au point de départ
L’idée était de réécrire un GUI mais cette fois en SDL (Benjamin Zores et Guillaume Lecerf s’en occupaient principalement). J’ai pris l’initiative d’écrire un wrapper MPlayer pour libplayer pendant cette période. libplayer est resté finalement un des seul projet a avoir survécu depuis le projet OMC et c’est tant mieux. Puis on a abandonné SDL pour revenir sur les EFL et cela s’est terminé par un nouvel échec (sauf pour libplayer) jusqu’au jour où on a découvert le projet Enna.
Ecrit en C il était (est) devenu très intéressant pour GeeXboX. En plus de cela, il est basé sur les EFL. Et il faisait (fait) un candidat parfait pour libplayer sans oublier le point le plus important, son développeur Nicolas Aguirre, qui fait un énorme travail.
A bientôt,
Mathieu SCHROETER
