La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: yrousse le 06 juillet 2017 à 16:02:35
-
Amazon, Cisco, Google, Intel, Microsoft, Mozilla, Netflix ou encore ARM et bien d'autres se sont réunis dans un consortium pour créer le prochain standard vidéo.
Il s'agit de l'Alliance for Open Media http://aomedia.org/ (http://aomedia.org/)
L'AV1, le nouveau codec, est attendu être prêt l'année prochain. Il est toujours en cours de maturation mais l'objectif est de le rendre plus efficace que l'HEVC *et* surtout libre de contrainte coté brevets tiers.
Lien pour les amoureux de la technique: https://aomedia.googlesource.com/ (https://aomedia.googlesource.com/)
(L'un des problèmes majeur d'HEVC est bien les "Patent pools" qui ont rendu difficile et (encore) risqué l'engagement des divers acteurs du marché car tout n'est pas encore complètement verrouillé. On se rappellera que H.264 a connu les mêmes déboires à une époque).
Donc AV1… pour lequel il faut garder à l'esprit qu'on est encore loin d'une industrialisation, et qu'Apple a fait le choix à long terme de l'HEVC. Ce qui n'est pas négligeable, parce que "Apple" ;) et parce que leur appareils génèrent une portion significative de la consommation des contenus payants. (pas de source. Flemme)
-
J'ai un peu la flemme de lire les détails mais au niveau algorithmique c'est les mêmes grands principes que H264 et HEVC ou il y a vraiment une approche différente ?
-
J'ai un peu la flemme de lire les détails mais au niveau algorithmique c'est les mêmes grands principes que H264 et HEVC ou il y a vraiment une approche différente ?
C'est largement au-delà de mes compétences mais d'après ce que j'ai compris, grand nombre de méthodes d'analyses (et ils sont encore en train d'en rajouter) mais de mon point de vue de néophyte, c'est relativement similaire. Il me reste à en lire un peu plus sur le sujet.
Mon ressenti lors d'une présentation cette semaine est que ça arrivera tard vs HEVC. L'industrie de l'encodage est en train de s'équiper pour ce dernier (progressivement: H.264 fait le job aujourd'hui)
Je crois que la problématique est surtout une question de calendrier et d'adoption par 1-2 acteurs majeurs en guise de bascule.
Mais bon… si vraiment open et devices Android équipés, on en parlera plus concrètement d'ici à… 3-4 ans?
-
sujet déjà discuté ici: https://lafibre.info/tv-numerique-hd-3d/vp9-vs-hevc/ depuis le 3 septembre 2015... ils sont pas pressé chez Alliance for Open Media.
-
sujet déjà discuté ici: https://lafibre.info/tv-numerique-hd-3d/vp9-vs-hevc/ depuis le 3 septembre 2015... ils sont pas pressé chez Alliance for Open Media.
Flute, si j'avais fait une recherche…
Merci kgersen!
En tous cas, la personne de chez Google qui nous a fait la présentation semblait être confiant pour une finalisation mi-2018.
-
donc une intégration dans les GPU fin 2019 ou en 2020.
Sur les mobiles, Youtube n'utilise le VP9 que sur les smartphone qui ont une accélération hardware (les derniers modèles)
Pour Microsoft Edge, le VP9 n'est autorisé que si il y a une accélération hardware, pour préserver la batterie.
Bref, H264 et VP9 ont encore de beaux jours devant lui.
L'attitude de Apple me dégoutte. Faire la pluie et le beau temps sur les techno (flash c'était pas une si mauvaise idée), les codecs, le hardware, la appli de son store, bloquer les moteurs de rendus des navigateurs concurrents (idée reprise par Microsoft dans Windows S),...
-
donc une intégration dans les GPU fin 2019 ou en 2020.
Sur les mobiles, Youtube n'utilise le VP9 que sur les smartphone qui ont une accélération hardware (les derniers modèles)
Pour Microsoft Edge, le VP9 n'est autorisé que si il y a une accélération hardware, pour préserver la batterie.
Bref, H264 et VP9 ont encore de beaux jours devant lui.
Oui, bien qu'avec l'adoption du HEVC par Apple, ce codec va voir une accélération.
L'attitude de Apple me dégoutte. Faire la pluie et le beau temps sur les techno (flash c'était pas une si mauvaise idée), les codecs, le hardware, la appli de son store, bloquer les moteurs de rendus des navigateurs concurrents (idée reprise par Microsoft dans Windows S),…
"dégoûte" : attention au jugement de valeur et interprétation personnelle quant à une stratégie d'entreprise. Toujours piègeux.
Faire la pluie et le beau temps, c'est l'apanage des acteurs de poids. Surtout devant des consortiums qui mettent des années à accoucher d'un consensus moisi, le plus souvent. Pour rester sur la question du codec HEVC, Apple a adopté le résultat d'un travail qui n'a pas été interne ni propriétaire.
L'efficacité du H.264 devient un problème avec les résolutions de type 4K. Ils ont décidé d'avancer avec un codec qui n'émanait pas d'un concurrent (VP9/Google). Raisonnable, me semble-t-il.
-
On peut aussi voir que les royalties demandés ne permettent pas a Firefox de décoder le H.265. C'est donc un moyen de bloquer un concurrent de Safari.
Coté IPv6, on pourrait citer le non support de 464XLAT chez Apple.
-
On peut aussi voir que les royalties demandés ne permettent pas a Firefox de décoder le H.265. C'est donc un moyen de bloquer un concurrent de Safari.
C'est le patent poll qui gère les royalties. Tu laisses entendre que c'est Apple en particulier, et en partie pour bloquer Firefox vs Safari. Tu interprètes. Et je suis à peu près certains qu'ils s'en foutent royalement, de Firefox. Mozilla n'existe réellement que sur du desktop et pratiquement pas sur mobile. Pas du tout une menace, surtout pas sur iOS.
À la présentation d'hier sur AV1, on était chez Mozilla d'ailleurs. Avec quelqu'un de l'équipe Firefox, et en effet, HEVC, c'est niet pour eux.
Coté IPv6, on pourrait citer le non support de 464XLAT chez Apple.
J'ai déjà posté quelque part sur le forum mon point de vue. Techniquement, je préfère leur choix. L'usage des addresses littérales dans les apps est une plaie. Et la politique d'Apple sur IPv6 a été signalé aux devs tiers depuis 2 ans. Aucune raison de faire du 464XLAT quand tu as mis tout ton écosystème d'accord depuis suffisamment de temps. Ça n'embête que les opérateurs mobiles qui doivent étoffer leur infra…
-
Google pourrait également bien me dégoûter avec son rétropédalage sur le XMPP ! Alors qu'on sait bien qu'ils l'ont fait uniquement pour bloquer le client Outlook de Microsoft.
Mais yrousse a raison, il ne faut pas y voir autre chose que les jeux de pouvoir des grands conglomérats, qui sont d'ailleurs bien plus que des jeux puisqu'ils ont des conséquences réelles sur leurs revenus, et sur les emplois de leurs salariés.
De ce point de vue il n'y en a pas un pour racheter l'autre, et il ne faut y ressentir nul dégout - juste du dépit qui doit nous faire réfléchir sur le bienfondé d'octroyer notre confiance à ces multinationales.
-
Google pourrait également bien me dégoûter avec son rétropédalage sur le XMPP ! Alors qu'on sait bien qu'ils l'ont fait uniquement pour bloquer le client Outlook de Microsoft.
Il y a des raisons de penser ça ? L'explication rationnelle pour moi était qu'en premier facteur Google Talk était un service peu plébiscité et vieillissant qui a été déprécié par Hangouts, en second facteur XMPP est un pur produit d'over-engineering qui n'est pas amusant à implèmenter, et qu'il n'était pas intéressant de continuer à le supporter et à l'étendre au vu de ce qui était requis par les évolutions fonctionnelles du service.
-
Et + de surface d’attaque = + de code à maintenir = + de bugs = + de possibilité d'avoir une faille de sécurité 0 day.
Firefox a déjà retiré des composants peu utilisés pour ça et a refusé d'intégrer le nouveau format d'image WebP pour cette raison (peu de gain par raport a l'ancien format d'image par rapport aux risques d'attaque supplèmentaire)
-
C'est le patent poll qui gère les royalties.
pour HEVC ?
-
pour HEVC ?
Oui. Le/Les patent polls et c'est bien ce qui gêne le déploiement du machin. Des décisions clefs ont été prises très tardivement.
Comme tu le sais, mattmatt73, l'adoption d'un codec, c'est aussi toute une industrie d'encodeurs, de distributeurs d'Origin/Edge servers, etc…
À priori, patent poll -> ces gens-là : https://www.hevcadvance.com (https://www.hevcadvance.com)
-
Oui. Le/Les patent polls et c'est bien ce qui gêne le déploiement du machin. Des décisions clefs ont été prises très tardivement.
Comme tu le sais, mattmatt73, l'adoption d'un codec, c'est aussi toute une industrie d'encodeurs, de distributeurs d'Origin/Edge servers, etc…
À priori, patent poll -> ces gens-là : https://www.hevcadvance.com (https://www.hevcadvance.com)
Non, c'est vrai ? Merci beaucoup pour ces précisions....
-
Non, c'est vrai ? Merci beaucoup pour ces précisions....
Je pensais aussi aux *autres* lecteurs qui pourraient être tentés de réduire ce périmètre à Apple vs Google. :P
-
Il y a des raisons de penser ça ? L'explication rationnelle pour moi était qu'en premier facteur Google Talk était un service peu plébiscité et vieillissant qui a été déprécié par Hangouts, en second facteur XMPP est un pur produit d'over-engineering qui n'est pas amusant à implèmenter, et qu'il n'était pas intéressant de continuer à le supporter et à l'étendre au vu de ce qui était requis par les évolutions fonctionnelles du service.
Principalement le fait que l'on puisse encore utiliser des clients XMPP pour se connecter à l'heure actuelle, mais que la federation ait été rapidement supprimée.
-
Principalement le fait que l'on puisse encore utiliser des clients XMPP pour se connecter à l'heure actuelle, mais que la federation ait été rapidement supprimée.
C'est peut-être alors une manifestation raisonnable du choix technique de maintenir un fonctionnement minimal du service tout en réduisant les coûts de maintenance, sur une période de transition. D'ailleurs peut-être qu'ils ont refondu en amont l'implèmentation frontale du service Google Talk, pour en faire une passerelle vers le nouveau service, réduite au minimum. C'est quelque chose de courant en ingénierie logicielle, sur les protocoles de messagerie (exemple MSN/Skype) ou les services web (exemple Google Maps/Maps Lite).