Collanews

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

Checkout Hypertec’s Solutions At 2020 NAB Show Exhibit

Par Andres Benetar

  To live in the information age is to live in a time of substantial innovation and constant evolution. Nothing sums up this notion more than the 2020 NAB Show, which is all about progression and the evolution of the broadcast industry. With over 90,000 professionals who specialize in media, content, and technology attending, then ...

The post Checkout Hypertec’s Solutions At 2020 NAB Show Exhibit appeared first on NAB Show News | 2020 NAB Show Media Partner and Producer of NAB Show LIVE. Broadcast Engineering News.

Concours GPU Hivernal 3DVF/NVIDIA/LDLC : découvrez les premiers projets et participez !

Par Shadows

Notre concours “GPU Hivernal”, organisé en partenariat avec NVIDIA et LDLC, bat son plein. Pour rappel, le principe est de créer un rendu évoquant l’hiver d’ici la fin du mois, avec un moteur pouvant utiliser le GPU (qu’il soit 100% GPU, propose une option de denoising accéléré sur GPU, qu’il s’agisse d’un moteur temps réel, etc). 5000€ de lots sont à gagner, dont un ordinateur portable haut de gamme et des cartes graphique dernier cri.

Une vingtaine de participants ont déjà créé le sujet de forum associé à leur participation : n’hésitez donc pas à faire un tour dans la rubrique dédiée, afin de jeter un oeil à l’avancée des différents projets mais aussi pour donner vos conseils et retours !

Rappelons que le concours se termine le 29 février à minuit : vous avez encore largement le temps nécessaire pour vous plonger dans le règlement et vous lancer également, afin de remporter un des lots !
N’oubliez pas également de jeter un oeil à la FAQ en bas du règlement, et au sujet de forum associé : nous sommes là pour répondre à vos questions en cas de doute.

L’article Concours GPU Hivernal 3DVF/NVIDIA/LDLC : découvrez les premiers projets et participez ! est apparu en premier sur 3DVF.

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.

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.

❌