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.

Le moteur de rendu Arnold passe en V6 : le GPU à l’honneur

Par Shadows

Enfin ! Avec la nouvelle version 6 d’Arnold, il devient enfin possible de faire des rendus à la fois sur CPU et GPU.

Le nouveau mode Arnold GPU s’appuie sur NVIDIA OptiX et est optimisé pour tirer parti de la technologie RTX : une carte graphique récente sera donc bienvenue même si pas indispensable.
Si Arnold GPU avait été dévoilé en beta en mars dernier, la version 6 en fait un véritable outil de production, avec support des fonctions essentielles. Reste toutefois encore quelques limitations : une poignée de LPEs, de lights et de shaders ne sont pas encore gérés. La documentation vous donnera le détail de ces restrictions.

Outre Arnold GPU, le moteur de rendu progresse en ce qui concerne USD avec une collection de composants dédiés.
Enfin, une série d’optimisations sont annoncées :

faster creased subdivisions, Physical Sky shader improvements, dielectric microfacet multiple scattering, improved Oren-Nayer Diffuse Roughness Mapping, better rough thin wall transmission in Standard Surface shader, and more accurate albedo AOVs.

Arnold 6 est disponible dès à présent, en souscription standalone ou via les collections Autodesk. Arnold GPU est disponible via les plugins Maya, Max, Houdini, Cinema 4D, Katana.

L’article Le moteur de rendu Arnold passe en V6 : le GPU à l’honneur est apparu en premier sur 3DVF.

Les drivers Quadro passent en 440 : quoi de neuf ?

Par Shadows

NVIDIA annonce le lancement de la release 440 de ses Quadro Drivers. Issu des branches de développement ODE (Optimal Driver for Enterprise), il s’agit donc d’un driver pensé pour la stabilité à long terme.

Au menu de cette version 440 :
– le support G-Sync pour les applications OpenGL et Vulkan ;
– la possibilité de fusionner et mettre à l’échelle le contenu de deux systèmes d’affichage et d’envoyer l’image finale sur un écran ou projecteur séparé, lié au même GPU ;
– le support en beta de l’upscaling de contenus plus réduits que la résolution native à l’aide d’integer scaling.

En outre, la version 440 apporte des gains de performances allant jusqu’à 30% sur certains outils : Solidworks, VRED, CREO.

Enfin, la dernière version de Windows 10 est pleinement supportée.

Ce nouveau driver peut être téléchargé chez NVIDIA.

L’article Les drivers Quadro passent en 440 : quoi de neuf ? est apparu en premier sur 3DVF.

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.

OpenDataCam 2.0 – An open source tool to quantify the world

Par Filip Visnjic
OpenDataCam 2.0 – An open source tool to quantify the world
OpenDataCam is a open source tool to quantify the world. It consists of a camera attached to a mini computer that is running an object detection algorithm that counts and tracks moving objects.

Cinegy to demonstrate real time 8K video editing and display capabilities with Sharp at IBC 2019

Par Manor Marketing

IBC 2019, 13-17 September, Stand 7.A01:  Cinegy, the global leader for broadcast playout software in the cloud, has announced that it will showcase the full scope of its 8K recording, capture, archive, and encoding capabilities during IBC 2019. On its IBC stand, Cinegy will feature the eye-popping Sharp 8M-B80AX1E 8K displays, the first 80-inch 8K ...

❌