Quoi de neuf sur les libs

Hello,

maintenant qu’Enna 0.4.0 est dehors et que les paquets sont disponibles, cet article me donne l’occasion de faire un peu la synthèse des modifications apportées à libvalhalla et à libplayer depuis les versions 1.0.0. A noter que la première version d’Enna concerne uniquement les versions 1.0.0, et en aucun cas ce que je liste ci-dessous.

libplayer

Concernant libplayer il n’y a pas grand chose de neuf. La plupart des patchs se rapportent à des fix mineurs dans les scripts et Makefiles. Ainsi que le support (en théorie) de Darwin. Je n’ai pas la moindre idée si la compilation pour MacOS X fonctionne car je n’ai jamais eu de Mac à ma disposition. A part une image émulée d’une Tiger qui n’est pas spécialement rapide à l’utilisation.

Mise à part ça, la modification la plus importante est le remplacement de Xlib par XCB. Xlib a toujours été un problème néanmoins une astuce permettait de le rendre utilisable dans le contexte de libplayer. X11 dans libplayer a deux raisons d’être. Tout d’abord c’est un bon moyen pour créer une fenêtre X pour MPlayer. Cette fenêtre étant entièrement contrôlée par libplayer, cela évite d’avoir des problèmes avec les événements X11 et il est facile de l’embarquer dans Enna. Ensuite cette fenêtre est indispensable pour xine-lib.

Le problème d’Xlib intervient au niveau des threads. Afin de garantir d’être thread-safe il est nécessaire d’appeler la fonction XInitThreads() avant n’importe quel autres fonctions d’Xlib. Ou alors, il faut gérer les locks sur les appels Xlib sois-même. J’ai donc opté pour la deuxième solution (dans le cas de libplayer-1.0.0). Des mécanismes dans xine-lib permettent d’appeler les locks créés par libplayer. Mais il y a un point à soulever. Selon les dires des développeurs de xine, ces mécanismes ne sont pas exempt de bugs.
Et l’utilisation d’XInitThreads() est impossible dans le cas de libplayer. La raison est très simple. Étant donné que ce doit être la première fonction à appeler, il faudrait être sûr que par exemple avec Evas, Qt ou GTK (si libplayer serait utilisé dans une application qui en dépend tel qu’Enna avec Evas), que libplayer soit initialisé avant ces libs. Ou alors qu’Evas fasse lui même un XInitThreads(). Ou encore que celui qui développe le GUI (tel qu’Enna) fasse un XInitThreads() dans son main() (avant toutes les autres initialisations). Et donc l’utilisation d’une telle bibliothèque deviendrait très contraignante.

La solution c’est XCB. Il n’y a aucun besoin d’initialiser quoi que se sois pour les threads contrairement à Xlib. XCB peut donc être utilisé de manière sûre dans libplayer et sans fournir de locks supplémentaires. C’est sur XCB que les développeurs de xine se tournent également. Car il y a au moins les sorties video Xshm et Xv qui sont portées pour XCB.

La prochaine release de libplayer utilisera donc XCB. Pour être plus précis, le fait d’utiliser XCB dans libplayer n’empêche pas d’utiliser Xlib pour un wrapper de libplayer, pour autant que les mécanismes pour garantir le thread-safe soient implémentés.

VDPAU

NVidia fait des efforts pour Linux depuis longtemps. VDPAU en est un exemple parmi d’autres. Mais tout ceci reste qu’en même du code fermé avec tous les désavantages qui en découlent. Dans le cas de libplayer, il est aujourd’hui impossible de supporter VDPAU avec xine. Non pas que xine ne peut pas l’utiliser, mais plutôt que xine est obligé de passer par Xlib pour pouvoir l’exploiter.

On pourrait croire alors que je n’aurais pas du changer Xlib pour XCB dans libplayer, mais en réalité ça n’a strictement rien à voir. Le problème est au niveau de VDPAU. Celui-ci étant basé sur Xlib, il est nécessaire d’avoir l’initialisation des locks. Le seul moyen actuel est de devoir faire appel à XInitThreads(). Ainsi xine refuse de charger VDPAU dans les seuls cas thread-safe tel que XCB ou la variante Xlib (soit disant “buggée” qui fonctionne qu’en même bien par rapport à ce que libplayet-1.0.0 en fait).

Pour être honnête, il y a un moyen mais c’est un hack. En ajoutant un XInitThreads() dans Enna avant l’initialisation d’Evas ainsi qu’une modification dans le wrapper xine de libplayer pour lui dire qu’il doit travailler avec Xlib.

Tout ceci ne concerne pas le wrapper MPlayer, qui peut parfaitement utiliser VDPAU pour la sortie vidéo comme pour les codecs, étant donné que c’est un processus “forké”.

libvalhalla

C’est sur cette bibliothèque où j’ai le plus travaillé depuis la 1.0.0. Mise à part des correctifs sur les scripts et Makefiles comme pour libplayer et Darwin, il y a aussi de nouvelles fonctionnalités.

API

Tout d’abord l’API publique est maintenant plus facile à étendre sans la casser à l’ajout de nouveaux paramètres à l’initialisation par exemple. J’ai également factorisé toutes les fonctions qui permettent de configurer libvalhalla en une seule fonction variadique.

Statistiques

Avec libvalhalla-1.0.0 il y a déjà quelques statistiques. Par exemple les résultats et les temps utilisés par les grabbers, ou encore un résumé des actions qui ont été faites sur la base de donnée. Néanmoins ces informations ne sont pas disponibles depuis l’API. Ce qui change dans le prochain libvalhalla c’est que toute les statistiques de ce type sont récupérables facilement. Il y en a également plus qu’avant. Je dois encore en ajouter sur certaines parties tel que le scanner. Mais les ajouts n’affecteront en rien l’API publique.

Dans le cas d’Enna ça pourra être utilisé pour montrer (pour le fun) l’état des différentes parties de libvalhalla dans une fenêtre d’information. Les statistiques peuvent être interrogées à n’importe quel instant, ce qui permet de suivre l’évolution.

Événements globaux

Il est possible d’avoir des événements globaux comme par exemple une information qui prévient que tous les fichiers  (pour une passe complète du scanner) ont été traités. Il n’y a pas beaucoup d’événements pour l’instant. Ils ne sont pas des plus utiles, mais dans le cas d’Enna il permettront d’avoir une notification. Il est également facile d’en ajouter des nouveaux.

Metadata callback

C’est un callback qui a été ajouté suite à une proposition d’un tiers pour une demande assez spécifique. Le but est de pouvoir récupérer depuis l’API publique toutes les metadata en même temps qu’elles sont récupérées par les parsers et grabbers. C’est donc un moyen d’avoir accès aux données sans passer par la base de donnée. Je ne recommande pas son utilisation pour plusieurs raisons. Tout d’abord si le callback est bloqué relativement longtemps pour chaque metadata, l’utilisation mémoire va augmenter en fonction (le blocage du callback ne bloque pas le reste de la bibliothèque). Il faut absolument veiller à traiter les données aussi vite que possible. La deuxième raison est que SQLite est beaucoup plus performant pour rendre toutes les metadata. Les fonctions de sélections sont relativement haut-niveaux et permettent de récupérer les informations de manière efficaces et ordonnée. Une de ces fonctions a également été un peu améliorée dans le cadre des modifications depuis la version 1.0.0.

J’ai qu’en même rajouté la fonctionnalité dans la bibliothèque car elle n’est pas intrusive et ne peut pas introduire des régressions ou des ralentissements.

Grabbers parallélisés

C’est la plus grosse nouveauté pour la prochaine release. Dans le cas de libvalhalla-1.0.0, beaucoup d’éléments travaillent en parallèle, à l’exception des grabbers (entre eux). Il est possible maintenant d’avoir “autant” de grabbers que l’on veut simultanément. Cette fonctionnalité permet d’économiser environ 30% du temps selon mes essais. L’intérêt est également que les fichiers vidéos ne sont plus bloqués sur les grabbers dédiés à l’audio et inversement. Par exemple le grabber LyricWiki qui est spécialement lent, était un vrai goulot d’étranglement pour les fichiers vidéos (aussi pour les autres fichier audio, ce qui est implicite). La parallélisation permet à ces fichiers (non-audio) de se terminer indépendamment de ce grabber (et des autres).

J’ai mis la limite maximum à 16 grabbers en parallèle (ce qui est plus que le nombre de grabbers différents qui existent). Un choix efficace et d’opter pour 3 ou 4. L’utilisation de la RAM n’est pas spécialement affectée car la plupart utilisent des services web qui sont plutôt gourmand en temps.

Il y a deux autres effets à noter:

  • Les priorités ne sont plus complètement respectées si on défini plus d’un grabber à la configuration. Ce qui veut dire que par exemple un fichier peut être envoyé dans un grabber qui devrait (selon les priorités) être interrogé dans les derniers. Il est donc possible de continuer à travailler comme libvalhalla-1.0.0 en forçant explicitement le nombre à 1.
  • Le second effet est lié au ondemand. Celui-ci est plus rapide car il y a plusieurs threads de grabbers et donc il peut rapidement avoir toutes ces demandes sur tous les threads (à cause des priorités du ondemand).

Le fonctionnement en quelques mots

La parallélisation des grabbers n’est pas comparable à celle des parsers. Lorsqu’un fichier doit être traité par un parser, il attend simplement dans la queue jusqu’à ce qu’un parser le POP et le traite vraiment. Il n’y a pas de raison de faire autrement car tous les parsers font le même travail. Les grabbers sont différents car chacun d’eux fait un travail spécifique. Ainsi lorsqu’un fichier se retrouve dans la queue et qu’un thread de grabber le POP, il va chercher un grabber de libre. Le cas échéant il renvoi le fichier dans la queue et réessaye avec le suivant. Il n’y a donc jamais de longue attente, ce qui permet de bien enchaîner tous les fichiers.

Il y a aussi quelques conditions. Un même fichier n’est jamais parallélisé entre les différents threads des grabbers.  Et un même grabber travail que dans un seul thread à la fois. Ce qui veut dire par exemple, que s’il y a 10 threads; pour que les 10 soient actifs il faut au moins 10 grabbers différents (FFmpeg, LyricWiki, Amazon, etc,…), et 10 fichiers différents.

Il est ainsi évident que d’avoir beaucoup de threads n’apportent absolument plus rien au delà d’une certaine limite que j’estime à environ 4. Mais ceci dépend fortement des types de fichiers différents, des types de grabbers compilés et leur nombre.

Bonne année,

Mathieu SCHROETER

4 thoughts on “Quoi de neuf sur les libs

  1. Bonjour,
    Je suis votre projet depuis quelques temps et je voulais vous féliciter pour tout ce travail accompli. Certes Enna est jeune et s’améliore tous les jours mais c’est très prometteur. Il est bcp plus léger que xbmc (un media center n’est pas souvent une bête de course).

    J’utilise E17 depuis des années comme WM principal et j’apprécie particulièrement que vous basiez sur ses bibliothèques très efficaces (même sans accélération graphique par exemple).

    Pour information, j’ai installé la version 0.4 via les PKGBUILD d’Archlinux dans le dépôt AUR et j’attend avec impatience la prochaine version.

  2. Hello et merci,

    les comparaisons avec XBMC sont très courantes, ce qui est légitime je suppose. XBMC ont une bien plus large main-d’œuvres que nous et leur produit est devenu très intéressant. D’ailleurs on s’inspire aussi de ce qu’ils font.

    Concernant le fait qu’un media center soit léger ou lourd c’est une question un peu plus délicate. Avant tout il faut savoir ce que l’on désire vraiment. Un environnement beau mais forcément plus gourmand ou quelque chose de plus austère (tel que les GeeXBoX 1.x) mais nettement plus léger.

    Alors on fait des compromis (pour GeeXboX 2.x). Mais en même temps le HD est synonyme de grosses ressources et alors on peut se permettre un peu plus de fantaisies (je lis souvent des choses tel que “faites votre media center en recyclant un vieux PC avec GeeXboX”; c’est flatteur mais c’est un peu le monde qui tourne à l’envers.. le multimédia est tout sauf pensé pour les petites configs).
    Avec Enna les EFL apportent tout ce qui est graphique mise à part une partie importante. C’est le support de la vidéo qui devrait se faire à travers Emotion (pour un puriste).
    Alors on ne fait pas du 100% EFL et on se détache aussi d’XBMC sur ce point; qui est le rendu vidéo. Même si tu utilises Enna avec l’engine OpenGL, le rendu ne se fait pas à travers OpenGL (et donc pas à travers les EFL). Ce qui permet de conserver les accélérations vidéos (je ne parle pas des accélérations au décodage) tel que Xv, XvMC, VDPAU, etc,..
    C’est à mon avis principalement à ce niveau que la différence se situe. Pour le reste on a encore beaucoup moins de fonctionnalités que les autres. Enna à encore le temps de prendre un peu d’embonpoint :-).

    EDIT: j’ai jeté un œil rapide chez ArchLinux http://aur.archlinux.org/packages.php?ID=33427&O=&L=&C=&K=&SB=&SO=&PP=&do_Orphans=&SeB= et a priori, au vue des dépendances sur libvalhalla.. il manque une craquée de grabbers.

    1. Bonjour et merci pour ta réponse.
      En fait, en ce moment je teste Enna sur mon vieux desktop (Athlon 3000+, Nvidia NV36, 512 Mo Ram) en attendant de récupérer un autre PC un peu plus puissant et joli que je mettrai dans mon salon. La puissance n’est pas un soucis dans mon cas mais je suis partisan du “c’est pas parce qu’on a les ressources qu’il faut les gaspiller”, d’où mon attachement à Enlightenment.
      Sinon j’ai vu que beaucoup de travail était en cours sur la libvalhalla et je m’en réjouis. En effet, parfois il y a des résultats un peu cocasses comme la pochette de Pulp Fiction pour l’album Fiction de Dark tranquillity mais je ne doute pas que ces “défauts” ne sont que passager. C’est déjà super impressionnant.

      Sinon, je vais essayer de faire marcher une télécommande PC:
      http://www.amazon.fr/TARGUS-Stow-N-Go-T%C3%A9l%C3%A9commande-ordinateur-portable/dp/B000N4JC2U
      avec des scripts comme mplayer en mode slave ne la reconnaît plus (et c’est logique).

      J’ai hâte de pouvoir parcourir mes films comme je le fais pour la musique (recherche par tags). Et je rêve d’une intégration de youtube (à long terme j’ai vu) et pourquoi pas d’une intégration avec un gestionnaire de collection (tellico, GCStar). Malheureusement je ne suis pas développeur et je n’ai pas les compétences pour vous aider mais je soumettrai des rapports de bugs et des demandes de fonctionnalités si ça peut vous aider dans votre travail.

      Bonne continuation et je ne doute pas que vous aurez beaucoup de succès, surtout avec la sortie de geekbox 2.0 pour les novices. Ne tenez pas comptes de certains aigris de Linuxfr.

    2. Pour libvalhalla je suis aujourd’hui même en train de travailler sur les priorités des metadata. Donc de pouvoir pousser devant les résultats des grabbers qui sont plus fiables. Après faut être clair. La qualité des résultats dépend principalement de la qualité des metadata “title”, “author”, “artist” et “album” dans tes fichiers. Et dans les cas où “title” n’existe pas et qu’un grabber en à besoin, alors c’est le decrapifier qui fait le job et faut donc veiller à avoir des noms de fichier pas trop sales. Mais faut être clair, c’est pas magique et tout ne peut pas être nettoyé parfaitement.
      Néanmoins la venue des priorités devraient mettre un peu plus d’ordre.

      Concernant les télécommandes, si ça passe avec Lirc alors c’est tout bon (sinon faut passer par irrecord). Et ensuite il suffit donc de faire un lircrc correcte.

      Pour la fonctionnalité de parcourir les films ça viendra.. j’espère avec Enna 0.5.0. De même pour les photos via les Exif. Vu qu’en pratique libvalhalla s’occupe également des photos, mais c’est non utilisés dans Enna 0.4.0. Et en fait ça demande de faire des gros changements dans le module valhalla.

      Mais les plus gros points noirs sont invisibles pour les utilisateurs. Il y a quelques zones sombres à réécrire complètement. Bref on est pas encore sorti de l’auberge :-)

      Et merci pour tes encouragements.. Concernant les aigris de Linuxfr pas de soucis, les critiques faciles importent peu. Si ces gens là nous payaient pour faire le job, ce serait différent, mais ici on a de compte à rendre à personne.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s