会议纪要
会议开场（会议页面）
主持人：王子韬（W3C Web 中文兴趣组联合主席）
王子韬: 我来自华为，目前担任 W3C Web 中文兴趣组的联席主席，今天会议由我给大家主持。
请刚加入的同事按照会议要求，在Zoom栏上修改参会信息，建议使用【姓名+单位】的形式，这样我们后续的交流会方便记录。会议也会发出后续文字版纪要供大家参考。
会议上不建议大家使用录屏，因为有些讨论可能涉及到知识产权信息。但是会后我们会提倡参会者或者演讲者上传自己演讲的幻灯片，方便大家能够获取以及进一步的交流。 今天会议的日程已经发出，会议形式为讲者演讲，每个演讲后提供开放讨论环节，欢迎直接在Zoom上举手发言。本次讨论使用中文，提供实时的在线字幕。
由于时差原因，有一些海外讲者没有办法线上接入，所以我们安排了预录报告。第一个议题是 W3C WebXR标准和产业现状介绍，预录内容由三星的Ada Rose Cannon分享。
预录视频：WebXR现状与未来
讲者：Ada Rose Cannon（三星、W3C 沉浸式 Web 工作组及社区组主席）[视频资料]
Ada：大家好，我是三星浏览器的开发技术推广工程师，我也是W3C沉浸式Web小组的联合主席，这些小组在制定WebXR的API，能让你使用沉浸式Web技术，例如增强现实和虚拟现实。
这次演讲的主题是WebXR，重点探讨当下大家利用现有的API，能构建哪些应用，以及未来即将推出的新富特性。WebXR小组成立于2018年，旨在制定WebXR API。目标是将虚拟和增强现实特性引入Web。WebXR由早期的试验性WebVR API迭代而来，WebXR由早期的质言性WebVR API迭代而来，后者只针对于虚拟现实的头戴式设备，至2019年底，WebXR广泛支持虚拟现实技术。因此我们可以废弃此前的试验性WebVR API。
不久之后，增强现实特性开始崭露头角。支持使用增强现实头戴式设备以及手机。自那以后，许多新特性的研究仍在继续，这些工作是同时进行的，使许多特性得以同时开发。WebXR的核心是一项API，用于访问沉浸式技术的硬件功能，WebXR的使用与扩展现实设备的流行程度密切相关。比如Oculus Quest2，下面的曲线记录了去年虚拟现实的使用情况。Qculus Quest2于去年10月发售，这是一款非常流行的虚拟现实头戴设备，你可以看到随着越来越多的人购买这款硬件，WebXR设备API的使用逐步上升。
作为开发技术推广工程师以及标准制定组织成员，我们努力推动着对一些新的、更高级特性的开发和适配。但意外的是，反而是一些最简单的硬件和体验，得到了最为广泛的应用。在硬件方面，手机是最常用的设备，如简单的VR纸板头戴式设备，它支持安卓设备上的WebXR API，是虚拟现实最常见的应用之一。
基于手机的增强现实是现如今最广泛的增强现实应用，除了这些用户体验外，如今推出的最广泛流行的应用体验，是单一的360度视频或360度的3D视频，它们在简单的沉浸式硬件上的效果很好。尽管WebXR设备上API能够支持更为强大的沉浸式体验，我们今天所能见到的最为震撼的扩展现实，是由台式电脑驱动的，目前来说，这类用例偏少。但随着OpenXR获得越来越多的支持，建立在它之上的WebXR也会获得支持，希望也能更受欢迎。
薛富侨（W3C）：这里她列出了WebXR的核心、AR模块、游戏手柄、hit test、以及光照估计等等，之后她会逐一介绍一下。
Ada：关于你当下可以使用的特性以及如何使用，对于这里所列出的特性，我们会谈一下它们的内容及其功能，然后我会展示如何使用的对应代码示例，希望这有助于大家投入研究WebXR API。
首先，WebXR核心，这是第一个构建的WebXR模块，WebXR核心被设计成接入其他模块，并作为其他模块的底层运行，这种模块化的方法非常重要。因为WebXR技术还处于雏形，发展的非常快，至少和Web相比是这样，Web技术发展还是相对较为缓慢，要使用WebXR，使用挂载在window.navigator上的xr对象，你可以借此检测该会话是否支持WebXR，那么你可以用它来请求你想要的指定会话。
WebXR核心自身仅支持虚拟现实，增强现实由后来推出的增强现实模块支持，增强现实模块非常简单，它能让WebXR场景显示虚拟内容，例如使用WebXR在手机摄像上渲染，或是在透明显示器上展示，其中并没有任何增强现实的高级特性，这些是额外的WebXR模块，稍候我会讲到其中的很多模块。
调用增强现实和虚拟现实非常相似，与此前的immersive-vr会话不同，取而代之的是immersive-ar会话，因为调用增强现实和虚拟现实的，代码结构十分相似。要设计一种既能实现虚拟现实，又能实现增强现实的单一应用非常简单，以此可以触及到尽可能多的人。
接下来，我想谈谈DOM覆盖层。DOM覆盖层非常有趣，因为它允许你在场景中使用部分HTML，因为现在WebXR完全以WebGL为基础，没有对HTML和CSS的内置支持，这意味着任何你想构建的界面，都必须完全使用原生WebGL构建，DOM覆盖层可以让你在其中使用HTML和CSS，就好像它们全屏覆盖在窗口中。
目前只适用于手持设备增强现实，因为只有在该场景中才有意义。它的工作原理是，在启动会话的时候，你需要请求调用dom overlay特性，将DOM元素传递进来，设定是否在场景中全屏展示，这实际上给你的手持增强现实设备，加了三层显示，比如在智能手机上，在最顶层是HTML和CSS，将你所选的元素的全屏展示。在该层下方展示的是你的WebGL内容，由WebGL渲染并发送至WebXR设备API，在这层下面展示是设备的摄像信号，这可能看起来很简单，功能很有限，但这肯定算是个开头，因为在WebXR中使用HTML和CSS，是个难以解决的复杂问题。
下一个特性是针对于虚拟现实和增强现实，即游戏手柄支持，你可以从WebXR设备输入源，访问相应的游戏手柄对象，WebXR输入源可以是，用于访问场景的任何控制器，以及不同控制器的各种各样的设备，有一些是实体硬件，有点像一只手握着的游戏摇杆，上面还有按钮，它能检测到物体的位置和旋转。总之，这些物体上的所有按钮，都会被当作为gamepad对象，你可以获取按钮的压力和摇杆的运动，该API和现有的gamepad API几乎一样，所以应该非常容易上手。要获取gamepad的信息，从会话中获取输入源，如果输入源下有gamepad对象，这就意味着，它可能是带有实体按钮的物理硬件，这些按钮的状态信息，可以通过gamepad对象读取。
Ada：非常感谢大家的倾听，我希望这能引起你对WebXR的兴趣。许多3D图形代码库都内置支持WebXR，比如ThreeJS、AFrame、BabylonJS、PlayCanvas，如果你想尝试使用这些，可以看看这个网站immerseweb.dev，上面有一系列不同框架的入门指南。如果你想参与沉浸式Web标准化工作，你可以看看我们在Github上的工作成果，都是公开的，可以通过github.com/immersive-web访问。你可以订阅immersivebebweekly.com 的周报，每周二发布，你也可以加入沉浸式Web社区组或工作组，这些小负责制定相关的标准。
非常感谢大家的聆听，希望你在这次演讲中有所收获。谢谢！
王子韬：关于W3C WebXR相关工作，有什么问题大家可以提出，我也在此希望大家能够积极参与相关的标准研究以及产业工作，通过这种开放的讨论，能够把我们一些好的想法贡献到社区里面去，同时也希望大家能在相关的标准工作中有所感悟，有所得。谢谢大家！
跨平台移动 Web AR 的关键技术介绍及应用
讲者：黄亚坤（北京邮电大学）[演示文稿]
黄亚坤: 我今天主要是从移动Web AR关键技术及应用实现角度，以及Web目前的标准现状和存在的不兼容的相关内容与大家进行一个分享讨论，主要围绕以下三个方面展开。
目前AR的实现方式，要么就是头戴式，或者是专用设备级别，若我们想做普适化或者传播推广的话，它具有它天然的缺陷。另外一种就是现在移动终端上得各种APP，比如抖音，它们在直播的时候都会大量应用到AR的一些效果，但是这个大家基本上都是基于自己的AR引擎去做。因此，当想去做一些跨平台传播或者面向国外用户与市场的话，还是会存在跨平台问题。
从AR发展历程来看，实际上对于移动AR或者面向Web平台的AR越来越呈现跨平台轻量化的趋势。WebAR的出现引领着跨平台Web解决方案的发展，包括基于轻量级、普适化Web AR开放服务平台等。
通过这么一个简单的背景介绍，我们接下来主要是围绕AR目前关键技术实现进行介绍，以及后续包括我们在实际应用中做的一些工作和相关问题的讨论。现在一个主流的方式或者说大家常见的还是以纯前端的解决方案去实现，比如JSARTooIkit，它的流程还是很容易明显获得，主要还是围绕识别，然后跟踪，以及渲染。
目前来讲的话，识别都还是属于一个入口流程，更主要的是在于跟踪和渲染这一块，目前对于Web平台的算力也好或者说接口，实际上还是有很高的一个要求。我这边也列出来具体识别或者说跟踪涉及到目前一个比较主流或者说大家常见的一些前端库的情况。比如大家现在常见的或者比较经典的AR.js，它的性能还是很高，但实际上更多的一些例子里面，刚才所提到的JSARToolkit它是支持Pat marker和Nft marker的识别与跟踪。
然后就是Tracking.js，包括awe.js，增加了一些基于位置的服务，或者是传统计算机视觉等内容去不断的扩展，但本质来讲它与我们所说的专业设备级别或者说基于APP级别的实现效果还是有较大的差距。
除了刚才提到的基于纯前端或者说是基于现有标准的实现技术，大家从内核的角度去考虑问题，我们一般把它归为是扩展浏览器内核的方案。目前来讲，这一块实际上做的研究还是要少一点。包括Web AR，它通过封装Web接口，和我们今天所谈的议题还是很吻合的一种方式。
我们今天整个讨论会的主题是关于WebXR，刚才谈到的这两个都是属于在这种方式下去支持更多的这种体验。但是从AR角度来讲还没有本质上去提升，比如它能够具备的核心功能，目前这一块还没有特别好的支持。
实际上在W3C网络社区，我们之前去讨论，也是希望能够把AR或者WebAR这一块东西内能够跟5G做一些结合，端+边缘+云，这些也都是在初步讨论范围之内，之前我们跟他们做了一些讨论和交流。例如云AR、5G边缘云AR系统架构设计问题，包括时延、带宽需求等方面目前都处于初级的讨论阶段。
我们刚才看到的，无论是采用哪种方式，目前在Web上面还是会存在几个关键的问题，即浏览器的算力还是极其受限，如果去渲染一些比较复杂的模型，它还是存在挑战。时延和实时跟踪要求也是另一个挑战。此外，还有Web渲染引擎的问题，国内最关键的问题就是浏览器的兼容性，不同的应用里面的内置，这些接口都还是有很多的限制，导致我们做这一块还是有比较大的困难。
我们探索怎么在现有环境下去实现较为通用的跨平台WebAR，刚才所谈到的大多数前端库，我们为了把传统一些复杂的算法放到前端来，我们还是去重新设计了一下，怎么在已有的标准下或者已有的前端技术接口前提下，去实现比较高效率的Web AR框架。
我们在里面做了一些工作，但并没有一个特别的详细介绍。我们这边放了两个模型，左边是一个模型的放置和转动，这是在微信小程序，我们能够做到在小程序，在常见浏览器上面做到兼容。
（图）这个是平面位置跟踪的一个模型，左边是把模板匹配完以后，它放置的是一个模型，右边就是在这上面去贴一个视频。这里面还有一个视频没有放，你也可以让它斜起来，这个视频也是能够有一个比较好的贴合。
除此之外，我们还会考虑在建筑或者有些大模型，我们在Web平台上面会有大模型渲染的问题。除了从底层浏览器角度考虑，我们还能做的就是怎么把模型做一些分块，使得它有一个高效的加载，体验会更好。右边就是动画和模型分类渲染的一个方案，去解决目前在渲染这一块出现的问题。
（图）这是我们做了一个冬奥速滑馆的应用案例。我们在追踪也好，或者说是开发框架那一块，最大的限制就在于在Web浏览器上能够拿到的IMU的数据频率和精度太低了，那么这个频率现在是在60Hz之内。当我们用一些比较好的框架，它的频率要求会更高，比如要200Hz才会达到一个比较好的效果，那么我们从数据源角度来讲我们没有办法拿到的话，还是存在较大的问题。
目前来讲，我们更多是在运动补偿或者从其他角度进行算法优化。但如果说能从浏览器标准或者设备支持角度提供一些更好的方案的话，那还是能够促进我们在Web上去实现AR。
最后，我这边大概调研了一下目前W3C相关的标准，包括WebRTC，WebGL都有比较大的关系，主要围绕WebRTC、WebGL还有 Web3.0。扩展浏览器的方式，主要问题还是在于说不同浏览器厂商的内核扩展不兼容的问题。
我们在扩展浏览器方案里面，不兼容问题导致我们想要进一步的把跨平台体验做的特别好，还需要去进一步研究的。在实现方式里面，说到扩展标签，有Google他们之前做了一个，华为这边之前也是提了一些扩展标签的方式。
与Web AR或者跟5G相关的，基于端+边缘+云，AR需要从这个角度去考虑一些。大家有什么问题可以讨论交流一下。谢谢！
王子韬：感谢亚坤老师的分享，现在是交流时间，大家交流的时候请介绍一下自己的姓名和所在单位，谢谢。
冉若曦（W3C）：我想问一下小程序对AR或者VR支持最大的限制是什么？未来对这些小程序的厂商有什么样的期望就是在未来的部署中。
黄亚坤：小程序这一块，我们考虑在国内做跨平台，大家用微信或者不同APP的小程序，核心还是说计算能力。那么从计算能力来说，因为我们涉及到Web AR或者XR更多是矩阵运算，这一块我们会用到Web 3D加速技术，这一块大家还都没有一个特别好的标准，现在Web 3D标准还是针对浏览器上面的，对小程序来说并没有一个很好的标准，之前在微信上上个版本的时候还是能够基于老的Web3.0做一个不错的跟踪引擎，做出来的效果虽然没有到APP级别，但实际上还是能够有一个很不错的效果。但是当它最新版本一更新以后，又陷入到它自己做它自己的内容，不论是从文档还是对于我们的开发者来说，还是有很大的障碍。
在交流过程中，他要考虑自己的安全，有一些性能的东西他是不会开放的。这个时候我们又会抛弃掉之前一些想要做的东西。所以说小程序上面确实其中一个比较大的问题，就是我们想计算的一些东西它目前没有一个很好的支持。目前我们做的最主要突出还是Web3.0这一块，是导致有一个很大的限制。
第二个我谈到的，我们做传感器数据的获取，无论是我们在小程序也好，还是web上面，目前都难以达到AR达到好的效果的这种级别。如果精度过高或者数据频度过高，我们拿到这些数据确确实实从隐私方面会有一些顾虑，但是如果不去做一个好的权衡的话，我觉得我们做这个AR，想让它得到一个比较好的效果的话，目前还有很大的问题。这是从数据的获取这一块是一个大的问题。
第三个小程序目前在渲染这一块，它有它自己的模型，比如模型文件大小、传输限制上面，我们想做一些复杂的应用的话，目前它也做了它自己的一些限制，这也局限了我们想在小程序平台上去跑一些与web浏览器相同或相似的一个级别应用还是具有一定的差距。
总结来看，我们在小程序做这个事情，主要还是在算力上，这个算力主要就是WebAssmebly支持，还是没有一个好的标准，或者说目前还是在初步的阶段。第二就是数据获取的一些问题，第三就是在模型渲染这一块还是有一些限制。谢谢！
冉若曦：W3C也联合国内外厂商，成立了 W3C MiniApps（小程序/快应用）工作组，大家也在做一些相关的标准，如果你有这方面好的想法，也欢迎加入！
黄亚坤：我看了，我会随时关注，也会积极参与讨论这块的问题。谢谢！
王子韬：希望亚坤老师可以贡献自己的想法，可以补充到我们W3C的工作组上，可以进一步讨论。另一方面关于端侧的姿态获取，这相关的内容据我所知W3C还跟OGC，就是地理信息相关的国际组织有过合作，讨论相关的标准工作，这一块我建议大家可以关注一下相关的内容。
姜茂山（联想）：目前来说Web AR这一块的应用，移动端以后肯定是一个发展方向，那我们从你讲的这里面会有一些技术，比如获取的频率不够，需可能需要800Hz甚至1000Hz来达到，怎么让的底层的厂家，比如我们用手机也好，PC也好，来支持WebXR的推广，就是能支持它。因为你说的200K这个是安卓的设计，这个考虑到功耗，包括运维场景，他们可能都达不到这个。包括其他的VR厂家，他们都是自己去做一体机，他们自己想办法去解决这些问题。我们现在如果要大量推广WebAR或者XR这样一个场景，那对于底层设备的支持的话这是一个硬性要求。算力我可以解决，因为现在随便一个手机或者随便一个PC它都可以达到这个算力，我觉得这个不是一个限制。有没有一些厂家或者手机厂家，或者以后移动端想要做的一些厂家，能把它做成标准化这样一些工作。我们这边有一些合作吗？
黄亚坤：这是两个问题。第一方面，手机IMU或者传感器数据高频率获取的话，当然功耗问题这个确确实实会存在，所以现在会有一个限制。我们这个平台是基于浏览器，浏览器厂商他在这个接口上面目前没有一个很好的统一。我们想要达到的是，当然是越高越好。如果越高越好以后，对于底层硬件设备厂商来说他们难以接受。这是两个方面，第一方面我们希望有一个标准，无论与硬件厂商也好还是浏览器厂商也好，大家能够从开放接口上面制定一个统一标准。
前期我们做国标Web AR，联合了国内的小米等等厂商去讨论这些东西，目前还没有一个特别好的方案能够使得大家都能把它做成一个很统一的，至少能够支持多少、多少的标准。如果说传感数据我们不能够让它始终保持一个高频，我们现在做的工作能不能从算法角度考虑确确实实会存在这么一个限制。我们不是说让它一直拿这么高的频率，拿完以后我们在它一个比较好的姿态以后我们再采一些低频的，尽量去改善在web上的AR或者密集型计算的限制。
当然这一块想推起来，我们只能联合浏览器厂商去做。另外刚才谈到算力，其实算力是我们目前遇到最大的问题，我们的问题是基于web平台去做，这个的算力不是直接应用到手机本身，比如安卓手机现在的算力非常高，大量跨平台小程序上来讲，它很多接口算力还是做了一些限制，这个限制会导致差的数量级还是蛮高的。这就是说你想要有一个很好的跨平台性，现在W3C做一些标准工作，还有一些地方没有达到很好的支持。这个时候我并不能拿到像安卓算力60%甚至于40%，这可能都用不到，算力也是我们做AR密集型计算，比如从底层运算库来看，前端的JavaScript库，都还是非常低效的方式。我们做大量工作的目的，还是想提升在Web上面计算力的问题。
所以总结来说，您刚才问的问题非常好，这也是我们想把它做进一步推广的时候遇到的一个比较大的障碍。我们还是属于上层，只能在已有平台支持和标准底下去做事情，我们是想让它有一个很好的支持或者有一个统一的标准来方便我们去做这个事，但这些还是在浏览器厂商包括硬件厂商支持，才能进一步往前去推这个事情。谢谢！
姜茂山：我追问一下，目前Web应用主要是在PC上，在移动端真正的应用距离还比较远，是这个意思吗？
黄亚坤：可以这么说。我们现在Web上来讲的话，往后看它的一个大的趋势肯定大家不需要下载APP，直接扫一下分享就能体验了，包括现在有一些很好的AR导航应用，到某个商场我不需要下这些APP了，直接小程序微信扫一下。但是局限于刚才我讲的那几个问题，我们去做一些体验好的，就是追踪或者数据获取还是很难达到的。我们现在做的一些工作，主要还是在识别、渲染、模型放置，想在做一些更大的突破可能需要浏览器厂商和硬件设备一块去推动这个事。
姜茂山：了解。应用场景您这边讲的主要是针对没有头戴设备结合的一些东西。
徐阳（快手）：假如我们以云端计算的方式，现在5G网络传输对于我们WebXR的实现是在时延方面还是在带宽方面有更大的限制？以及它的差距是多少？是否可以通过CDN的调动策略？
黄亚坤：跟5G相结合去特升Web AR，相当于需要实时性很高的应用需求底下怎么去做这么一个事情。去年讨论的时候，这还是属于个兴趣小组的阶段。刚才讲到到底是时延还是带宽的问题？我们在做的过程中，我谈的实际上是我们自己做的一些体验过程中，说这个目前还是有一些问题。时延我们现在在测的XR或者AR这些时延的要求还是高于我们现在讲的，典型的就是AR游戏，它的时延要求目前我们实际测的边缘计算这些网络的时延抖动还是难以达到，与我们讲的理论值还是有一定差距的。
我们如果说基于cloud做实时的话，对于我们跨平台来讲有一个大的问题，手机的功耗问题是我们难以接受的。如果我们始终使用这种cloud的方式，把所有计算全部放到云端，这个时候手机功耗，你如果说只是体验几分钟还是可以的，但如果稍微多人的话，时间长一点，你的手机功耗是很大的。所以我们之前跟网络那边讨论的时候，在这一块可能会存在问题。
目前基于5G整个架构底下的WebAR或者cloud AR整个基础架构，现在有一些草案，包括有些白皮书去做这些事情，但还没有一个特别好的可以让我们大家很明显的知道这个东西在上面有非常大的提升。我觉得这个问题还需要跟网络社群那边去做进一步的沟通，我们怎么跟web AR包括XR的应用，性能指标我们更多关注的是延、抖动、带宽等等性能上的要求，去进一步的探讨，制定一个比较好的标准。
王子韬：来自聊天频道的提问，Web AR/VR上传感器上报数据频率推荐是多少？多少能满足基本的体验品质？
黄亚坤：200Hz，精度是9位，有的是能够高一点，在后面做追踪的时候，自动累计误差的时候会有一个很大的误差，所以说我们在做的过程中，如果让我们考虑这个标准的话，至少满足200Hz和9位精度这么一个数据。
WebXR 探索与实践
讲者：张浩（华为） [演示文稿]
张浩: 华为在AR、VR整个行业里面我们是作为一个设备厂商的角色，今天下午我的分享主要还是从设备厂商的角度来谈一谈我们在WebXR的探索和实践。前面黄老师的议题讲的非常好，我之前跟黄老师没有线下交流，但我觉得我这里面一些材料正好可以回应黄老师材料里面的一些问题，大家可以一起来探讨一下。
在讲华为在WebXR的探索和实践之前，我想先给大家介绍一下华为在AR、VR工作的现状。华为AR引擎跟苹果ARKit和谷歌ARCore定位是一样的，我们目前是全球三大移动设备AR开发平台之一，在中国国内可能是排第一的，我们看了一下谷歌ARCore支持的国内设备是比较少的，只有一些安卓厂商的旗舰有覆盖，很多中低端都没有覆盖，但是华为是全线覆盖，所以从覆盖设备量来说我们在国内可能是第一，目前是覆盖了87款华为和之前荣耀的设备。我们的应用数量，我们这里可以透露一个数据，我们从后台看到的应该是1600左右，活跃的接近500个三方应用，目前大概是这么一个情况。
（图）这些是国内厂商利用华为AR引擎做的应用，这个是京东做的室内家居摆放，包括百度也是调用了AR引擎做的百度室内导航，在华为手机上会调用华为的AR引擎。这是时尚杂志ELLE用华为AR引擎提供的2D图像识别与跟踪技术实现杂志里面的二次元人物复活。这是沃尔沃，利用华为AR引擎提供的3D物体的识别和跟踪能力，对一个真车做虚拟物体的叠加，在真车上叠加一些内容，在车的营销方面做了一个应用。
VR这一块，华为是在2019年底推出华为的VR Glass设备，现在接近两年过去了，轻薄短焦距设备目前在市场上能够量产的还看不到其他家，其他家的VR设备基本上是头显，我们是一个眼镜形态，重量只有166g，可以做近视调节，分辨率和象素目前来看还是领先的。
今年我们在VR Glass基础上推出一个6DOF配件，之前大家买过VR Glass设备的消费者，他只需要再购买一套6 DOF配件，主要是上面这个插件插到原来的VR Glass上，同时换上6DOF手柄，就可以把原来设备变成6DOF设备。从华为角度来看，华为是从底层的硬件，以前我们还有芯片，到OS，到AR、VR引擎的能力，包括AR引擎、VR引擎、渲染引擎和框架层，就是为了让开发者能更简单开发AR、VR应用，包括我们的云服务，还有我们的开发工具，还有我们的数据格式，还有3D物体重建服务，这些在华为开发者网站上面都是公开的，这是我们端对端为构建AR、VR应用提供了软件的一套框架。
在这个基础之上，我们对WebXR进行了一些技术路径的探索，这个正好可以对应上刚刚黄老师讲的那几条技术路线。一是通用浏览器WebXR上，我们进行过一些分析，它的好处是不依赖与系统和浏览器联合，它的兼容性非常高，但是它的问题，一个是性能问题，刚刚黄老师有讲到，我们可以去做一些优化。但是在Web应用这个层次上，它只能是语言性能上的优化，但是比如底层加速上，很多计算机视觉会用到深度学习，那你这一块往CPU上跑的话，这个性能还是有些问题的。它可能会依赖于现在正在进行当中的Web NN这些新的标准，在这些新的标准没有出来之前，在浏览器之上，用浏览器接口来调下面的话，性能确实还是有一个瓶颈在的。
另外一个就是刚刚黄老师也提到的，就是怎么样调用系统底层的这些硬件接口，比如IMU，在上层做到一个VIO的算法。我这边作为一个设备厂商的回应，我们觉得第一个问题IMU能够提供多少频率，这是一方面。另一方面IMU和Camera还需要保证时钟同步，如果不同步，仅仅一个频率指标可能还是不够的。
另外在上层如果来做这个SLAM算法的话，它还会面临一个标定的问题，你手里的设备是没有问题的。但是如果这个设备要推广，我们除了在手里这台设备商我们通过标定让它满足我们的需求之外，如果我们要推广到更多的设备上去，那就会面临一个标定的问题。因为不同设备它用到的IMU，用到的Camera之间会存在差异，那就没有办法做一个推广。
所以在这种场景下，基于通用浏览器的WebXR，它可以做一些简单场景，但是从性能，从精度这两个方面而言，它没有办法去做太复杂的一个场景。
第二条技术路线是在浏览器内核中实现XR支持，比如一些浏览器宣传支持WebVR，但是下面都有一个列表，我只支持这几个设备，那要再支持其他设备，那你设备厂商要跟我合作，要么你自己提交，你把你的算法或者是你的一些东西提交进来，提交到我的内核里面来。要么就是让我们合作，我把这个东西拿进来。那也有的设备厂商说我自己比较牛，我自己改，我自己给自己定制一个浏览器，比如像Facebook，他自己改一个浏览器来做他的官方浏览器来用。但是这种方式对设备厂商而言就存在几个问题：第一个问题是我作为一个设备厂商，我要不就得自己去改浏览器内核，或者说我要维护一个浏览器内核团队专门干这个事情，对设备厂商来说这是一个很大的资源付出，其实是不利于竞争的。我即使付出了资源，我只是在某个浏览器内核上做了这个算法，但是不可能把所有浏览器内核都做一遍，那就容易形成一个垄断，就是一个不好的竞争关系。所以我认为这个方式，从我们设备厂商角度来讲我们是不推荐这种方式的。浏览器内核必须要跟具体的设备进行解耦。
所以我们推荐的一个方式是最右边这个方式（系统能力适配的WebXR），也就是谷歌Chrome支持的WebXR Device API这种实现模式，它调用的是安卓里面的AR库，AR算法还是放在OS层，没有放在浏览器内核里面。但是这个方式谷歌他能做，第一安卓是他的，第二AR是他的，所以他很方便能够调到系统和算法。但是像我们华为，还包括其他的一些设备厂商，那怎么跟浏览器内核做对接？ 所以在这个地方我们认为是需要跟OpenXR合作的。
我们希望在算法之上有一个共同的API标准，我们作为设备厂商只需要对接这个标准就可以了。浏览器内核厂商只需要支持OpenXR，向上提供WebXR Device API，大家互相解耦，每一层都有通过一个标准接口进行解耦。因为设备厂商它自己的算法，它自己去做好标定和硬件适配工作，就不需要在应用层或者浏览器内核去做这些事情。因为标定这个事情，除了设备厂商能做之外，上层都没法做。因为标定会涉及到像前面提到的，除了我们获取那些API的参数之外，关键的一个问题，即使是同一个硬件，我们就拿手机来举例，同一个手机型号它可能会有不同的供应商，比如Camera是3个供应商，IMU就是3个供应商，那就是9种组合，9种组合都必须分别做标定，除了设备厂商之外，不管是内核层也好还是应用层也好，你都没法去市面上买9个组合的东西都能买得到，你可能买100个可能都是一种组合的，你都没法把这9中组合买全。你说你支持这一款设备，消费者买过去之后，用了你的这个算法，在所谓支持的这个型号上面跑起来都是有问题的。
所以我们认为这些东西应该是放到设备厂商，放到OS层来完成。上层尽量是通过能力调用，通过API传上去，这是从设备厂商角度来讲认为这是一个合适的方式。我们的一个探索，主要是希望在WebXR标准制订过程当中能够跟OPenXR之间大家互相有一个合作，有一个沟通，我们用这种方式去做一个对接。
另一方面，现在WebXR它只是API的标准，现在整个3D也好，XR也好，它都是在都是在2D的Web上，重新挖了一个窗口，是HTML组建的一个2D的Web。我们是希望有一个真正的3D或者XR的场景语言，能够作为未来3D Web的一个描述。因为HTML只是针对文档的，它的操作对象是DOM，相对位置关系也是根据树状的关系来的，整个都是一个平面的东西。3D描述一个对象是一个场景，操作对象是Entity，锚点是虚拟世界跟真实世界一个锚定的关系，Entity之间不一定有直接的关系，会随着光照、主客体的位置会有一些变化。所以我们希望有一个更大胆的做法，我们做一个跟2D并列的一个3D的Web标准，就是直接跟HTML并列。
在这一块我们也作了一些尝试，我们做了一个叫RSDZ数据格式，它就是所谓的XR互动的场景描述语言，我们这一块的标准制定也是很开放的，目前1.0版本已经开放出来了，通过软件绿色联盟开放出来了。我们希望它的一个框架是基于ECS框架，它了面能支持物理引擎，它也是同样基于JS脚本语言，支持RBR材质，支持2D/3D UI控件及触发事件。刚才三星Ada讲了把DOM叠加到XR中，我们希望我们这个东西是WebXR有一个自己的空间，上面可以支持一些2D、3D的控件。
如果说我们有了这样一个场景语言描述之后，我们就可以用所见即所得开发RSDZ场景，这也是华为的一个实际案例，我们现在也有一个工具叫Reality Studio，让工程师直接通过3D内容在里面做场景搭建、动画制作、交互的开发，形成一个文件，这个文件就可以在我们端侧，最后通过端上XRKit运行时加载来做最终的一个呈现。
这是我们在过渡阶段的一个架构。在浏览器内核之上，我们现在还是说在HTML里面插入一个RSDZ标签，插到里面之后，它可以在HTML里面以3D的形式展示，但它如果以AR形式展示的时候，那点击之后跳转到一个原生页面，例如苹果AR Quick Look是应用间的跳转，我们是在华为浏览器内部去放这么一个原生的Activity，底层基于XRKit框架，实现应用内的跳转。我们设想的一个未来形态，就是把XRKit和3D渲染引擎放在浏览器内核当中，去支撑一个Web世界里面新的3D场景描述语言。
我们的总结和建议是：WebXR Device API和OpenXR这两个标准加强打通，如果大家有兴趣可以考虑跟HTML并列的一个3D/XR场景描述语言的标准。我的分享就到这里。
吴小倩（W3C）：您刚刚提到的3D描述语言，我记得两年前在W3C的年度技术大会里面介绍过，当时有几个并列的方案，像苹果、微软大家都提出了共同的设想，说想做一个类似的语言。因为当时大家都处于比较早期的探索阶段，回去整理一下和相关的实践，等到更成熟一点的时候再探讨一个共同的标准。两年以后，你们这边有没有更明确的一些标准化方向或者是国内厂商有没有类似的想法？这个描述语言最终的愿景是怎么样的？有没有一些您心目中标准化的一个时间线，我们这边非常乐意去提供协助。
张浩：我们目前的推动是在软件绿色联盟里面我们去做了一个发布，国内厂商像百度我们都有做过一些标准，包括京东，还有阿里，大家都在里面，这一块我们做了联合的一些定义。就整个来讲，这一块还是在一个早期阶段，我们希望大家都能参与进来。从我们的角度来讲，我们也是一个开放的定位，但是这一块还是需要有更多的应用把它驱动起来，然后逐渐驱动它成熟。大致的一些设想，我们跟两年前比的话，可能会更清晰一些，3D的语言，比如基于ECS框架来构建，两年前我们还没有定位到这么清晰。这是我们现在进一步确定的。
未来除了像图形的渲染之外，因为AR、VR涉及到声音的渲染，甚至涉及到一些触觉的渲染，我们在框架上都考虑了，都是可以包括在里面的。这一块我们还是希望有更多厂商大家一起来努力，因为仅靠我们，我们毕竟是个设备厂商，像上层的语言，我们还是希望应用厂商能够多参与进来，大家一起去推。让应用场景来推动它成熟，从我们单纯一个设备厂商来讲，靠自己的力量是不够的。
吴小倩：您刚刚提到绿色软件联盟这边有没有可以在线看到的文档或者案例，它是完全对外开放的吗？
张浩：是的。
王子韬：我也建议如果有机会的话，能够和W3C互发联络函，派遣观察员，包括后续在W3C大会上可以组织联合议题一起讨论有没有后面共同孵化一个国际化标准的可能，这是我个人建议。
乔秀全（北邮）：张浩您好，咱们又见了，我发现你们现在理的这个思路比较清晰，我觉得也比较好。你们现在相当于浏览器你们也在改，是吧？
张浩：说实话我们不希望去改浏览器，因为改动的话对我们难度比较大，所以我们才呼吁要大家最好能够定义标准接口来划清各自的边界。
OpenXR有在做，但它也是在一个早期，VR方面它做的工作多一点，AR方面还没什么进展。AR相当于还没有制定，还是一个比较前期的状态。所以我们希望这两个标准能够互相打通起来，从我们的角度来看，我们现在看到像ARCore的API，包括华为的这一套API，如果要把它统一起来做到OpenXR标准里面，就是基于现有的，还有苹果AR Kit，能够把它统一起来，浏览器内核就只需要去支持OpenXR就行了，我们是这么希望、呼吁。
乔秀全：只是一个想法，现在还没有实际做这样的工作，是吧？
张浩：OpenXR的工作也在做，我们也会推动OpenXR在制定AR的时候跟WebXR打通。
乔秀全：华为这边的浏览器组有什么动静吗？
张浩：我们现在对内核的改动不多，我们还是希望通过标准来推动，而不是直接去干。
乔秀全：我看手机上你们自己默认带了一个华为浏览器，那这个浏览器里面跟你们这个想法是不是也在做这样的工作？和你们底层是不是在协同，还是说只是你们部门的想法？
张浩：我们做的事情还是在应用层里面做的，就像HTML嵌入RSDZ，跳传到原生页面，我们还没有放到内核里面去，没有动这个。
乔秀全：你们现在发布的华为浏览器上，还体验不了你们的这些功能，是吧？跳转的这个能体验吗？
张浩：目前我们没有对发布，只是内部的。但是像XRKit这个我们是发布的，如果有三方基于XRKit开发一个自己的应用，他可以做这个事情。但是我们官方浏览器还没有正式的放出来。
王子韬：群聊频道阿里的同学提问，华为小程序/快应用在AR这块有甚么探索吗？
张浩：小程序/快应用我们提供的建议也是跳转这种模式，小程序它也是扩展了很多原生的组件和原生的API，所以我们目前的建议还是说这一块跳出来做，如果小程序厂商愿意跟我们一起来打通这一块，AR这边制定一个标准，一起来打通也是可以的。因为华为目前这一块，就像我们快应用上也是一个跳转方式，因为目前来说是工作量最小的。如果要改小程序/快应用引擎的话，我们也欢迎大家联合来改引擎，因为这个存在一些工作量，如果阿里有同学愿意在阿里小程序上跟我们一起来合作，联合做这个事情我们也是很欢迎的。
王子韬：群聊频道提问，如果以跳转的方式，RSDZ里面可以包含业务逻辑，以及GUI交互？
张浩：我们现在的业务逻辑主要是能做一些互动，整体来说肯定不会太复杂，能做一些动画，像之前我们发布过一个踢瓶盖，这是两个不同模型，我们可以把它连在一起，让他把这个瓶盖踢飞，制作这么一个动画，这是我们之前做模型的时候是这么做的。2D的控件，通过点击之后可以触发一些事件，它可以发一些事件出去，但是不能做太复杂的逻辑，我们希望后面能把脚本这一块的支持做进来，JS引擎做进来。
关于体积视频 - WebXR 中的沉浸式内容
讲者：邵志兢（普罗米修斯视觉） [演示文稿]邵志兢：我来自深圳普罗米修斯视觉，今天和大家聊一下体积视频在 WebXR 中的沉浸式应用。什么是体积视频？（视频）这是一个小姐姐跳舞的视频，不同的是，它是用 three.js 渲染的一个三维场景和三维人物，它的每一帧都不是图片，而是三维模型，我们可以把这个小姐姐放在一个虚拟场景里面。体积视频这个词翻译于 Volumetric Video，Volumetric Video 是三维的视频格式，为了制作这样一种视频格式，我们是用了上百个摄像头对演员进行环绕拍摄和建模。这是一个全新的体验，会带来很多商业场景。
（图）这个图片是我们搭建的一个专业级摄影棚，由 80 个相机组成阵 列，可以支持中间 2 米直径区域的拍摄和建模。一般来说，单人表演 者的模型使用 2-3 万个面，最高可以做到 10 万个面，但是为了播放性 能和功耗上面的考虑，一般用到 2-3 万个面（就是模型上的三角 面）；配套的纹理一般用到 4K。我们在北京搭建了一个摄影棚，8 月 底会开放。
每一个模型都是体积视频的一帧，对于零散的三维模型流的这种形 式，当前还没有一个统一的标准，没有一个标准的文件格式，所以为 了更好把这些数据压缩到一起，以及更好的分发，我们是定义了一种 我们自己的文件格式。简单来说，我们把纹理图当成视频一样，压缩 成 MP4，把模型写入 MP4 附加信息里面，就是 SEI 这个区域，SEI这个区域一般用来写视频的一些，比如说直播的时候会有一些弹幕， 还有用户留言，这些留言就写在 MP4 的附加信息，就是 SEI 里面。我 们现在就是把模型写到 SEI 里面。我们这个魔改版的 MP4，可以对纹 理提供最好的压缩比，并且 MP4，适合于各种视频云 CDN 进行穿 发。支持在 H5 播放，支持 XR 使用的场景。
体积视频核心意义就是将真人带入三维虚拟世界，我们可以和传统游 戏领域的做法做一个对比。传统的三维建模如果做一个特别高仿真的 NPC。下面这个图，他们做了一个非常高质量的人物模型，制作周期 是非常长的，需要对演员进行非常精细的建模，不仅要建静态模型， 还要精修它的毛发系统、骨骼，身上各个区位的材质等等。一个非常 高质量的项目，一般制作周期都是半年起，成本非常高昂。而体积视 频拍摄相对便捷，我们拍几分钟三维模型序列，一般就是拍摄，算法 自动处理，再酌情加入一些美术手工的修复，制作周期就是几个小时 到几天，非常快。
原生高质量模型渲染在 Web 端是非常难以使用的，但是体积视频，因 为是静态模型流的解码和播放，所以体积视频在 Web 端播放是简单很 多。体积视频表比较适合表演类的内容，并不能像传统游戏数字资产 那样用骨骼进行随意驱动，所以在用途上面是有区别的。
这里是一个服装展示的例子，厂商提前请模特录好衣服的展示内容， 因为是三维的体积视频，所以用户可以从各个角度能够看出衣服的质 感、垂感。
接下来是我们配合移动和字节的同事为湖南省文化厅做的网页版的红 色故事，“半条被子”，我们请舞蹈老师来我们摄影棚里录制体积视频， 并根据历史遗址来进行场景建模，在 WebXR 里以现代舞的形式展现 这个故事。首先看这是一个 AR 场景，这是一个介绍页，这里我们做 了一个讲解员。刚才亚坤老师提到的 8th wall SDK，这个 SDK 是我们 找到 WebAR 体验最好的一个 SDK。前端想做好 SLAM 是很难的，像 IMU 数据它的采样频率非常高，它应该会采集半秒到 1 秒，整包丢出 来，所以它的时间戳要找准起点很难。手机的图像，比如在亮的地 方，它的曝光比较短，在暗的地方曝光比较长，如果你不知道手机摄 像头的曝光时间，时间戳也是拿不准的。另外手机摄像头因为是 Rolling Shutter 有行与行之间不同步的问题，也需要精细的时间戳。
接下来看的这个视频是这个故事的最后一幕。我们测试了几个主流的 浏览器，像苹果的 Safari、微软的 Edge、以及 Chrome，Firefox 支持 都是挺好的；国内的几个浏览器，像 QQ、UC 就不行，基本没无法打 开，所以在 WebXR、H5 这些支持方面，这几个国内浏览器完全没有 跟上。在微信内的支持还可以， VR 场景这个网址在微信内可以直接 播放；AR 场景在安卓手机上可以在微信内播放，苹果手机还不行。
刚才亚坤老师也提到云端串流的方式，这里是我们用 UE 做的一个渲 染，如果用到边缘计算以及云渲染的话，我们可以看到很好的画质。 这里场景是虚拟的三维场景，人物是用体积视频录制出来的三维人 物，因为它本身是一个三维模型，对光影有非常好的响应。
目前各家体积视频公司，大家都是在自定义文件格式。相较于现在主 流的视频文件来说，体积视频的码流还是比较大的。体积视频最低的 质量要在 10Mbps 左右，如果使用更高的纹理分辨率，它的码流就更 高了，大概上到 30、40Mbps 都是有的。高情商的说法，这种新媒体 格式比较适合 5G，但是从普及角度来说，肯定还需要从业者做更多努 力，压缩的方式以及文件格式都需要新的标准出现才可以。
我们在制作这样一个体积视频 Web 项目的时候也是遇到了不少困难， 主要分为视频解码和模型解码两个部分。视频部分，我们最开始尝试 用video标签来做，但是它的接口实在是太粗糙了，无法提供准确 的时间戳。唯一能够提供准确时间戳的函数叫 requestVideoFrameCallback，但是非常可惜这个函数目前还没有成为 正式的 H5 标准。因为我们把模型部分写到了视频的附加信息，也就 是 SEI 里面，也是没有 callback 可以得到的。所以我们做了 WebAssembly 软解视频，整个性能功耗就会比较高，在一些比较老 旧手机上它的播放是很难做到流畅的，并且它也有一些兼容性的问 题，有一些浏览器还是没有跟进上来的。
模型部分我们测试了 Draco 和 MeshOpt，Draco 比 MeshOpt 压缩比 会小很多，但是 Draco 解码速度比较慢，每秒 30 帧的解码，Draco 是 很吃力的。我们希望未来无论是硬件支持还是标准支持，希望模型跟 视频一样能够有浏览器支持的原生解码。
体积视频和 WebXR 有非常好的结合前景，无论是服装展示、AR 广告、沉浸式的内容，比如沉浸式的短剧或者是录制游戏的过场动画、NPC，以及真人讲解，虚拟场景的教育类互动课堂上，都有非常好的结合场景。总结来说，体积视频可以帮助大家将具有巨大商业价值的真人 IP 或者是一些重要人物，或者是一些值得记录的家庭的重要成员，将真人形象代入 WebXR，我们也相信一定能够激发出更多新鲜的玩法，更多年轻人喜欢的新媒体运营的方式，能够讲出新的好故事。
我今天的分享就是这些，谢谢大家。
王子韬：下面我们进入讨论时间。我有一个问题，刚才通过扫码体验 了一下体积视频在享有的一些实现。尤其在刚才“半条被子”的视频上， 我感觉扫码扫下来，想要加载完成这个视频，需要的时间特别长，这 部分主要的瓶颈是什么呢？是视频太大还是现有的浏览器没有办法很 好的适配？您认为这边主要的瓶颈是什么？
邵志兢：第一个瓶颈肯定是文件大小，那一个场景应该是有上百兆的 内容，我们现在的做法是将内容切成很多、很多个小段，我们设想的 是用户只要能加载一个小段，比如加载了整个时长的 1/10 或者 1/20 然后就开始播放，在播放的过程中继续加载后面的东西。这是我们这 样一个设想，但事实上的话有两个限制，第一个是网速，比如说用户 在播放第一小段结束之后，第二小段还没有下载完，这个网速的限制 一下就会让用户卡在这里。第二个就是手机解码的性能，虽然文件下 载完了，但是一段 5 秒钟的东西解码需要 6 秒，这就没有办法一边播 放一边解码来做。所以我们现在做的稍微保守一些，会要求用户先把 整段视频全部下载完，然后再一点一点播放。如果整个压缩比能做的更高，文件大小做的更小，或者在 5G 情况下，我们不用考虑文件大 小限制的话，就可以做到随时打开、随时播放。
另外手机性能的部分，我们现在测起来，发现微信内嵌浏览器的解码 性能大概是中等偏上，如果是其他一些手机原生的浏览器，如果能打 开的话，一般来说性能也会差很多，这里面有浏览器内核优化的问 题。主要是这样的。
徐阳：我想请教一下，您这边这个视频用的什么标准编的码？是264还是265？
邵志兢：264、265 都可以，目前我们主要是用 264，265 没有合适的 WebAssembly 代码可以找到，所以暂时用 264。如果用 265 的话，整 个文件能再小 30%的样子。
徐阳：：我看从原片到普通压缩和低清画质，即使最低清也是要 11Mbps，这个对播放器性能，感觉这个是关键的瓶颈。
邵志兢：有一半是模型的部分，纹理的部分大概 3、4Mbps 的样子。 我们现在视频的部分，浏览器用video标签硬解是没有问题的，但是 因为video不能用，所以只能用软解，软解基本上流畅，但是会消耗 手机很多性能这样一种状态。
黄亚坤：您刚才提到建模几小时甚至要几天，我看您的场景图，和我 们所说的，他们会搭一个全息视频做直播。这种情况下有没有可能说 如果当带宽达到更高或甚至于 6G 情况下，有没有可能像直播 6G 的情 况？
邵志兢：人到相机是 2-2.5 米左右，在 2.5 米距离上只有 1 毫米误差， 精度是千分之一。如果有百分之零点五就是 1.5 厘米的测距误差的 话，手指的形状就已经没有了，所以基于质量的考虑，当相机离人比 较远的时候我们是用工业相机这样一种形式。深度算法本身可以做到 实时的，以及深度转点云这个环节都是实时的。如果用点云直播做直 播推流，目前这个系统可以实时来用的。点云直播的问题，最好压缩 也要最低 150Mbps，常规是 300Mbps 这样的带宽，这个带宽一定要 是一个万兆网络环境才可以流畅的跑。目前后面的点云转模型，一帧 少则 10 秒，多则几十秒，所以导致整个系统从点云的实时降为模型的 非实时。
黄亚坤：真实场景下如果没有这些绿幕环境，你们的算法可以支持模 型直接给它做？包括多人复杂场景，这都是属于同样一个问题。
邵志兢：首先算深度这个环节，是没有要求绿幕的；模型要贴上纹 理，就是从相机画面上取模型的纹理，这个环节我们用了扣图，这个 对绿幕没有刚性的要求，基于深度网络的分割，人抠出来的也是可以 的。人物神经网络对物体是没有很好的支持，如果这个表演者拿了一 个道具或者是他有一些配饰服装这些，基于神经网络的话，有可能会 把它给删掉。如果分割的不干净的话，也会有一些杂色进来。如果是 一个直播的场景，大家对质量要求没有这么苛刻，那是完全可以不用 绿幕。
黄亚坤：您说您在北京什么时候会有一个这样的体验？
邵志兢：大概是8月底。
王子韬：我们现在进入10分钟的休会，在这个过程中欢迎大家加入我们微信交流群组（联系薛富侨、贾雪远加入），也可以扫码领取我们本次会议的参会纪念品。
[会间休息十分钟]