La versión 69 de Chrome fue una gran actualización , ya que mostró una nueva interfaz para escritorio y versiones móviles. Chrome 70 no es tan radical, pero sus nuevas características son muy importantes. Hicimos una traducción adaptada y agregamos material sobre lo más importante, en nuestra opinión, importante en la nueva versión: soporte para el códec AV1, que establece una nueva barra para el rendimiento. Hasta ahora, el códec se usará solo cuando se reproduzca video, pero esperamos que llegue a WebRTC; esto nos dará la oportunidad de usar codificación avanzada en video llamadas y conferencias (por ejemplo, usando
nuestro SDK web ).
Soporte AV1
Hace casi 10 años, Google lanzó su propio códec de la competencia para H.264: era
VP8 . Si bien los competidores tecnológicos no eran muy diferentes, VP8 era gratuito y H.264 requería una licencia. Android apoyó VP8 fuera de la caja, comenzando con 2.3 Gingerbread. Además, todos los principales navegadores (con la excepción de Safari) pueden reproducir videos VP8.
Google ahora es parte de Alliance for Open Media, un grupo de compañías que está desarrollando un sucesor VP8 / VP9 llamado AV1.
Facebook ya probó el códec en miles de videos populares y descubrió que aumenta la compresión en más del 30% en comparación con VP9, es decir, en un 50,3%, 46,2% y 34% (en comparación con el perfil principal x264, alto- perfil x264 y libvpx-vp9, respectivamente).
A partir de Chrome 70, el códec AV1 admite el valor predeterminado para escritorio y Android. Y aunque el códec llevará tiempo para ser ampliamente utilizado, este sigue siendo un paso importante, porque Ningún otro navegador soporta AV1 todavía.
AV1 en detalle
Explicación: Esta sección es extractos del artículo
video de próxima generación: Presentación de AV1 .
Croma de luma
La predicción de croma de Luma (en adelante, CfL) es uno de los nuevos métodos de pronóstico utilizados en AV1. CfL predice colores en una imagen (croma) basándose en un valor de luma. Primero, los valores de luminancia se codifican / decodifican, luego CfL intenta predecir los colores. Si el intento tiene éxito, se reduce la cantidad de información de color que debe codificarse; por lo tanto, se ahorra espacio.
Vale la pena señalar que CfL apareció por primera vez no en AV1. El documento fundador sobre CfL se remonta a 2009; Al mismo tiempo, LG y Samsung propusieron una implementación temprana de CfL bajo el nombre de
Modo LM , pero todo esto se redujo durante el desarrollo de HEVC / H.265. El códec Thor de Cisco utiliza una técnica similar, y HEVC ha implementado una versión mejorada llamada Predicción de canales cruzados (CCP).
Predicción intra mejorada
Hasta hace poco, la compresión de video se basaba en
la predicción entre cuadros , es decir. en la diferencia del marco de otros, cuando la predicción se basa en
marcos de referencia . A pesar del hecho de que esta técnica se ha desarrollado rápidamente, todavía requiere marcos de referencia que no dependen de otros marcos. Como resultado, los marcos de referencia utilizan solo la predicción dentro del marco.
Los primeros 60 cuadros del video de prueba. El histograma comienza con un marco de referencia ~ 20 veces más grande que el resto.Los marcos de referencia son mucho más grandes que los intermedios; por lo tanto, intentan usarlos lo menos posible. Pero si hay muchos marcos de referencia, esto aumenta la tasa de bits del video. Para hacer frente a esto y reducir el tamaño de los marcos de referencia, los investigadores de códecs se centraron en mejorar el pronóstico dentro del marco (que también se puede aplicar a los marcos intermedios).
En resumen, se puede argumentar que CfL es precisamente la técnica avanzada de pronóstico dentro del marco, porque Funciona en función del brillo
dentro del marco .
Lápices de colores
CfL en su núcleo es el color de una imagen monocroma basada en una predicción razonable y precisa. La predicción se ve facilitada por el hecho de que la imagen late en pequeños bloques en los que la codificación se produce de forma independiente.
Bloqueo para maximizar la precisión de codificación.Dado que el codificador no funciona con toda la imagen, sino con sus fragmentos, es suficiente para revelar correlaciones en áreas pequeñas; esto es suficiente para predecir los colores para un brillo bendecido. Tome un pequeño bloque de imagen:
Basado en este fragmento, el codificador establecerá que brillante = verde, y cuanto más oscuro, menos saturación. Y así con el resto de los bloques.
CFL a AV1
CfL no comenzó a usar el algoritmo
PVQ , por lo que los costos para los dominios de píxeles y frecuencia son aproximadamente los mismos. Además, AV1 utiliza una transformación senoidal discreta y una transformación de identidad de dominio de píxeles, por lo que no es muy fácil realizar AV1 CfL en el dominio de frecuencia. Pero, una sorpresa, AV1 no necesita CfL en el dominio de frecuencia, porque Las ecuaciones básicas de CfL funcionan igualmente en ambas áreas.
CFL en AV1 está diseñado para simplificar la reconstrucción tanto como sea posible. Para hacer esto, es necesario codificar explícitamente α y calcular β sobre la base de esto, aunque ... No puede calcular β, sino utilizar el cambio de color DC ya predicho por el codificador (será menos preciso, pero aún así adecuado):
Comparación del pronóstico DC predeterminado (cálculo basado en píxeles vecinos) con el valor β calculado (cálculo basado en píxeles en el bloque actual).Por lo tanto, la complejidad de la aproximación en el lado del codificador se optimiza al máximo mediante el uso de la predicción. Si el pronóstico no es suficiente, se realizan las transformaciones restantes; Si la predicción no proporciona beneficios en bits, entonces no se utiliza en absoluto.
Algunas pruebas
Open Media Alliance utiliza una
serie de pruebas , que también están disponibles en
Are We Compressed Yet?A continuación se muestra una tabla con una tasa de bits en el contexto de diferentes indicadores. Preste atención a CIE delta-E 2000, esta es una métrica de error de color perceptualmente uniforme. ¿Se nota cómo se guarda la tasa de bits? ¡Hasta 8%!
| Bd-rate |
| PSNR | PSNR-HVS | SSIM | CIEDE2000 | PSNR Cb | PSNR Cr | MS SSIM |
| Media | -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 |
| Pantalla de 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 |
... y otros artículos nuevos en Chrome 70
PWA en Windows
Aunque el soporte para Progressive Web Apps se implementa principalmente en
plataformas móviles , Google no se olvida del escritorio. En el escritorio Chrome 67, apareció el botón de instalación PWA, y Chrome 70 trajo varias mejoras para los usuarios de Windows.
Ahora Chrome muestra la ventana emergente "¿Instalar aplicación?" para PWA (después de interactuar con ellos durante un tiempo). Si instala PWA, el navegador creará un acceso directo para PWA en el menú Inicio. Similar a la experiencia móvil, la interfaz del navegador estará oculta en PWA abierto.
Google promete implementar esta funcionalidad para Mac y Linux en la versión 72.
API de detección de forma
Las aplicaciones web pueden leer códigos de barras y reconocer caras de diferentes maneras, generalmente utilizando bibliotecas JS de aprendizaje automático, pero esto puede funcionar muy lentamente. Para que esta función sea más accesible y productiva, Google está introduciendo su propia funcionalidad en la detección de forma de Chrome.
La API de detección de forma en Chrome 70 es una prueba de origen, es decir aún no está listo para su uso generalizado. La API puede definir 3 tipos de objetos / imágenes: caras, códigos de barras y texto. Por el momento, la compatibilidad varía entre plataformas, porque el sistema operativo requiere funcionalidad para definir objetos. Puedes probar la demo
aquí .
TLS 1.3
Transport Layer Security es un protocolo que le permite transferir datos de forma segura a través de Internet. Cuando utiliza el sitio en HTTPS, lo más probable es que los datos se envíen a través de TLS. Chrome 70 es compatible con TLS 1.3, que se lanzó el mes pasado.
La lista de cambios está disponible
aquí , pero en general, la versión 1.3 mejora tanto la eficiencia como la seguridad (por ejemplo, BREACH y CRIME "ganó", gracias a lo cual puede volver a utilizar la compresión de forma segura en https -
comentario del traductor , gracias a
menstenebris ). Se requieren menos pasos para establecer una conexión, por lo que puede notar una ligera mejora en el tiempo (si el sitio que visitó es compatible con TLS 1.3, por supuesto). Aquí hay una comparación clara de las diferencias
de CloudFlare :
Con el lanzamiento de TLS 1.3, el soporte para funciones antiguas, como SHA1 y MD5, también cesa. Google anunció esto en la
página de estado :
TLS 1.3 fue un proyecto de varios años que reunió a simpatizantes de diversas industrias, grupos de investigación y otros participantes mientras trabajaban en el estándar. Anteriormente, experimentamos con versiones preliminares del estándar, pero cuando el estándar se implementó completamente, finalmente podemos implementarlo en Chrome.
Firefox 60 agregó soporte para TLS 1.3 (borrador 23), que se lanzó en mayo de este año; entonces CloudFlare comenzó a usarlo.
Otras características
Como siempre, Chrome 70 incluye innovaciones para usuarios y desarrolladores. Aquí hay una lista de otros cambios en esta actualización:
- La API de síntesis de voz no funcionará hasta que la página haya interactuado al menos una vez con esta API. Esta API se usa a menudo para ventanas emergentes de spammers en dispositivos móviles hasta la nueva política de reproducción automática en Chrome 66;
- Touch ID en Macbook Pro se puede utilizar como método de inicio de sesión en la API de autenticación web;
- si la página está en modo de pantalla completa, la aparición de una ventana emergente la sacará de la pantalla completa;
- AppCache ya no funciona en páginas NO https;
- en dispositivos Android, el número de compilación OC (por ejemplo, "NJH47F") ya no se incluye en el agente de usuario para evitar la identificación del navegador. Chrome en iOS dejará el número de compilación "15E148" en lugar de eliminarlo por completo para seguir la implementación en Safari;
- opus audio ahora es compatible con contenedores MP4, Ogg y WebM;
- WebUSB ahora usa el contexto de un trabajador individual, lo que debería aumentar la productividad;
- Web Bluetooth ahora funciona en Windows 10;
- nuevo cuadro de diálogo de sincronización de escritorio;
- los trabajadores de servicios pueden recibir nombres;
- La API de administración de credenciales ahora admite PublicKeyCredential ;
- las implementaciones iniciales de elementos personalizados, importaciones HTML, navigator.getGamepads y la API Shadow DOM ahora están en estado obsoleto;
- La carga diferida ahora se puede habilitar usando los indicadores # enable-lazy-frame-loading y # enable-lazy-image-loading .