Journal Support VA API pour MPlayer

Posté par  .
Étiquettes :
13
24
déc.
2008
VA API est une spécification ouverte visant à exposer les fonctions de décodage vidéo du matériel sous-jacent au développeur. VA API == Video Acceleration API. Les codecs supportés, suivant les implémentations, sont le MPEG-2, MPEG-4 Part-2 (ASP, DivX), MPEG-4 Part-10 (AVC, H.264) et VC-1. VA API expose aussi différents points d'entrée pour le décodage. VLD (Variable Length Decoder) est le plus intéressant car il prend tout en charge. Sinon, il est aussi possible de démarrer à d'autres niveaux comme idct, mocomp, deblocking.

Splitted-Desktop Systems développe plusieurs appareils multimedia et communiquants. Actuellement, j'explore donc les solutions disponibles pour décharger le CPU des tâches de décodage vidéo. Évaluation de performances, en particulier. Vu qu'il n'existait pas de player vidéo accessible facilement pour les plate-formes Intel, j'ai donc décidé de le faire pour MPlayer. Et comme c'est un projet GPL/LGPL, les sources du support de VA API pour MPlayer sont également disponibles.

À noter que VA API est une spécification, il vous faut une implémentation, i.e. le couple driver vidéo et backend pour libva. Pour l'instant, il n'y en a de disponible que pour les MIDs et netbooks (e.g. Dell Inspiron Mini 12) à base de chipset Intel Poulsbo (US15W, GMA500). Notez aussi que certains distributeurs n'ont visiblement pas fait beaucoup d'efforts pour fournir les drivers pré-installés. Je pense en particulier à Ubuntu pour les Dell. Apparemment, selon les infos que j'ai pu trouver sur le net, les MIDs à base de Midinux fournissent l'accélération 3D et le décodage video. Hypothèse de fiction(?): "Comment? Les constructeurs favoriseraient Windows en fournissant des alternatives sous-équipées et sous-fonctionnelles sous Linux?". Je me pose parfois la question en voyant les offres du moment...

Enfin bref, si vous avez une plate-forme avec une implémentation de VA API fonctionnelle, je vous invite à y essayer MPlayer. C'est assez impressionnant. Comme quoi, avec un pauvre CPU comme l'Atom Z et un bon chipset à côté, on peut faire de bonnes choses. Remarquez aussi que cette solution d'Intel a le mérite de tourner sans radiateur, et encore moins de ventilateur.

  • # Super

    Posté par  . Évalué à 2.

    Enfin quelque chose de très interessant, qui va réduire l'utilisation processeur.
    Promis, dès que l'accélération est implémenté dans les pilotes OpenChrome (cf: http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=Hard(...) ), j'essaye sur mon microclient qui est un peu limite avec ses 500MHz. :)

  • # Apport de Gallium3D pour VA API ?

    Posté par  . Évalué à 3.

    J'avais cru comprendre que VA API arriverait surtout avec gallium3D car il suffirait de faire un seul pilote et ça marcherait automatiquement sur toutes les cartes (qui supportent les shaders) grâce à la magie de Gallium3D. Donc finalement c'est juste une incompréhension de ma part ou bien c'est exact mais on peut déjà implémenter ça mais en le faisant indépendamment pour chaque pilote ? J'attend tout ça avec impatience histoire que les API propriétaires qui sont en train d'arriver sur linux ne prennent pas trop d'avance.

    Sinon peut-on trouver une liste des appareils supportés. J'ai un Dell mini 9 mais je ne remettrai la main dessus que début janvier pour voir le chipset, est-ce qu'il est supporté lui aussi ?

    • [^] # Re: Apport de Gallium3D pour VA API ?

      Posté par  (site web personnel) . Évalué à 4.

      Oui et non.
      Oui il est possible de coder un support VA API à coup de shader, mais ca n'a a peu pres rien à voir avec ce qui est fait ici. La plupart des chipsets contiennent d'emblée des options de décompression vidéos, À CÔTÉ de la fonction 3D (valable même chez NVIDIA/ATI qui disent avoir une architecture "unifiée"). Donc oui c'est possible avec les shaders, mais c'est pas la seule manière, et c'est certainement pas la meilleure manière en terme de consommation éléctrique, consommation CPU, performances maximales (entre un truc fait "en soft" et l'autre en cablé, la différence peut être énorme). Sans compter que comme les shaders ne sont pas prévus pour, le transfert de textures entre le CPU et le GPU peut faire des pertes énormes de performances.
      Bref un driver VA API pour Gallium3D oui, mais c'est pas une raison pour se débarasser des autres drivers.

    • [^] # Re: Apport de Gallium3D pour VA API ?

      Posté par  . Évalué à 6.

      Désolé, mais le Dell Mini 9 est basé sur un Atom N et un GMA900 (i945). Aucun des deux ne fournit d'accélération matérielle du décodage vidéo.

      Quant à utiliser des shaders, je crois que ce n'est pas trivial non plus à gérer. De toutes façons, je pense pas qu'une telle approche ait un avenir car la plupart des puces du moment possèdent une unité de décodage vidéo dédiée, i.e. totalement indépendante de la puce 3D. Ainsi, si l'on peut croire Wikipedia (ahem), la partie graphique du Poulsbo est en fait double: un SGX535 (puce 3D), et un VXD370 (puce de décodage vidéo). D'ailleurs, ce ne sont pas des technologies propres à Intel, et c'est pour cela que, je pense, il y aura peu de chances d'avoir des drivers libres.

      • [^] # Re: Apport de Gallium3D pour VA API ?

        Posté par  . Évalué à 3.

        Ah merci pour tous les détails Ph Husson et toi, On peut imaginer qu'un pilote passant par les shaders soit utilisé en cas d'absence de matériel dédié ou de manque de pilote (pas encore implémenté ou spécifications manquantes) ? Une sorte de solution de repli. J'imagine (à tort ?) que ce serait quand même plus efficace que d'utiliser uniquement le CPU ?

  • # Détails supplémentaires

    Posté par  . Évalué à 3.

    Pour les anglophones il y a aussi quelques détails supplémentaires sur phoronix : http://www.phoronix.com/scan.php?page=article&item=xorg_(...)

  • # VA API dans drivers nvidia et AMD?

    Posté par  . Évalué à 2.

    Quand? Prochain siècle?
    AMD devrait dropper son driver proprio et ne faire qu'un driver libre comme fait Intel.
    Quand à nvidia... no comment afin d'éviter des torrents de haine.

    • [^] # Re: VA API dans drivers nvidia et AMD?

      Posté par  . Évalué à 2.

      L'article cité au dessus dit:
      If you happen to have hardware with the Intel Poulsbo and Intel's closed-source driver
      Donc je vois pas trop la différence intel/nvidia coté driver dans ce cas.

      Coté API et performance, voila ou en est la solution nvidia:
      http://www.phoronix.com/scan.php?page=article&item=nvidi(...)

      La différence pour l'instant c'est surtout les matériels visés, à moins que nvidia fasse de l'embarqué basse conso.

    • [^] # Re: VA API dans drivers nvidia et AMD?

      Posté par  . Évalué à 5.

      A priori, sans doute jamais venant d'AMD ou de NVIDIA. L'un et l'autre ayant leurs propres solutions: XvBA et VDPAU. Cependant, dans la mesure où VDPAU fournit un niveau de possibilités supérieur à VA API mais que ce dernier nécessite de détailler davantage les blocs de contrôle, on peut tout à fait imaginer de créer un backend VDPAU pour VA API. Idem pour XvBA. Ca fait un peu solution du pauvre (ne pas taper direct soi même dans le HW), mais au moins, ça permettra de ne conserver qu'une seule API. Parce que bon, 3 APIs ça va 5 minutes pour jouer/tester, mais à maintenir pour un vrai produit, c'est nul...

  • # Commentaire et addons

    Posté par  . Évalué à 3.

    Slt et joyeux noël à tous...;-)


    J'ai posté un lien de ton travail (j'aurais pas dû ?) sur la ML [1] des développeurs de FFmpeg. Peux-tu y jeter un œil et voir les améliorations à apporter suivant les commentaires qui ont été fait ?

    Je vais tester de mon côté...








    [1] : http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-Decemb(...)

  • # Et le bon vieux XVMC dans tout ça ?

    Posté par  . Évalué à 2.

    Auparavant XVMC ne permettait le décodage matériel que pour le MPEG2, mais les CG Intel 965GM et supérieures permettent le XVMC pour le h.264 (ou on m'aurait menti ?). Le support du XVMC pour ces CG a d'ailleurs été ajouté dans la version de développement des drivers Intel, mais pas encore releasé. J'ai testé cette version de dev et effectivement le XVMC est reconnu, et si je ne me suis pas trompé sur ce que j'ai vu, il serai effectivement capable d'accepter du h.264. Le seul hic, c'est que ffmpeg/mplayer et compagnie m'ont aucun codec pour l'exploiter. il ne savent faire du XVMC que pour le MPEG2...:/

    Bref corrigez-moi si je me trompe, mais en tout cas ça serai cool si on pouvait en rester aux bonnes vieilles technos qui fonctionnent déjà, au lieu de réinventer 10 fois la roue. :)

    • [^] # Re: Et le bon vieux XVMC dans tout ça ?

      Posté par  (site web personnel) . Évalué à 5.

      XvMC comme son nom le montre bien ne permet de faire que la Compensation de Mouvement (le MC), qui n'est qu'une partie infime (bon 30% à la louche), du décodage du h264, donc ce n'est PAS réinventer la roue que de sortir VA-API/VDPAU/-le truc ati dont j'ai oublié le nom-. Bon quand même un peu vu qu'ils sont concurrents entre eux, mais pas par rapport à XvMC.
      La réutilisation de XvMC a été étudiée par les créateurs de VA-API et verdict c'est plus compliqué de l'étendre que de refaire une API.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.