Journal Décodage matériel H.264 avec GPU Intel

Posté par  .
Étiquettes : aucune
12
25
juin
2010
Un petit signe de l'état du libre pour décoder de la vidéo HD (le H.264 est le codage le plus utilisé actuellement pour la HD) : le pilote libre pour les puces graphiques Intel intégrées au processeur (i3/i5/i7) a maintenant le code nécessaire à ce décodage.

La page http://intellinuxgraphics.org/h264.html indique tout ce qu'il faut, si quelqu'un a ce genre de processeur je serais curieux de voir si ça permet de consommer moins de Watts...

  • # Ouin

    Posté par  . Évalué à 4.

    Je veux la même chose avec ATI :(

    À noter que tout les i3/i5/i7 n'ont pas cette puce, sinon.

    DLFP >> PCInpact > Numerama >> LinuxFr.org

    • [^] # Re: Ouin

      Posté par  . Évalué à 3.

      A noter que d'après la doc programmeur Intel, les G45 devraient aussi savoir faire ce décodage, mais le pilote ne les gère pas encore. Pour ATI, ça viedra avec Gallium ;-)

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

    • [^] # Re: Ouin

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

      Je viens de changer de PC, j'ai maintenant un i5 avec chipset intégré... Je regrette vraiment très fort mon ATI X1400 :(.

      Que les perfs soient moins bonnes c'est une chose, qu'il y ait quelques bugs graphiques mineurs ok, mais le problème c'est surtout que je peux pas utiliser mon 22" : https://bugs.freedesktop.org/show_bug.cgi?id=28306

      Ça m'a même poussé à aller accepter la licence du Windows pour voir si ça marchait sous windows :(. (et oui, ça marche... et donc j'arrête de faire chier dell pour mon remboursement, c'est devenu inutile)

  • # Mouai...

    Posté par  . Évalué à 2.

    La page http://intellinuxgraphics.org/h264.html n'est pas très à jour...
    Il faut ou les drivers intel 2010Q1 (driver 2.11...) avec libdrm et libva et un kernel 2.6.34 avec les patchs "multiple ring buffer"
    OU
    Les drivers intel 2010Q2 (driver 2.12) avec un kernel 2.6.35 (ou 2.6.34 avec les patchs "multiple ring buffer").

    J'essayerai ça après le boulot mais bon je suis pas persuadé de faire une bonne affaire. Faut voir si sa passe sans bugs. Par expérience avec le vdpau de nvidia, c'est pas encore tout à fait ça (même si c'est un peu plus performant qu'avec le cpu seul).
    La lecture d'un flux h264 en grosse HD n'a pas tant d'impacte que ça sur un core i*. D'autant que plus on charge la carte graphique du core i, moins on peut charger le cpu (avec le "turbo boost" de intel).

    • [^] # Re: Mouai...

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

      Faut voir si ça passe sans bugs.

      S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.

    • [^] # Re: Mouai...

      Posté par  . Évalué à 2.

      Je n’ai pas pu m’empêcher, j’ai installé le noyau 2.6.35-rc3 et le driver xf86-video-intel 2.12. Et je ne suis presque pas déçu.

      J’ai toujours eu des performances assez mauvaises avec mon Intel GM45 pour la lecture de vidéos (pour ceux que ça intéresse, c’est celle là : http://www.intel.com/products/notebook/chipsets/gm45/gm45-ov(...) ). Sur des vidéos HD, en tout petit, ça passait à peu près. En plein écran (1366 x 768), j’avais 3 ou 4 fps. Un peu frustrant quand on a un GMA qui s’appelle 4500MHD.

      J’ai testé avec des vidéos disponibles ici : http://samples.mplayerhq.hu/V-codecs/h264/ . La première testée est hdtv-interlaced/sky_720p_test_why-cant-i-overwrite.ts, avec une surprise presque agréable. En plein écran, c’est presque fluide, avec quelques ralentissements qui ont l’air de venir du décodage du son (aucune idée de la cause précise, mais c’est l’impression que ça donne). Pas mal pour du 720p, mais pas parfait.

      La seconde est HD-h264.ts en 1920 x 1088 (!). Le son (AC3) ne fonctionne pas, je ne dois pas avoir les bons codecs. Par contre, la vidéo est … parfaite. Juste parfaite. Parfaitement, parfaitement fluide, en fenêtré et en plein écran, avec gnome-shell. OMG.

      À suivre, mais c’est drôlement encourageant !

      • [^] # Re: Mouai...

        Posté par  . Évalué à 2.

        Tu peux préciser avec quel lecteur s'il te plaît? En tout cas, merci du test sur GM45, comme ils précisaient GPU i3/i5/i7 j'ai cru qu'il fallait une révision de plus que le G45, et j'ai même pas essayé avec...

        Si c'est mplayer, il suffit de désactiver le son avec -nosound pour t'assurer.

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

        • [^] # Re: Mouai...

          Posté par  . Évalué à 2.

          C’est avec Totem + gstreamer + ffmpeg. Ça m’a vraiment étonné de voir que ça fonctionnait tout simplement, sans que j’ai rien eu à configurer. En même temps je suis sur gentoo, les paquets se compilent souvent avec les bons flags au bon moment. ffmpeg a un flag vaapi qui installe libva, libva a un flag intel, ce qui doit faire toutes les étapes prévues sur la page h264 d’Intel.

          J’ai fait quelques test supplémentaires, dont l’exposé sera purement factuel et non analytique au vu de mes piètres connaissances techniques en décodage vidéo :). Tout d’abord, mon CPU est quand même bien à fond lorsque je lis les vidéos, j’ai un load de 1,7 avec deux cœurs. Ensuite, sur la vidéo la plus grande, totem met 4 ou 5 secondes à galérer au lancement de la vidéo (moins d’une fps), puis part tranquillement sur sa vitesse de croisière.

          Pour la petite vidéo, j’ai testé sans le son avec gst-launch. J’ai les mêmes problèmes qu’avec le son, c’est-à-dire des moments précis (les mêmes à chaque fois) où l’image « saute ». Par contre, la charge CPU est bien plus faible (un peu moins de 1, tout est relatif).

          Je n’ai aucune différence notable entre gnome-shell, metacity avec compositing et metacity sans compositing.

          C’est presque louche… En tout cas, d’où que ça vienne, j’arrive à voir un film en 1080i en plein écran sur mon ordinateur. J’ai tellement eu l’habitude de voir des films en qualité pourrie que je bave devant la vidéo de démonstration (oui, je l’ai regardée en boucle, juste pour trouver les brefs moments où on discerne le fait que la vidéo est compressée, des fois, dans les dégradés de noir, quand on fait pause). H264 fait bien son boulot, même si sapucepalibre.

          Prochaine étape : faire fonctionner l’accélération avec epiphany + youtube + html5, parce que pour l’instant j’ai encore les anciennes perfs (pour des raisons indéterminées, il me semblait que ça utilisait aussi gstreamer pourtant). J’aurai alors un plus grand échantillon de vidéos pour tester tout ça !

          • [^] # Re: Mouai...

            Posté par  . Évalué à 1.

            Juste une petite précision, par rapport à la charge CPU : avec du 720p j’ai environ une charge de 0,9 dont 0,5 de charge pour le décodage (comme Emeric ci-dessous), 0,25 pour X et 0,2 pour le gestionnaire de fenêtres (et les pouillèmes pour le reste).

            Ça paraît énorme pour un truc qui est censé être fait en hard. Mais bon, si ça fait passer mes vidéos de 3 à 25 fps, je suis preneur !

      • [^] # Re: Mouai...

        Posté par  . Évalué à 1.

        Bon j'ai installé le kernel26-rc3, libva patchée pour i965, mplayer-vaapi, les derniers drivers intel, et paf.
        Le coeur cpu qui décode passe de 35% a 50% environ pour lire un h264 720p (entre 5 et 20mbps). Avec post-traitements par contre, soit 10% de plus au décodage.

        Il y a un truc que j'ai sans doute pas fait comme il faut...

        • [^] # Re: Mouai...

          Posté par  . Évalué à 2.

          peut-etre parce que le i965 n'est pas supporté...

          il parlait des chipsets video incorporé dans les processeurs core i3/i5/i7
          pas des chipsets i910/i915/i955/i965

          mais je peux aussi le tromper

          • [^] # Re: Mouai...

            Posté par  . Évalué à 1.

            Oui j'ai bien un core i5 avec un "gma hd" comme ils appellent ça chez intel. Et à ma connaissance cela correspond au i965 dans leur nommage de carte. Enfin c'est vrai que c'est pas clair pour le chipset graphique des core i*.

            En tout cas pour libva, il y a une branche "i965" qui gère vaapi pour les chips intel.

  • # Un défi pour ArchLinux / Fedora

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

    Pendant ce temps je reste tranquillement sur mon Xubuntu temporaire, les bras croisés, avec mon noyau antique. Et puis zut, je suis un utilisateur mouton qui reconnait à Ubuntu des qualités, je ne suis donc pas un bêta-testeur !


    /me prends la fuite

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

Suivre le flux des commentaires

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