H.265, VP9, AV1… Des codecs qui coûtent cher
Le secteur de la diffusion de vidéos en streaming est tout proche d’un grand bouleversement. Jusqu’à présent, cette industrie n’avait guère plus qu’un codec à gérer, le H.264/AVC. Les choses vont changer très rapidement, Apple ne faisant aucun mystère de son support du H.265/HEVC, qui sera la norme dans iOS 11 et macOS High Sierra ; du côté de Google et d’Android, on supporte le codec VP9, tandis que l’Alliance for Open Media a son AV1 libre et gratuit, supporté par les plus grands noms de l’industrie tech.
La fragmentation est donc en marche, les diffuseurs devant supporter au moins trois codecs : H.264, H.265 et VP9, en attendant l’AV1 qui devrait être lancé en 2019. Pour l’utilisateur et les tuyaux des opérateurs, les atouts des nouveaux codecs sont évidents : les fichiers pèsent beaucoup moins lourd à qualité égale. En revanche, c’est un casse-tête pour les diffuseurs qui vont devoir consacrer beaucoup de ressources pour encoder leur contenu dans ces formats.
Pour les serveurs, le coût d’encodage en H.265 et en VP9 est multiplié par cinq. Pour l’AV1, ces coûts sont même multipliés par… 20 ! Et il faut aussi prendre en compte les différents niveaux de qualité : aux SH, HD et 4K, il faut ajouter le HDR, le 10-bit, et un framerate plus élevé dans certains cas. Or, il faut multiplier par 5 les coûts serveur pour passer du 1080p SDR au 4K HDR. Et puis il y a également les contenus 360° qui sont de plus en plus consommés et qu’il faut bien prendre en charge également.
Selon Dan Rayburn, analyste pour StreamingMedia, les diffuseurs de contenus en streaming pourraient bien subir une multiplication par 500 de leur facture d’encodage dans les prochaines années en raison de la prise en charge des nouveaux codecs, de la qualité d’image et des vidéos 360°. Évidemment, l’industrie a commencé à réfléchir sur le sujet en exploitant une technologie qui commence à prendre racine dans les fermes de serveurs, le FPGA (Field Programmable Gate Array) ou encore circuits logiques programmables.
Plus souples que les processeurs et processeurs graphiques, ces circuits sont déjà installés dans les centres de données d’Amazon, de Baidu ou encore chez OVH, où on estime d’ailleurs que « 2017 sera l’année du déploiement » de cette technologie.
Chaque format a ses qualités, mais aussi ses défauts. Si chacun reste sur ses positions, nous risquons le blocage. Je pense que, comme chaque fois, se sont les diffuseurs qui vont faire le tri et créer un standard de fait (probablement celui qui ménage le mieux la bande passante!) auquel les utilisateurs se rallieront par nécessité.
Bon ben je suis rassuré c'est donc AV1 qui a gagné (Google, Netflix, Amazon, Hulu...)
@JLG01
Pas tres facile de savoir quel format va prendre le dessus.
Pour la musique on a eu le cas du MP3, format pourri et bricolé, mais qui a bénéficié d'un engouement du GP sur lequel les industriels ont surfé (voire se sont crees pour une bonne part)
Pour la video si on remonte a la prehistoire, il y avait le VHS, totalement pourri qui a supplanté le BetaMax...
Ensuite on a eu le consensus sur le format de fichier numerique H.264/AVC, apres de grosses discussion dans l'industrie du divertissement.
Maintenant on est dans la phase du streaming, l'industrie tentant toujours de supprimer le modele du telechargement, bien trop dangereux.
Le prochain format qui va emerger sera celui qui:
- donnera le plus de garanties en terme de DRM
- chargera le moins les reseaux (parce que les operateurs vont finir par faire payer les diffuseurs)
- sera le mieux supporté par des coprocesseurs integré dans les materiel
- offrira la meilleure durée (pas pour le consommateur, mais qui encaissera le plus d'evolution du coté du diffuseur: 120hz,3D, HDR, autre futurs machins marketing,...)
- aura une duree de vie pas trop longue histoire de quand meme pas refaire le coup du CD...
Aujourd'hui y a plusieurs candidats...
et puis y a un parametre qui reste aussi dans l'espace: quel format va adopter le sharing. Parce que si la repression est de plus en plus violente et efficace, le sharing est quand meme et toujours un tres gros acteur dans le paysage... Il suffit qu'un nouveau protocole capable de passer sous les radars et echappant aux lois scelerates emerge et on va revenir a l'epoque glorieuse du MP3... Et la c'est le format de compression majoritaire de cet usage qui va devenir le principal.
> on est dans la phase du streaming, l'industrie tentant toujours de supprimer le modele du téléchargement
Un ordinateur ne peux pas lire un contenu qu'il n'a pas et donc pas non plus l'afficher. Le "streaming", c'est du téléchargement, certes après utilisation la duplication contenu est "vite" supprimée, mais il y a bien eu téléchargement.
---
Il y aussi la problématique des brevets qui pourrait ne pas être négligeable pour le "choix" du futur format majoritaire (s'il y en a un qui prend significativement le dessus sur les autres).
Question me venant à l'esprit comme ça: je télécharge souvent des épisodes de séries en h265 vu le poids très intéressant et la qualité au top. J'ai l'impression qu'à durée égale un épisode en h265 consomme plus de batterie qu'un en h264 est-ce possible ? La décompression demande-t-elle plus de ressources ? Merci d'avance ?
@shaba
Oui ça demande plus de ressource, et tu dois avoir un processeur moderne pour ne sentir qu'une baisse de batterie. Si le processeur n'est pas optimisé pour le décodage ça va te prendre un paquet de puissance.
@fousfous
J'ai un iPad mini 4 qui lit ça sans broncher avec infuse. Merci de ta confirmation :)
@shaba
Août 2017, seuls les processeurs Kaby Lake d’Intel disposent d’instructions spécifiques pour h265 (et codecs utilisant le même type d’encodage). Il y a des ASIC spécialisés également, bien entendu.
Les iPad utilisent simplement leur puissance brute. Ce qui n’est pas sans conséquences sur la batterie.
Mais dans tous les cas, les nouveaux codecs sont très fortement asymétriques et demandent considérablement plus de puissance à l’encodage qu’au décodage.
@ fte
Et pourtant depuis 2015 processeur et GPU sur le desktop supporttent le decodage HEVC, Skylake a des instructions pour decoder du HEVC.
Apple A8 supporte HEVC.
nVidia supporte HEVC depuis les 950/960.
> Apple A8 supporte HEVC.
Dans ce cas il faut d'urgence que tu contactes Apple parce que tu en sais + qu'eux sur leurs produits ! Ils ont précisé/rappelé à la WWDC session que le support HEVC était à partir du A9.
Grace à tes infos on a plus à attendre une hypothétique appletv5 pour avoir le support hardware de l'HEVC, on l'aurait déjà dans l'appletv4 ...
@tboy
Je confirme. J'ai un iPad mini 2, on voit que sur du h264 c'est décodage HW, sur du h265 c'est du software et ça rame...
https://ibb.co/jaOXra
https://ibb.co/fEvZ4v
Oui voici le document wwdc d'apple: https://devstreaming-cdn.apple.com/videos/wwdc/2017/503i6plfvfi7o3222/503/503_introducing_heif_and_hevc.pdf
Pour HEVC
>=A9 pour le décodage
>=A10 fusion pour l'encodage (8bit)
Il vaut mieux privilégier le 10bit, ne serait-ce que pour un gain de place.
Je te propose donc de contacter Intel pour leur signaler les erreurs dans leurs datasheets.
Le chip graphique de Kaby Lake décode l'HEVC en 4k sans mouiller le slip, Skylake rame en 1080p60.
Quant à décoder du HEVC, je pense qu'on peut y arriver sans peine en JavaScript sur un 8086. Pas en temps réel par contre.
Je te parle au niveau des chips d'apple et de ton A8 et tu réponds sur les processeurs intel...
Et même la tu te mets à mélanger décodage hardware et décodage software avec ton 8086.
Tu aurais pu tout simplement répondre: "je me suis trompé concernant le A8" , c'eût été suffisant :)
Je répondais à Stardustxxx qui évoquait Skylake. Si je ne m'abuse, Apple ne donne pas les mêmes noms de code qu'Intel à ses processeurs.
Et je ne mélange pas software et hardware. Skylake a un support software limité, Kaby Lake ajoute des instructions hardware, ce qui explique que Skylake rame en 1080p et que Kaby Lake s'emmerde en 4k.
@fte
Skylake ne rame pas en 1080p en 8 bit
http://forum.doom9.org/showthread.php?p=1735714#post1735714
https://www.reddit.com/r/htpc/comments/421h3c/skylake_is_a_more_cost_effective_4k_h265_decoding/?st=j5y3oix8&sh=62c49d2e
En HDR, kaby lake est mieux
@Stardustxxx
"Skylake ne rame pas en 1080p"
Ça depend du débit numérique. Beaucoup. Les torrents ne sont pas une référence.
@fte
Qui parle de torrents ?
Dans les tests, ils montent jusqu'a 300 Mbps en débit sans aucun soucis en terme de performance.
@fte
Encore plus de resultat pour le decodage h265 sur different CPU/GPU : https://forum.doom9.org/showthread.php?p=1799099#post1799099
@fte @tboy
Pour ce qui est du playback :
https://www.techspot.com/article/1131-hevc-h256-enconding-playback/
Donc il y a une erreur dans l'article, ca parle du A8. Mais peut-etre qu'ils ne parlent que du support h265 pour facetime (et donc resolution limitée)
Pour ce qui est des procs intel, voici le support pour le HEVC, ca commence avec skylake :
http://www.flatpanelshd.com/news.php?subaction=showfull&id=1496905696
@shaba
Hello, cela m'intéresse. J'ai un ipad mini 2 qui a de la peine selon les fichiers en h265. Il a un A8 et toi un A8x, que peux-tu lire exactement ? 720-1080p? Ntsc ou 60 fps? 8bit et 10 bit? Film d'animation ou normal?
Merci pour ta réponse, je t'avoue que le support avancé seulement pour le a9 et hevc sur le site d'infuse m'a bien perturbé, vu que j'arrive quand même à lire certains fichiers en 1080p
@Tankiste
Et bien je lis du 720 et du 1080 sans soucis en h265. Pour les autres caractéristiques, je ne me suis jamais penché sur la question je prends les fichiers tels quels sur les sites de ddl...
@Tankiste
Un iPad mini 2 a un A7
Le h265 demande beaucoup plus de ressources materielles que le h264.
Tous les processeurs actuels savent le traiter (pour les x86, faut compter sur les processeurs datant de 2008) mais seules les toutes dernieres generations de processeurs disposent de circuits dediés qui consomment pas trop (Intel Skylake au minimum et coté ARM, il me semble qu'il faut un A9 au minimum)
Sur un PC portable ça peut vider la batterie tres vite et sur un smartphone/tablette ça peut simplement ne pas fonctionner.
A noter que tous les softs (mediacenter/player) ne sont pas capablent de traiter le h265. VLC focntionne avec quasi tous les materiels, mais c'est pas le cas de kodi ou d'iOS.
@shaba
Plus la compression est sophistiquée, plus il faut de moyens pour la récupérer. Si en plus on monte en définition, c'est encore plus de pixels à restituer.
C'est la course habituelle à l'armement qui ringardes la matériel le plus ancien. La véritable obsolescence est là, bien plus que dans la prétendue panne matérielle programmée.
Sujet interessant, mais j’aurais aimé en savoir plus sur ces FPGA avec un gain chiffré de ce qu’ils apportent.
Si j’ai bien compris ce que l’on perd en coût d’encodage, on le gagne en taille de stockage.
Ca aurait aussi interessant de dire dans quelles proportions.
@ macinoe
Au final un FPGA est un circuit intégré remplissant une fonction particulière (ici encodage ou décodage de vidéo) de manière ultra efficace. C'est en quelque sorte du code, des algorithmes gravés en dur dans le silicium. Les FPGA ont comme avantage d'être relativement faciles à concevoir et à produire car ils utilisent tous la même trame (chez un producteur donné). Le hic, c'est que qui dit circuit intégré spécifique, dit carte électronique dédiée à développer elle aussi, et une interface, un "driver" logiciel pour permettre à l'ordinateur de l'utiliser. Mais une fois cet investissement effectué, ça dépote !
Quant au gain en espace de stockage, l'article parle d'un rapport de 2 pour le HEVC vs. H264.
C'est un sujet très intéressant d'ailleurs, la possibilité de rajouter un FPGA dans un téléphone ou un ordinateur. Cela permettrait d'avoir des algos qui tournent "matériellement" sur la machine et donc une efficacité énergétique incroyable. Si le FPGA est reprogrammable, cela permettrait de s'adapter à la tâche en cours et même de rendre le matériel évolutif pour le support de nouveaux codecs ou logiciels.
J'aime ta remarque quant à embarquer des FPGAs dans des appareils mobiles. Cependant, tu négliges la connaissance nécessaire en programmation/raisonnement pour concevoir des programmes capables de tourner dessus.
J'ai eu par chance une unité d'enseignement FPGA dans mon master Info (à Lille), et c'est pas si facile que ça... si on veut bien faire le job.
Tout dépend du niveau d'abstraction, mais plus tu montes, moins ton application sera taillée FPGA..
Sachant que la re-programmation de la puce prend un certain temps.
Accepterais-tu d'attendre 5 secondes ou plus avant d'utiliser une application ?
J'avais entendu que c’était plutôt de l'ordre d'une heure actuellement. Cependant rien n’empêche de commencer en pur logiciel avec une programmation du FPGA en parallèle et de passer sur celui-ci quand il est pris (un mode hybride qui sera certainement mieux en terme de consommation que le pur logiciel pour les contenus suffisamment longs).
Et donc la question est :
Est-il interessant de diviser les coûts de stockage par 2 si c’est pour multiplier les coûts d’encodage par 5 ?
Et quid de l’économie de bande passante et de la puissance supplémentaire nécessaires au décodage.
Je suppose que les nouveaux codecs consistuent globalement un progrès, mais j’aimerais en être totalement convaincu par une étude claire et chiffrée.
Pour faire simple, est-ce que ça vaut vraimen5 le coût ?
@macinoe
Le coût d'encodage est un coût fixe. Le coût de stockage est un coût récurrent. Les intéressés ont dû déjà faire le calcul d'amortissement.
Et le coût de décodage ?
@macinoe
Ça dépend de ta machine.
Les iBidules récents (génération 6S et plus) encodent et décodent matériellement le HEVC avec un coût minimum. Et le décodage démarre à l'A8 je pense
Sur Mac le support matériel commence à partir de l'HD4000 (soit tous les Macs depuis 2012).
Mon MBP 2010 lit le HEVC sans problème mais c'est vrai qu'il chauffe un peu plus sur ce format de fichier.
Le décodage démarre à l'A9 et l'encodage à l'A10 Fusion et encore, seulement le 8bit.
@macinoe
L'encodage n'est réalisé qu'une seule fois. Il faudrait savoir si le coût au Go encodé est inférieur au coût stocké.
Ensuite il ne faut pas oublier le coût de la bande passante qui est lui aussi réduit.
Enfin, et c'est le plus important, les coûts d'encodage augmentent parce qu'ils ne sont pas encore supportés par une puce dédiée (accélération matérielle) et donc traités par le microprocesseur, mais sur les Macs et iPhones récents l'encodage est réalisé en temps réel par une puce dédiée et ça ne coûte rien.
Chez Netflix il me semble qu'il y a encodage à la volée puisque ça dépend du débit du client.
à la volée ça m'étonnerait. Je dirais plutôt que les fichiers ont été encodés avec différentes qualités et que Netflix te renvoie le plus approprié
@bonnepoire
Je ne pense pas.
Les fichiers sont stockés dans plusieurs formats (comme les vidéos YouTube) et c'est la compatibilité de ton navigateur et ta bande passante qui indiquent aux serveurs de Netflix quel fichier envoyer.
Faire de l'encodage à la volée coûterait une vraie fortune !
Oui. Il n'y a pas d'étude claire et chiffrée mais je suis persuadé qu'il n'y en a pas besoin.
Le coût d'encodage est 5 fois supérieur en termes de quantité de calcul avec les technologies actuelles, mais les encodeurs matériels arrivent et rendront la différence de performances négligeable.
Idem pour le décodage. Ne reste donc plus que le stockage et le transport dont les coûts sont incompressibles à court terme.
Oui mais ces progrès matériels pourraient aussi grandement améliorer le coût de l’encodage / décodage du h264.
En fait mon interrogation vient du fait qu’il n’est pas forcement evident que l’on y gagne en terme de coût en échangeant un fichier plus compact contre un temps de calcul plus long.
C’est une équation où l’on fait varier 2 paramètres et il arrive forcement un moment le coût de l’encodage devient rédhibitoire.
Je veux dire que c’est forcement un compromis car ces 2 paramètres s’opposent et qu’en allant trop loin, les coûts peuvent tout bonnement exploser. Il y a forcément une limite à ne pas dépasser.
Je ne prends pas pour acquis qu’un codec plus récent est globalement moins couteux dans tous les cas. Je ne vois pas pourquoi ce serait si évident.
J’attends qu’on me le démontre.
C'est un calcul à faire.
A-t-on besoin de plus d'énergie pour transmettre une information moins compacte et plus facile à décoder, ou pour transmettre une information plus compacte mais qui a besoin de plus de ressources pour être décodée ?
Voilà voilà.
@minitoine
Oui c'est un très bon raisonnement.
C'est un peu comme l'impact globale écologique d'un Hummer qui était estimé moins grave que celui d'une Toyota Prius.
Quand je lis 5 fois plus couteux, je lis juste 5 fois plus d'impact écologique.
L'argent est quelque chose de très volatile, il y en aura toujours pour certaines choses. Par contre l'argent ne peux pas tout réparer....
Quand on sais qu'un email échangé c'est l'énergie d'une ampoule de 60w pendant 1heure, et qu'on a tenté de nous moraliser sur la lumière allumée qu'on a oublié,
je me dis que le streaming, les youtubes, SnapChat, et compagnies X, c'est notre fin.
@misterbrown
+10000 sur la conclusion.
Pour compléter :
- http://www.ademe.fr/sites/default/files/assets/documents/guide-pratique-face-cachee-numerique.pdf
- https://www.greenpeace.fr/il-est-temps-de-renouveler-internet/
Bref, le digital c'est comme le reste...en digital.
Le gain de multiples transits sur le réseau avec un tel encodage devrait compenser largement le coup d'encodage.
Maintenant, graver en dur une telle circuiterie* doit poser plus de problème que de reprogrammer en dur un nouvel algorithme, si on peut tenir compte de l'évolution possible des calculs de compression et du courage d'Apple d'ouvrir la reprogrammation* hardware …
* absent du dico silicium en français d'Apple
Pas possible d'intégrer ce FPGA dans le CPU ? Il me semble que c'est possible dans un ASIC ?
@ CorbeilleNews
Un ASIC (Application Specific Integrated Circuit) c'est au final un "circuit à la demande" comme le FPGA, mais la techno est différente. Le FPGA utilise toujours la même "trame" qui est "recâblée" selon les besoins, alors qu'un ASIC est un circuit sans trame prédéfinie, mais plus rapide à concevoir qu'un circuit intégré classique, car on le construit comme un gros mécano en utilisant des éléments logiques prédéfinis et disponibles dans une bibliothèque. Portes OR, NAND, flip-flop, etc, etc. A chaque élément de la bibliothèque correspond un design physique qui a été optimisé en soi, mais c'est toujours le même design qui est réutilisé partout où l'élément est utilisé. Les optimisations se font sur l'ensemble mais donc à partir de ces briques prédéfinies.
Dans un circuit intégré classique tout est optimisé, et un même élément pourra avoir un design physique différent selon l'utilisation.
Bref, un ASIC permet de faire ce qu'on peut faire avec un FPGA, mais il sera mieux optimisé et sa conception plus complexe. D'ailleurs il arrive qu'on utilise des FPGA comme prototype fonctionnel pour au final produire des ASIC.
Donc après ce long blabla, la réponse est qu'on peu parfaitement implémenter les algos de ce FPGA dans un ASIC, c'est l'inverse qui n'est pas toujours vrai pour des questions de timing et de performances. L'ASIC sera plus performant, mais les coûts et temps de conception et de production sont supérieurs car basés sur moins d'éléments standards réutilisables.
Les CPU/GPU modernes pourront encoder/décoder.
C'est plutôt l'inverse qu'il est possible de faire, créer un CPU dans le FPGA. Mais le FPGA est beaucoup trop onéreux pour le moment.
Pages