La 69e version de Chrome était une grosse mise à jour , a montré une nouvelle interface pour les versions de bureau et mobiles. Chrome 70 n'est pas si radical, mais ses nouvelles fonctionnalités sont très importantes. Nous avons fait une traduction adaptée et ajouté du matériel sur le plus important, à notre avis, important dans la nouvelle version - la prise en charge du codec AV1, qui établit une nouvelle barre pour les performances. Jusqu'à présent, le codec ne sera utilisé que lors de la lecture de vidéos, mais nous espérons qu'il parviendra à WebRTC - cela nous donnera la possibilité d'utiliser un codage avancé dans les appels vidéo et les conférences (par exemple, en utilisant
notre SDK Web ).
Prise en charge AV1
Il y a près de 10 ans, Google a déployé son propre codec concurrent pour H.264 - c'était
VP8 . Alors que les concurrents technologiques n'étaient pas très différents, VP8 était gratuit et H.264 nécessitait une licence. Android a pris en charge VP8 hors de la boîte, en commençant par 2.3 Gingerbread. De plus, tous les principaux navigateurs (à l'exception de Safari) peuvent lire la vidéo VP8.
Google fait maintenant partie de l'Alliance for Open Media, un groupe de sociétés qui développe un successeur VP8 / VP9 appelé AV1.
Facebook a déjà testé le codec sur des milliers de vidéos populaires et a découvert qu'il donne une augmentation de la compression de plus de 30% par rapport à VP9, à savoir de 50,3%, 46,2% et 34% (par rapport au profil x264 principal, haut- profil x264 et libvpx-vp9, respectivement).
À partir de Chrome 70, le codec AV1 prend en charge la valeur par défaut pour le bureau et Android. Et bien que le codec mettra du temps à être largement utilisé, il s'agit toujours d'une étape importante, car aucun autre navigateur ne prend en charge AV1 pour le moment.
AV1 en détail
Explication: Cette section est extraite de l'article
vidéo de nouvelle génération: Présentation d'AV1 .
Chroma de luma
La chrominance de la prédiction Luma (ci-après - CfL) est l'une des nouvelles méthodes de prévision utilisées dans AV1. CfL prédit les couleurs d'une image (chroma) en fonction d'une valeur de luma. Tout d'abord, les valeurs de luminance sont codées / décodées, puis CfL tente de prédire les couleurs. Si la tentative réussit, la quantité d'informations sur les couleurs à coder est réduite; par conséquent, l'espace est économisé.
Il convient de noter que CfL n'est pas apparu pour la première fois dans AV1. Le document fondateur sur CfL remonte à 2009; en même temps, LG et Samsung ont proposé une implémentation précoce de CfL sous le nom de
LM Mode , mais tout cela a été réduit pendant le développement de HEVC / H.265. Le codec Thor de Cisco utilise une technique similaire et HEVC a implémenté une version améliorée appelée Cross-Channel Prediction (CCP).
Amélioration de la prédiction intra
Jusqu'à récemment, la compression vidéo était basée sur
la prédiction inter-images , c'est-à-dire sur la différence de la trame par rapport aux autres, lorsque la prédiction est basée sur
des trames de référence . Malgré le fait que cette technique s'est développée rapidement, elle nécessite toujours des référentiels qui ne dépendent pas d'autres référentiels. Par conséquent, les trames de référence utilisent uniquement la prédiction intra-trame.
Les 60 premières images de la vidéo de test. L'histogramme commence par un cadre de référence ~ 20 fois plus grand que le reste.Les cadres de référence sont beaucoup plus grands que les cadres intermédiaires - ils essaient donc de les utiliser le moins possible. Mais s'il y a beaucoup de trames de référence, cela augmente le débit vidéo. Afin de faire face à cela et de réduire la taille des trames de référence, les chercheurs du codec se sont concentrés sur l'amélioration des prévisions intra-trame (qui peuvent également être appliquées aux trames intermédiaires).
En résumé, on peut affirmer que CfL est précisément la technique avancée de prévision intra-trame, car Il fonctionne en fonction de la luminosité
dans le cadre .
Crayons de couleur
CfL est à la base la coloration d'une image monochrome basée sur une prédiction raisonnable et précise. La prédiction est facilitée par le fait que l'image bat en petits blocs dans lesquels l'encodage se produit indépendamment.
Blocage pour maximiser la précision du codage.Étant donné que l'encodeur ne fonctionne pas avec l'image entière, mais avec ses fragments, il suffit de révéler des corrélations dans de petites zones - cela suffit pour prédire les couleurs pour une luminosité bénie. Prenez un petit bloc d'image:
Sur la base de ce fragment, le codeur établira que lumineux = vert et plus sombre, moins de saturation. Et donc avec le reste des blocs.
CFL à AV1
CfL n'a pas commencé à utiliser l'algorithme
PVQ , donc les coûts pour les domaines pixel et fréquence sont approximativement les mêmes. De plus, AV1 utilise une transformation sinusoïdale discrète et une transformation d'identité de domaine de pixels, il n'est donc pas très facile d'effectuer AV1 CfL dans le domaine de fréquence. Mais - une surprise - AV1 n'a pas besoin de CfL dans le domaine fréquentiel, car Les équations de base de CfL fonctionnent également dans les deux domaines.
CFL dans AV1 est conçu pour simplifier autant que possible la reconstruction. Pour ce faire, vous devez coder explicitement α et calculer β sur sa base, bien que ... Vous ne pouvez pas calculer β, mais utilisez plutôt le décalage de couleur DC déjà prédit par l'encodeur (il sera moins précis, mais toujours adapté):
Comparaison de la prévision DC par défaut (calcul basé sur les pixels voisins) avec la valeur β calculée (calcul basé sur les pixels dans le bloc actuel).Ainsi, la complexité de l'approximation côté codeur est optimisée au maximum grâce à l'utilisation de la prédiction. Si les prévisions ne suffisent pas, les transformations restantes sont effectuées; si la prédiction n'apporte aucun avantage en bits, elle n'est pas du tout utilisée.
Quelques tests
L'Open Media Alliance utilise une
série de tests , qui sont également disponibles dans le
Are We Compressed Yet?Voici un tableau avec un débit binaire dans le contexte de différents indicateurs. Faites attention au CIE delta-E 2000, c'est une métrique d'erreur de couleur perceptuellement uniforme. Vous voyez comment le débit binaire est enregistré? Jusqu'à 8%!
| Taux bd |
| PSNR | PSNR-HVS | SSIM | CIEDE2000 | PSNR Cb | PSNR Cr | MS SSIM |
| Moyenne | -0,43 | -0,42 | -0,38 | -2,41 | -5,85 | -5,51 | -0,40 |
| 1080p | -0,32 | -0,37 | -0,28 | -2,52 | -6.80 | -5,31 | -0,31 |
| Écran 1080p | -1,82 | -1,72 | -1,71 | -8,22 | -17,76 | -12,00 | -1,75 |
| 720p | -0,12 | -0,11 | -0,07 | -0,52 | -1,08 | -1,23 | -0,12 |
| 360p | -0,15 | -0,05 | -0,10 | -0,80 | -2,17 | -6,45 | -0,04 |
... et d'autres nouveautés dans Chrome 70
PWA sur Windows
Bien que la prise en charge de Progressive Web Apps soit principalement mise en œuvre sur
les plates -
formes mobiles , Google n'oublie pas le bureau. Dans le bureau Chrome 67, le bouton d'installation PWA est apparu, et déjà Chrome 70 a apporté plusieurs améliorations pour les utilisateurs de Windows.
Maintenant, Chrome affiche la fenêtre pop-up "Installer l'application?" pour PWA (après avoir interagi avec eux pendant un certain temps). Si vous installez PWA, le navigateur créera un raccourci pour PWA dans le menu Démarrer. Semblable à l'expérience mobile, l'interface du navigateur sera masquée dans PWA ouvert.
Google promet de déployer cette fonctionnalité pour Mac et Linux dans la version 72.
API de détection de forme
Les applications Web peuvent lire des codes-barres et reconnaître des visages de différentes manières, généralement à l'aide de bibliothèques JS d'apprentissage automatique, mais cela peut fonctionner très lentement. Pour rendre cette fonctionnalité plus accessible et plus productive, Google présente sa propre fonctionnalité de détection de forme Chrome.
L'API de détection de forme dans Chrome 70 est un essai d'origine, c'est-à-dire il n'est pas encore prêt pour une utilisation généralisée. L'API peut définir 3 types d'objets / images - visages, codes-barres et texte. À l'heure actuelle, la compatibilité varie selon les plates-formes, car le système d'exploitation nécessite des fonctionnalités pour définir des objets. Vous pouvez essayer la démo
ici .
TLS 1.3
Transport Layer Security est un protocole qui vous permet de transférer des données en toute sécurité sur Internet. Lorsque vous utilisez le site sur HTTPS, les données sont probablement envoyées via TLS. Chrome 70 prend en charge TLS 1.3, qui a été publié le mois dernier.
La liste des modifications est disponible
ici , mais en général, la version 1.3 améliore à la fois l'efficacité et la sécurité (par exemple, BREACH et CRIME "won", grâce auxquels vous pouvez à nouveau utiliser en toute sécurité la compression sur https -
commentaire du traducteur , grâce à
menstenebris ). Moins d'étapes sont nécessaires pour établir une connexion, vous pouvez donc remarquer une légère amélioration dans le temps (si le site que vous avez visité prend en charge TLS 1.3, bien sûr). Voici une comparaison claire des différences
avec CloudFlare :
Avec la sortie de TLS 1.3, la prise en charge des anciennes fonctionnalités, telles que SHA1 et MD5, cesse également. Google l'a annoncé sur la
page d'état :
TLS 1.3 était un projet pluriannuel qui a réuni des partisans de diverses industries, des groupes de recherche et d'autres participants tout en travaillant sur la norme. Auparavant, nous avions expérimenté des versions préliminaires de la norme, mais lorsque la norme a été entièrement mise en œuvre, nous pouvons enfin l'implémenter dans Chrome.
Firefox 60 a ajouté la prise en charge de TLS 1.3 (ébauche 23), qui a été déployé en mai de cette année; puis CloudFlare a commencé à l'utiliser.
Autres fonctionnalités
Comme toujours, Chrome 70 comprend des innovations pour les utilisateurs et les développeurs. Voici une liste des autres modifications apportées à cette mise à jour:
- L'API de synthèse vocale ne fonctionnera pas tant que la page n'aura pas interagi au moins une fois avec cette API. Cette API est souvent utilisée pour les fenêtres publicitaires intempestives sur les appareils mobiles jusqu'à la nouvelle stratégie de lecture automatique dans Chrome 66;
- Touch ID sur Macbook Pro peut être utilisé comme méthode de connexion dans l'API d'authentification Web;
- si la page est en mode plein écran, l'apparition de pop-up fera sortir la page du plein écran;
- AppCache ne fonctionne plus sur les pages NON https;
- sur les appareils Android, le numéro de version OC (par exemple, «NJH47F») n'est plus inclus dans l'agent utilisateur pour empêcher l'identification du navigateur. Chrome sur iOS laissera le numéro de build "15E148" au lieu de le supprimer complètement afin de suivre l'implémentation dans Safari;
- L'opus audio est désormais pris en charge pour les conteneurs MP4, Ogg et WebM;
- WebUSB utilise désormais le contexte d'un travailleur individuel, ce qui devrait augmenter la productivité;
- Web Bluetooth fonctionne désormais sur Windows 10;
- nouvelle boîte de dialogue de synchronisation du bureau;
- on peut donner des noms aux travailleurs des services;
- L'API de gestion des informations d'identification prend désormais en charge PublicKeyCredential ;
- les implémentations initiales des éléments personnalisés, les importations HTML, navigator.getGamepads et l'API Shadow DOM sont désormais dans un état obsolète;
- Le chargement différé peut désormais être activé à l'aide des indicateurs # enable-lazy-frame-loading et # enable-lazy-image-loading .