Collanews

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierVos flux RSS

L’accélération vidéo dans HandBrake

Par Pierre Dandumont

J’utilise HandBrake depuis des années pour (re)compresser des vidéos ou passer d’un format un peu atypique à quelque chose de plus standards, et je me suis rendu compte récemment que depuis la version 1.2, HandBrake peut utiliser l’accélération vidéo sous macOS.

L’encodage chez Apple passe parce une technologie appelée VideoToolbox. Il y a assez peu d’options dans HandBrake (et sous macOS), et la technologie est supportée depuis pas mal de temps. Pour le HEVC (H.265), ça doit marcher sur tous les Mac sortis après 2015. Le principal problème de VideoToolbox va être « Qui encode ? ». La question n’est absolument pas triviale, les Mac intègrent plusieurs encodeurs différents.

Premièrement, il y a les fonctions des GPU Intel, disponibles sur les Mac avec un IGP (les portables, quelques iMac, les Mac mini, etc.). La technologie porte le nom de QuickSync et permet d’encoder plus ou moins bien en H.264 ou en H.265 sur les appareils récents. Sur d’autres Mac, c’est le GPU dédié qui prend la main, généralement à base d’AMD. Et en fonction de la carte graphique, les résultats varient. Enfin, sur les Mac avec une puce Apple T2, l’encodage (et le décodage) passent par cette dernière (et c’est a priori plus rapide, mon Mac n’a pas de T2).

Attention, l’encodage sur le GPU peut être moins bon que sur le CPU. Les encodeurs ont des fonctions fixes et la qualité diminue, un bon encodeur CPU évite les erreurs, compressent mieux et offre un résultat meilleur, mais généralement bien plus lent. Mais pour un usage grand public basique, genre regarder un film sur l’Apple TV, l’encodeur GPU suffit généralement. Il va manger quelques détails, mais il va aller 5 à 10x plus vite, ce qui n’est pas négligeable. L’encodeur Apple, on va le voir, a un défaut gênant pour HandBrake : il demande un bitrate précis (le débit). Avec le x264 ou le x265, on peut définir une qualité à obtenir, et l’encodeur va se débrouiller en fonction de la scène. Avec l’encodeur Apple, il faut définir une valeur de débit, et c’est tout. En pratique, on a donc des fichiers plus gros par défaut, et il faut tester pour atteindre le bon rapport débi/qualité (pas très pratique).

Avec HandBrake, une fois la vidéo choisie et les paramètres définis, il faut se rendre dans l’onglet Vidéo et modifier l’Encodeur vidéo. Par défaut, HandBrake va souvent proposer le x264, un encodeur logiciel efficace. Il suffit de passer sur un encodeur VideoToolbox pour activer l’accélération. Attention, surtout avec l’encodeur H.265, le résultat n’est visiblement pas toujours parfait, mais je n’ai pas eu de soucis.

HandBrake


Deux options VideoToolbox

Quelques tests

Je suis parti d’une vidéo d’une dizaine de minutes en 1080p (Big Buck Bunny) et j’ai testé plusieurs cas de figures. La machine est un MacBook Pro 2017, avec un CPU quatre coeurs (Core i7 7700HQ), une Radeon Pro 560 et un eGPU à base de Radeon Vega 64.

L’encodage en H.264 (x264) utilise le CPU pour encoder, et le processeur reste aux alentours de 2,9 GHz en permanence (entre sa fréquence de base, 2,8 GHz, et son Turbo à 3,4 Ghz). Il encode en 7 minutes et 23 secondes (~32 fps) pour un fichier final de 278 Mo.

L’encodage en H.264 par VideoToolbox utilise le GPU (l’Intel, j’y reviens). Le CPU reste utilisé pour pas mal de tâches, mais l’encodage prend seulement 2 minutes et 18 secondes (~104 fps). Petit défaut, le fichier final est plus gros : 459 Mo. Je n’ai pas remarqué de dégradations visuelles flagrantes. Pour la taille du fichier, c’est normal : l’encodeur Apple a peu d’options, et HandBrake sélectionne un bitrate fixe (6 Mb/s) avec ce dernier, contre un réglage de qualité sur l’encodeur software (RF 22).

Le second essai a été d’encoder de la même façon, mais en débranchant le eGPU. Le résultat ne bouge pas : 2 minutes et 17 secondes. C’est bien l’IGP Intel qui encode en H.264. Le dernier essai (uniquement avec l’IGP) confirme bien que c’est l’IGP qui encode : le GPU ne s’active pas, le temps ne bouge pas.

L’encodage en H.265 (x265) avec les mêmes réglages (RF 22) utilise le processeur. Il prend nettement plus de temps (14 minutes et 33 secondes, ~16 fps). Le fichier est un peu plus petit qu’en H.264 (243 Mo). Je suppose qu’il y a des réglages plus efficaces, ceci dit.

L’encodage en H.265 par VideoToolbox utilise le GPU, et plus spécifiquement dans mon cas l’eGPU (une Radeon RX Vega 64). C’est un peu tendu à voir, mais l’augmentation de la température montre bien que c’est cette carte précise qui encode. Il faut 2 minutes et 21 secondes (~101 fps) pour un fichier de 472 Mo. C’est aussi logique : HandBrake ne permet qu’un bitrate fixe.

On voit que la Vega 64 travaille un peu

Le seconde essai, là aussi, passe par le débranchement du eGPU. L’encodage s’effectue ici sur l’IGP Intel (on peut le voir avec Moniteur d’activité) mais une partie passe aussi par le GPU dédié (Radeon Pro 560 dans mon Mac). Vu l’occupation, je peut supposer que le décodage s’effectue sur le GPU et l’encodage sur l’IGP. Malgré tout, c’est nettement moins rapide : 5 minutes 19 secondes (~45 fps). Le troisième essai confirme : il faut le même temps et macOS force l’activation du GPU.

Ici, Radeon et Intel HD travaillent de concert


L’encodage force bien le GPU

Conclusion

L’encodage H.264 s’effectue visiblement uniquement via QuickSync, et rapidement. Pour le H.265 (HEVC), ça va dépendre de votre Mac, mais un eGPU peut donner un gros gain. Le jour ou j’ai une machine sans GPU ou une autre avec une puce T2 sous la main, j’effectuerais d’autres tests.

Un eGPU pour Macintosh… en SCSI

Par Pierre Dandumont

Récemment, j’ai récupéré un boîtier PowerView de chez Radius. Il s’agit d’une carte graphique externe en SCSI. Oui, c’est assez particulier.

Je l’ai reçue sans alimentation externe, donc pour information (et pour mon moi du futur qui cherchera) : il faut un bloc en 5V et 3A, continu, + au centre. La liste de compatibilité officielle comprend Mac Classic II, Powerbook 140, 145, 145b, 160, 165, 170, 180 and 180c. En pratique, j’ai testé sur un Macintosh LC III sans problèmes.

La carte est assez imposante, nécessite une alimentation externe et se branche en SCSI Centronics. Elle propose deux prises pour le chaînage, un sélecteur pour l’ID SCSI et deux sorties vidéo. Une prise DA-15 pour les écrans Apple et une DE-15 (VGA) pour les écrans de PC. En interne, elle contient selon la page Wikipedia une puce TMS34010, un accélérateur vidéo des années 80. Vous trouverez les pilotes sur cette page. Sur les pilotes, justement, j’ai dû ouvrir l’image disque et copier manuellement le Tableaux de bord au bon endroit, l’installeur indiquait que je n’avais pas la bonne disquette en travaillant depuis l’image disque.

La carte


Les prises


Les infos (le 0346 indique le modèle exact)

La carte a ses limites, que cette vieille FAQ détaille. La carte peut afficher du 800 x 600 au maximum en 256 couleurs (version 0346, la mienne) ou du 1 152 x 870 (la version 0366). Visiblement, System 7.1 semble le dernier OS supporté, et il existe une version 2.2 bêta pour certains Mac. Sur les Mac “récents”, ça ne fonctionne pas. Je n’ai trouvé que PowerView 2.1, mais ça fonctionne, donc. Dans les autres trucs à savoir, il dépend de Color QuickDraw (donc de la ROM des Mac) et il existe d’autres versions et d’autres modèles (SuperMac SuperView, Aura ScuzzyGraph, etc.).

Il est bien vu comme second écran

J’ai branché la carte à mon Macintosh LC III, mis une terminaison (pas obligatoire, visiblement) et installé les pilotes, donc. A l’usage, l’OS lui-même est un peu lent. La souris bouge avec un lag visible, comme le déplacement des fenêtres. C’est plus fluide sur la carte vidéo intégrée, c’est évident. Une fois l’écran externe indiqué comme écran principal (comme dans un Mac moderne, en déplaçant la barre de menus sur le bon écran), on peut lancer des logiciels. C’est un peu plus lent que sur l’interne, mais tout à fait jouable dans le cas de Prince of Persia, par exemple. Plus largement, pour un écran externe de présentation (par exemple), c’est amplement suffisant à l’époque. C’est mieux en interne, c’est évident, mais c’était une solution valable pour l’époque.

256 couleurs max


Plusieurs choix possibles


Les options du Tableau de bord

Dans la vidéo, je mets quelques mouvements de souris, le changement d’écran principal, le lancement de quelques jeux, etc. C’est fluide dans les jeux, choppy dans l’interface.

❌