L’institut Fraunhofer pour les télécommunications a annoncé hier soir l’arrivée du VVC (Versatile Video Coding) ou H.266, en relève du H.265. Il a été développé pendant trois ans en partenariat avec Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm et Sony notamment.
On retrouve les promesses habituelles des évolutions de la technologie : un nouveau bond d’environ 50 % dans la réduction du poids des fichiers, sans « différence perceptible dans la fidélité visuelle ». À taille constante, les vidéos pourront bien sûr être de meilleure qualité.
Fraunhofer donne un exemple. Il faut actuellement 10 Go pour stocker 90 min de vidéo 4K UHD en H.265. En H.266, la même vidéo ne prend plus que 5 Go. Le codec a d’ailleurs été pensé avec les 4K et 8K en cibles.
L’institut annonce également que les logiciels permettant de lire et coder en H.266 seront disponibles pendant l’automne.
Le nouveau codec aura cependant fort à faire pour s’imposer. Le H.265 n’a été adopté que lentement mais est bien là, tout comme AV1, un standard ouvert, sans royalties et faisant aussi bien. Sans parler du H.264, très présent.
Commentaires (79)
#1
Bah voila, pas besoin de la 5G pour regarder du porno en (U)HD dans les toilettes, suffit du H.266.
E Piellot va être content…
La réduction de 50% en volume est impressionnante, quid des ressources nécessaires pour décoder un tel fichier par rapport à un 4K H.265 sachant qu’au départ il n’y a pas de support matériel non, tout sera en software ?
#2
Quel intérêt d’utiliser ce format quand l’AV1 fait aussi bien mais gratuitement ? " />
#3
#4
Le véritable problème va être le non support hardware. Sur des machines vraiment performantes, cela ne devrait pas être trop un souci. Sur des machines un tant soit peu anciennes, oulah … Déjà que tous les matériels actuels n’ont pas de capacité hardware de décodage H265, pour le H266, va falloir attendre, et pas qu’un peu.
#5
Comme toujours, faut renouveler le matos pour une prise en charge matérielle. " />
#6
En même temps comment veux tu la prise en charge matérielle sans changer le matos?
#7
J’en sais rien du tout, ce n’est pas mon métier.
Je trouve ça juste dommage de devoir changer. " />
#8
Au vu du degré de programmation possible sur les puces graphiques actuelles, une maj par driver est envisageable. Par contre je doute que les fabricants de smartphones la propose si elle existe un jour.
#9
Prise en charge matériel signifie que c’est directement supporté par des composants spécifiques dans le silicium.
Pour ça qu’il faut changer.
Prise en charge logiciel par contre te permet de l’utiliser sans changer de matos, s’il est assez puissant
#10
#11
Le H.265 est sorti en 2013, il y a 7 ans. On a donc un gain moyen de 6,4% par an, pas négligeable!
#12
C’est le support logiciel ;)
#13
Yes, mais pour moi, le support logiciel, c’est le CPU. " />
La CG n’est pas utilisée, moi je vois que sur YT, le codec AV1 utilise le CPU.
#14
Il est clair qu’avant de trouver une box multimédia (et pire : une télé) compatible, et à un coût moindre (comme avec des puces Asmedia ou nVidia) on risque d’attendre un peu. " />
Déjà que les puces actuelles ARM (sauf Apple A10+) ne savent pas décoder des flux élevés (> 100Mbits en crête) alors décoder de l’AV1 et pire h266…. Ben ne compressons pas trop vite nos vidéos “archivées” pour gagner de la place " />
#15
Le H265 n’est même pas décodé par la Freebox revolution…. alors pour le H266, faudra attendre de nouveaux matos.
#16
#17
#18
Guerre des codecs en perspective ?
#19
ce qui m’interroge à chaque fois c’est la limite en résolution d’un codec donné, ça marche comment ? Il n’est pas efficace si on a trop de pixels en même temps ?" />
Hormis pour le fun ( " /> ), qu’est-ce qui n’empêcherait de faire du 4K en MPEG2 par exemple ? (enfin les logiciels et le codec doivent imposer la limite justement).
+1 avec Citan666
#20
J’sais pas, chez moi l’AV1 utilise la partie 3D du GPU d’après le task manager alors que le VP9 utilise la partie Video Decode " />
#21
#22
#23
#24
#25
J’ai une 1080 Ti donc tout ce qui est après 2017 c’est mort….
#26
#27
Pour le support des codecs, intégrer un FPGA aux GPU pourrait être intéressant.
#28
Pour le support des codecs, intégrer un FPGA aux GPU pourrait être intéressant.
#29
Pour le support des codecs, intégrer un FPGA aux GPU pourrait être intéressant.
#30
Quid du temps d’encodage ? Vu le temps complètement abusé requis par le H265, s’il faut encore plus, pratiquement personne ne l’utilisera.
#31
Je partage également ton avis sur les gains d’un côté qui se traduisent par une augmentation de usage et non par une économie.
Traditionnelle analogie bagnolesque :
Pour la voiture électrique, le gain de densité sur les batteries ne va presque pas à la diminution du poids de la voiture mais à l’augmentation de l’autonomie.
Idem, l’amélioration des moteurs thermiques a surtout permis d’augmenter la taille des voitures sans augmenter la consommation.
C’est la même chose avec l’informatique.
#32
un nouveau bond d’environ 50 % dans la réduction du poids des fichiers, sans « différence perceptible dans la fidélité visuelle »
Quelqu’un aurait-il une source expliquant comment on compare la fidélité visuelle ?
Parce qu’en demandant à un aveugle, on peut descendre jusqu’à 100% sans différence perceptible dans la fidélité visuelle ….
#33
#34
#35
Éric Piolle* ;)
#36
#37
#38
La comparaison divx / mpeg2 tiens toujours, malheureusement.
Pour obtenir leur gains en compression on perd généralement en piqué, et a mes yeux ca reste visible pour toutes les évolutions.
On a de plus en plus de fonds baveux (aplat au lieu de grain du film), mais, chouette, on peu faire passer tenir 2H de 8K sur un CD..
#39
#40
#41
#42
#43
#44
#45
#46
#47
#48
#49
#50
Le problème principal qui se pose, c’est la consommation énergétique.
Même en décodage matériel, le H265 est déjà bien plus gourmand que le H264, c’est bien beau de parler de réduction de poids de fichiers et débits de streaming, mais si la consommation d’énergie pour décoder le H266 sera supérieure aux gains côté réseau et stockage, à quoi bon ?
Ça n’est pas un hasard si le H265 peine à s’imposer en streaming et à être adopté partout !
À la limite, ça pourra être intéressant pour les services d’accès à distance (Cloud Gaming comme Shadow, Teamviewers & cie…)
#51
#52
#53
Je me pose aussi cette question. Après j’imagine qu’il faut qu’il soit suffisamment taillé pour les usages futurs.
#54
Il n’y aura peut être pas la chaîne complète mais aujourd’hui le décodage passe par tellement d’étapes qu’on peut espérer que les plus coûteuses soient quand même déjà faisables matériellement.
#55
#56
A part une optimisation des lecteurs/codec et l’utilisaiton combinée du couple GPU/CPU, je vois pas encore comment.
Wait and see
#57
L’encodage ce n’est rien car si on parle de diffusion, on encode une fois pour diffuser potentiellement des milliers/millions de fois.
Tu penses bien que Netflix dont les coûts viennent en grande partie du transfert de donnée va prendre le temps d’encoder les vidéos correctement.
#58
En petits caractères on lit H.266/WC.
#59
#60
#61
#62
J’ajoute que le morse est un codage aussi (on parle de code Morse).
Il y a une forme de compression qui se rapproche de ce qui est exploité par Huffman, les lettres les plus courantes en anglais sont codées sur peu de signes (le “e” est juste un point, le “t” est un seul trait, le “a” et le “i” sont sur 2 signes, etc.), ce qui permet au passage de transmettre un message plus rapidement qu’un codage de type ASCII (même sur 5 ou 6 bits).
#63
Le temps qui passe fait mal aux oreilles… et a surtout une compression / encodage / autotunage / vocodage / accent / vocabulaire / cyclotrucage très étrange " />" />
#64
Si ce n’était que les encodeurs HW qui étaient mauvais, les décodeurs aussi.
Et c’est bien la le but de ma question originale : comment on évalue la qualité d’un système de codage si chacun fait comme il veut lors de implémentation.
Pour en revenir a l’ancêtre divx, a chaque nouvelle version, ils se vantaient d’être plus rapide … en changeant le processeur de test pour un plus puissant.
Eh non, je ne ferais pas d’encodage, il y a bien longtemps que j’ai arrêter de jouer a ca " />
#65
#66
#67
#68
Je regarde des dictionnaires qui sont sérieux. Et surtout j’ai une mémoire des usages, et je refuse le laisser-aller sous prétexte que des geeks s’expriment mal dans des forums (suis geek aussi). La démocratisation de l’informatique a trop laissé se répandre des anglicismes inutiles et des mésusages.
#69
#70
#71
J’ai volontairement utilisé les mots qui me venaient naturellement et que tout le monde comprend, j’ai vu la discussion enflammée sur le sujet dans les commentaires et je m’en fous.
#72
Mais fais-tu partie de ceux qui diffusent ? Recompresser pour un usage local à la limite c’est ton problème, au mieux ça te ferait gagner de la place ça retarderait l’achat d’un nouveau disque dur mais c’est tout. Par contre recompresser avant diffusion en ligne, ça fait gagner en temps de transfert, en stockage sur d’éventuels serveurs et donc en énergie/matériel.
#73
#74
#75
“Dictionnaire qui sont sérieux”…Ha ?! et lesquels ?
Aller au pif : le dictionnaire de l’académie française. Après tout il est officiel. C’est le plus légitime. Non? Cocoricooooo!
Alors regardons de plus près :
C’est quand même se foutre de la gueule du monde de parler de vocabulaire et de défense de la langue française face aux attaques anglo-saxonnes quand dans le même temps l’usage de termes non admis est plus que flagrant et abusif! Au point que cela parait pathologique avec un soupçon de compulsivité mal placée.
Et s’il te prends l’envie de donner une leçons aux “Immortels”, appelles moi. Je préparerai deux tonnes de pop-corn (ha mince un mot anglais…sic). C’est quand même dingue de se fourvoyer comme cela.
#76
La réduction de ton impact environnemental, tout simplement.
Des fichiers plus petits = moins de charge réseau pour le transfert et moins de besoins matériels (et énergétiques) pour le stockage.
Si on parle de diffusion à grande échelle l’effet est évidemment démultiplié.
Evidemment c’est sous réserve que le décodage ne prenne pas plus de ressources que ce que tu gagnes en transfert, mais ce n’est pas gagné car ça consomme beaucoup de transférer des grosses quantités de données.
#77
#78
Non ce n’est pas une blague le dictionnaire est en ligne. Cela prend deux seconde à vérifier.
 https://www.dictionnaire-academie.fr/
fin.
#79