Chrome的第69版是一个重大更新 ，因为 显示了针对台式机和移动版的新界面。 Chrome 70并不那么激进，但其新功能非常重要。 我们进行了改编，并添加了我们认为最重要的新材料资料-支持AV1编解码器，这为性能树立了新的标杆。 到目前为止，仅在播放视频时才使用编解码器，但我们希望它能用于WebRTC-这将使我们有机会在视频通话和会议中使用高级编码（例如，使用
Web SDK ）。
支持AV1
大约10年前，Google推出了自己的H.264竞争对手编码解码器
-VP8 。 尽管技术竞争对手差别不大，但VP8是免费的，并且H.264需要许可证。 Android从2.3 Gingerbread开始支持VP8。 此外，所有主流浏览器（Safari除外）都可以播放VP8视频。
Google现在是开放媒体联盟的一部分，该联盟是一组公司，正在开发称为AV1的VP8 / VP9后继产品。
Facebook已经在数千个流行视频上测试了编解码器 ，发现与VP9相比，它的压缩率提高了30％以上，即分别提高了50.3％，46.2％和34％（与主要的x264配置文件相比， x264配置文件和libvpx-vp9）。
从Chrome 70开始，AV1编解码器支持台式机和Android的默认设置。 尽管编解码器要花很多时间才能广泛使用，但这仍然是重要的一步，因为 尚无其他浏览器支持AV1。
AV1详细
说明：本节摘自文章
下一代视频：AV1简介 。
亮度色度
来自亮度预测的色度（以下简称CfL）是AV1中使用的新的预测方法之一。 CfL根据亮度值预测图像中的颜色（色度）。 首先，对亮度值进行编码/解码，然后CfL尝试预测颜色。 如果尝试成功，则减少了需要编码的颜色信息量； 因此，节省了空间。
值得注意的是，CfL最初不在AV1中出现。 关于CfL的创始文件可追溯到2009年。 同时，LG和三星以
LM模式的名义提出了CfL的早期实施方案，但在HEVC / H.265的开发过程中，所有这些都被缩减了。 思科的Thor编解码器使用了类似的技术，HEVC已实现了一种称为跨通道预测（CCP）的改进版本。
改进的帧内预测
直到最近，视频压缩还是基于
帧间预测 ，即 当预测基于
参考帧时，根据帧与其他帧的差异进行比较。 尽管该技术发展迅速，但仍然需要不依赖于其他框架的参考框架。 结果，参考帧仅使用帧内预测。
测试视频的前60帧。 直方图以参考帧开始，比其他帧大20倍。参考框架比中间框架大得多-因此，它们尝试尽可能少地使用它们。 但是，如果参考帧很多，则会增加视频比特率。 为了解决此问题并减小参考帧的大小，编解码器研究人员致力于改善帧内预测（也可以将其应用于中间帧）。
综上所述，可以说CfL正是帧内预测的先进技术，因为 它根据
帧内的亮度工作。
彩色蜡笔
CfL的核心是基于合理，准确的预测对单色图像进行着色。 图像会跳成小块，在其中独立发生编码，这一事实有助于进行预测。
阻塞以最大化编码精度。由于编码器不能处理整个图像，而是可以处理其片段，因此足以显示小区域的相关性-足以预测色彩以获得明亮的亮度。 拍摄一个小图像块：
基于此片段，编码器将确定明亮=绿色，而黑暗则饱和度越小。 以此类推。
从CFL到AV1
CfL并未开始使用
PVQ算法，因此像素和频域的成本大致相同。 另外，AV1使用离散正弦变换和像素域标识变换，因此在频域中执行AV1 CfL并非易事。 但是-令人惊讶-AV1在频域中不需要CfL，因为 基本的CfL方程在这两个方面均能正常工作。
AV1中的CFL旨在尽可能简化重构。 为此，您必须显式编码α并在其基础上计算β，尽管...您无法计算β，但要使用编码器已经预测的DC色移（虽然精度较差，但仍适用）：
将默认DC预测（基于相邻像素的计算）与计算出的β值（基于当前块中的像素的计算）进行比较。因此，通过使用预测最大程度地优化了编码器侧的近似复杂度。 如果预测还不够，则执行其余的转换；否则，将执行其余转换。 如果预测没有提供位优势，则根本不使用预测。
一些测试
开放媒体联盟使用
一系列测试 ，
《我们是否压缩了吗？下表是在不同指标的情况下具有比特率的表。 注意CIE delta-E 2000，这是感知上均匀的颜色误差的度量。 值得注意的是如何保存比特率？ 高达8％！
| 率 |
| 信噪比 | 信噪比 | SIM卡 | 2000年 | 信噪比 | 信噪比 | 微软SSIM |
| 平均值 | -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 |
| 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 |
...以及Chrome 70中的其他新项目
Windows上的PWA
尽管对渐进式Web应用程序的支持主要在
移动平台上实现，但Google不会忘记桌面。 在桌面版Chrome 67中，出现了PWA安装按钮，而Chrome 70已经为Windows用户带来了一些改进。
现在，Chrome显示弹出窗口“安装应用程序？” （与您互动一段时间后）。 如果安装PWA，浏览器将在“开始”菜单中为PWA创建快捷方式。 与移动体验类似，浏览器界面将隐藏在开放的PWA中。
Google承诺在版本72中为Mac和Linux推出此功能。
形状检测API
Web应用程序通常可以使用机器学习的JS库来读取条形码并以不同的方式识别面部，但这可能会非常缓慢。 为了使此功能更易于访问和高效，Google在Chrome中引入了自己的功能-形状检测。
Chrome 70中
的Shape Detection API是一项原始试用版，即 它尚未准备好广泛使用。 该API可以定义3种类型的对象/图像-面孔，条形码和文本。 目前，兼容性因平台而异，因为OS需要定义对象的功能。 您可以在
此处尝试演示。
TLS 1.3
传输层安全性是一种协议，使您可以通过Internet安全地传输数据。 当您在HTTPS上使用该站点时，最有可能通过TLS发送数据。 Chrome 70支持上个月发布的TLS 1.3。
可以
在此处找到更改列表，但总的来说，1.3版提高了效率和安全性（例如，“赢得”了BREACH和CRIME，由于有了menstenebris，您可以再次对
https-译者注释使用压缩）。 建立连接所需的步骤更少，因此您可以注意到时间略有改善（当然，如果您访问的站点支持TLS 1.3）。 这是
与CloudFlare的区别的清晰比较：
随着TLS 1.3的发布，对旧功能（例如SHA1和MD5）的支持也停止了。 Google在
状态页上宣布了这一点：
TLS 1.3是一个多年项目，在制定标准的过程中，来自各个行业，研究小组和其他参与者的支持者聚集在一起。 以前，我们尝试过该标准的草案版本，但是当该标准完全实现后，我们最终可以在Chrome中实现它。
Firefox 60增加了对TLS 1.3（草案23）的支持，该协议于今年5月推出； 然后CloudFlare开始使用它。
其他功能
与往常一样，Chrome 70为用户和开发人员提供了创新功能。 以下是此更新中的其他更改的列表：
- 在页面至少与该API交互一次之后，语音合成API才会起作用。 该API通常用于移动设备上的垃圾邮件弹出窗口，具体取决于Chrome 66中的新自动播放策略 ；
- Macbook Pro上的Touch ID可以用作Web身份验证API中的登录方法；
- 如果页面处于全屏模式，则弹出窗口的外观会使页面退出全屏模式；
- AppCache不再可用于NOT https页面；
- 在Android设备上，用户代理中不再包含OC内部版本号（例如，“ NJH47F”），以防止浏览器被识别。 iOS上的Chrome浏览器将保留内部版本号“ 15E148”，而不是完全删除它以遵循Safari中的实现；
- 现在，MP4，Ogg和WebM容器支持opus音频；
- WebUSB现在使用单个工作人员的上下文，这应该提高生产力；
- Web蓝牙现在可以在Windows 10上运行；
- 新的桌面同步对话框；
- 可以给服务人员起名字；
- 凭据管理API现在支持PublicKeyCredential ；
- 自定义元素，HTML导入，navigator.getGamepads和Shadow DOM API的初始实现现已弃用；
- 现在可以使用标志＃enable-lazy-frame-loading和＃enable-lazy-image-loading启用延迟加载 。