Décodage matériel des vidéos avec le pilote libre AMD

Posté par (page perso) . Édité par Lucas Bonnet, Xavier Claude, Nÿco, Benoît Sibaud et patrick_g. Modéré par patrick_g. Licence CC by-sa
Tags : aucun
39
4
avr.
2013
Audiovisuel

L'équipe de développement libre d'AMD publie le code permettant d'utiliser l'accélération matérielle pour lire des vidéos MPEG ou h264 (UVD). Cela devrait augmenter l'autonomie des portables, et permettre de lire des vidéos Full HD avec n'importe quel processeur.

Libre ?

De nouveaux firmwares sont disponibles dédiés à ce décodage, on peut supposer que toute la partie dont la propriété intellectuelle posait problème y a été développée, le code libre ne montrant pas certains secrets industriels. Bien que ces solutions soient courantes, elles ont déjà posé problème, par exemple pour les cartes Wi-Fi Intel, quand l'équipe de développement interne a été dissoute.

Technique

D'après le site Phoronix, cela concerne les cartes graphiques 4xxx à 7xxx, soit l'UVD2. L'annonce sur la liste DRI indique que les cartes 2xxx à 3xxx pourraient être ajoutées dans le futur.

L'accès au matériel se fait par la bibliothèque VDPAU, créée par Nvidia pour son pilote propriétaire. Il est intéressant de noter que ni la librairie VA API - utilisée notamment par Intel, ni la bibliothèque XvBA - utilisée par le pilote propriétaire AMD - n'ont été retenues.

Utiliser

Dans vlc, il suffira de cocher l'option « Utiliser l'accélération matérielle du GPU » dans « Lecture et codecs », mais le gain y est moindre qu'avec mplayer :

mplayer -vo vdpau -vc ffh264vdpau

Quand cela arrivera-t-il dans nos distributions ? Le code est développé en interne chez AMD depuis 2011, on peut donc espérer qu'il soit stable. Cependant, il faudra un noyau Linux 3.10 et Mesa 9.1, donc ce sera pour les distributions de la fin 2013, à moins que vous n'utilisiez une rolling release.

  • # des vidéos au format MPEG ou H264

    Posté par . Évalué à  3 .

    Excellente nouvelle pour l'autonomie et éventuellement la fluidité en cas de multitâche.

    Je suggère de remplacer ce vilain "vidéos encodées en MPEG" par "vidéos compressées en MPEG" ou, mieux, "vidéos au format MPEG" et même "vidéos MPEG" tout simplement.

    Songez qu'on ne parle pas d'image "codée en JPEG", on dit image au format JPEG, image compressée en JPEG, ou tout simplement "image JPEG".

    • [^] # Re: des vidéos au format MPEG ou H264

      Posté par . Évalué à  7 .

      Je ne comprends pas cette histoire d'autonomie, le processeur va travailler moins, mais en contrepartie, la carte graphique va travailler plus. Est-ce que ça veut dire qu'à travail égal, une carte graphique consomme moins qu'un processeur ?

      • [^] # Re: des vidéos au format MPEG ou H264

        Posté par . Évalué à  10 .

        Avec des circuits (asic) spécialisés, le décodage utilise plus efficacement le matériel qu'avec un décodage purement logiciel qui utilise un processeur généraliste.

        Donc oui, la carte graphique est plus efficace que le processeur, mais uniquement pour certains calculs spéciaux, liés à l'affichage et à la vidéo.

      • [^] # Re: des vidéos au format MPEG ou H264

        Posté par (page perso) . Évalué à  4 .

        Est-ce que ça veut dire qu'à travail égal, une carte graphique consomme moins qu'un processeur ?

        Ça dépend du travail.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: des vidéos au format MPEG ou H264

        Posté par . Évalué à  3 .

        khivapia a déjà fort bien répondu, j'ajoute que tu trouveras l'information sur des tests complets, comme on peut en trouver sur AnandTech, où est montrée la consommation d'énergie lors du décodage CPU et lors du décodage par le GPU (qui en effet a directement câblé en lui une bonne partie des opérations de décodage et donc utilise beaucoup moins de transistors pour la même tâche), intégré ou pas.

      • [^] # Re: des vidéos au format MPEG ou H264

        Posté par (page perso) . Évalué à  7 .

        C'est plus compliqué que ça : une CG consomme en général plus qu'elle soit occupée ou pas. Donc le gain de consommation dépend de fait que tu en aies une ou pas.

        • Intel : consommation mesurée égale en lecture CPU ou VAAPI sur un portable (24W )
        • Nvidia proprio : consommation diminuée avec VDPAU, plus avec mplayer qu'avec VLC. Cependant, si j'enlève la carte graphique externe 9600GS et utilise la carte AMD x1150 intégrée à la carte mère, ça consomme autant en lecture 1440x1080i. Mais le Flux HD TNT 1920x1080i lui saccade avec un Athlon 3200+.

        Bref, parfois c'est mieux, parfois pas.

        ⚓ À g'Auch TOUTE! http://agauch.fr

  • # codage

    Posté par (page perso) . Évalué à  2 .

    À noter que les proc Intel Gen6/7, avec VA API, prennent en charge l'encodage aussi. Je ne sais pas ce qui est prévu de ce côté chez amd ?

    • [^] # Re: codage

      Posté par (page perso) . Évalué à  6 .

      Actuellement, les Intel ont plein des bugs (j'ai accès à de Sandy bridge et du Ivybridge) au décodage.
      J'ai des freezes, des bouts d'image verte, des zones qui pixelisent avec un simple flux HD Free ADSL.

      L'encodage matériel n'est pas développé en libre par Intel, mais vu le résultat des tests sous Windows, la qualité obtenue est de toute façon très faible comparé à la librairie libre x264.

      ⚓ À g'Auch TOUTE! http://agauch.fr

      • [^] # Re: codage

        Posté par (page perso) . Évalué à  4 . Dernière modification : le 04/04/13 à 23:24

        L'encodage matériel n'est pas développé en libre par Intel

        Si : pilote libre+VA API

        mais vu le résultat des tests sous Windows, la qualité obtenue est de toute façon très faible comparé à la librairie libre x264.

        Attention l'implémentation Linux n'est pas la même (un mélange de shaders et Quick Sync Video) mais la remarque reste certainement valable

      • [^] # Re: codage

        Posté par . Évalué à  1 .

        Flûte ! Moi qui comptais me monter un ordi à base de intel et hd4000 pour faire un peu de montage vidéo et voire mes vidéos en qualité max, c'est rapé …

  • # VDPAU, VA API, XvBA

    Posté par (page perso) . Évalué à  5 .

    Il serait intéressant de savoir si d'avoir choisi VDPAU est purement fortuit (seule API disponible au début du développement) ou s'il y a une véritable raison (bonne ou mauvaise)…
    Mais ça me semble quand même dommage d'avoir 3 API (une soutenue par chaque constructeur) pour faire la même chose… le choix, c'est parfois bien, parfois non… et là je crois que c'est non.

    • [^] # Re: VDPAU, VA API, XvBA

      Posté par (page perso) . Évalué à  5 .

      Le choix, je pense que c'est lié à l'utilisation VDPAU est, de loin, l'api la plus utilisée par différent lecteurs (pourquoi, je ne sais pas (parce que c'était la première disponible ?)).

      Vu qu'il y a 3 API pour 3 drivers, donc 2 propriétaire, ça n'est compliqué de comprendre pourquoi. C'est seulement maintenant qu'il y a deux drivers libres qui le prennent en charge qu'on pourrait se poser la question de l'unification.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

Suivre le flux des commentaires

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