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.
Aller plus loin
- L'annonce sur le site Phoronix (267 clics)
- Le code qui débarque dans Mesa (157 clics)
- L'annonce sur la liste de diffusion DRI (93 clics)
# des vidéos au format MPEG ou H264
Posté par Olivier Jeannet . É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 ElectronLibre63 . É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 khivapia . É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 claudex . Évalué à 4.
Ça dépend du travail.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: des vidéos au format MPEG ou H264
Posté par dinomasque . Évalué à 10.
Certains étant plus égaux que d'autres, la consommation est proportionnelle.
BeOS le faisait il y a 20 ans !
[^] # Re: des vidéos au format MPEG ou H264
Posté par Gui13 (site web personnel) . Évalué à 2.
Cahuzac?
[^] # Re: des vidéos au format MPEG ou H264
Posté par remjg . Évalué à -4.
Je me suis connecté juste pour indiquer que ce commentaire était pertinent ;)
[^] # Re: des vidéos au format MPEG ou H264
Posté par Olivier Jeannet . É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 ʭ ☯ . É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.
Bref, parfois c'est mieux, parfois pas.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# codage
Posté par antistress (site web personnel) . É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 ʭ ☯ . É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://afdgauch.online.fr
[^] # Re: codage
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 04 avril 2013 à 23:24.
Si : pilote libre+VA API
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 ellebehash . É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 rictus (site web personnel) . É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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.