如何看待美国拦截四艘伊朗运往委内瑞拉的油轮并宣布没收全部100多万桶油？ 第2页

这个“全息显示仓”要实现的目标非常简单：让远隔千山万水（国际奥委会主席巴赫在北京、阿里巴巴CEO张勇在上海）的两个（或多个）人仿佛处于同一空间中进行交流。而且从实际的观看、拍摄与交流方面来看，对记者们来说，虽然两人都不在眼前，但效果上与他们俩站在面前几乎别无二致。

当然了，虽然新闻中名称叫“全息显示仓”，但实际上这是生活中广义上的全息，并不是物理意义上的。物理意义上狭义的“全息”是衍射成像的技术，但目前的技术还远远做不到理想的动态全息显示，这是整个光学领域圣杯级别的高难度挑战。

此次堪称黑科技的“全息显示仓”虽然不是严格的物理全息，但在立体感与真实感方面远远超出了目前普通显示屏所能呈现的显示效果。可能还有小伙伴没看现场的视频，可以看一下：

明明这是一个显示技术，官方的名称为什么叫“阿里云聚”呢？其实这是因为，之所以能取得如此惊艳的效果，最重要的核心技术不仅仅是我们看得见的面前的这款显示屏本身，还包括我们看不到的、尤其是云端的大量黑科技。

要能够实现我们看到的这么棒的发布会效果，至少有三个方面的“黑科技”：

（1）拍摄与显示的硬件设备

从现场的情况来看，发布会现场的“全息显示仓”是一块一人多高的高清大屏幕，用于显示参加新闻发布会的两位嘉宾的实时影像，仿佛两个人都同时站在大家面前。

从官方透露的消息来看，拍摄端的硬件布置大概是这样的：

拍摄端在摄影棚内，有常规的灯光、交互提示用的电视屏。除此之外，还有一块不太常规的屏幕，那就是用于显示另外一个人的“显示仓”。而且这个显示仓的位置和角度是特意设计过的，使得望向屏幕中的人时，拍摄出来的视线恰好符合两人站在一起时的视线。如此一来，物品的交接才会显得如此自然。

（2）符合广播级稳定要求的实时通信网络

很多小伙伴可能会觉得，本质上这不就是个复杂一些的视频会议嘛，只不过级别更高、屏幕更大、清晰度更高、稳定性要求更高。非要这么说倒也没错，但是要注意的是，无论是什么技术，随着从量变到质变的过程，要解决的技术问题的数量和难度可都是非线性陡增的。要想实现类似高规格发布会的万无一失，网络传输环节要实现的保障度是远远超出大多数时候的。

比如为了能够实现发丝级的“全息复刻”，拍摄的原始画面清晰度是非常高的，如果按照传统方式传输，将挤占大量带宽，极有可能遇到网络拥堵问题。阿里云聚这次采用了一种叫作“窄带高清”的技术，能够在节省50%带宽的情况下，仍然保障画面的清晰度。

另外，即便我们使用的是运营商最高带宽的宽带套餐，日常生活中还是难免会遇到网络信号不好的情况，造成视频会议时的画面卡顿。平时会议稍微等一等倒也问题不大，但是对新闻发布会这种高级别会议，卡顿显然是无法接受的。为了能够在网络信号不好的情况下依然保持画面流程，阿里云聚开发了“弱网抗丢包”技术，能够在80% 丢包下可提供流畅通话，同等丢包环境弱网传输效率提升65%，实现良好的实施传输效果。

（3）强大的云端算法与算力

不知道大家有没有注意到，记者会现场的全息显示仓中，张勇与巴赫所处的似乎是一个封闭的空间，两个人的身后似乎有一定的纵深，墙上也有很自然的阴影效果，使得图像出现了较强的空间感。其实这种光影效果是计算机实时渲染出来的，起到了以假乱真的效果。这是需要强大的算法与计算力的。

其实需要算法与算力的远不止视频的实时渲染。比如音频的处理，我们都有过在嘈杂环境下开会的经历，要想听清对方讲话是非常困难的。阿里云聚通过亿次通话数据验证和海量历史数据回归，实现了持续进步的多场景智能降噪能力。而这同样需要算法与算力的加持。

根据研究，要想实现流畅舒适的交互效果，延时必须控制在200ms以内。

也就是说，端到端的实时传输和处理，比如音视频转码、光影渲染、音频智能降噪等等功能，都需要在200ms以内实现，这需要高效的算法与强大的算力，靠拍摄或发布会现场的端侧计算机是无法做到的。阿里云聚解决这个问题的方法是“云处理+端渲染”技术，即通过实时通信与云上处理的技术结合，解决因端侧算力受限的难题。

其实可以看得出，这次的高级别新闻发布会算是阿里云聚的一次“亮剑”：连如此高要求的场景都能hold住，其他的应用场景更不在话下。很明显，这种“宛若就在面前”的显示与交互技术，还可以应用在很多其他的应用场合，比如远程教育、虚拟社交、远程VR操控等等。而在新冠疫情的大背景下，甚至只用它来开个远程视频会，都让会议显得更温暖了呢……

---

  she-hui-ke-xue-19 网友的相关建议: 
      

本来不应该判这么重，无良媒体煽风点火。

---

  william-lim 网友的相关建议: 
      

开源代码没啥可评价的。

但对RISC-V的生态有何影响还得再看，简单说把risc-v带入Android生态，就给risc-v的应用提供了不小的应用场景，但是还不清楚相关的工具链的成熟度。新闻上Android studio/NDK已经支持了RISC-v的交叉编译环境，但还不知道成熟度如何，这些实际上都会对选型有影响。Google对Android的性能调优做了很多工作，也有不少工具，这些东西何时开始支持risc-v也比较重要。

理论上RISC-v依赖Android生态，对Google是好事，但毕竟Google利用GMS还是控制了相当程度上的Android生态，当年号称不作恶的谷歌还是利用开源方案包装了一个半开放系统。依赖Android的任何厂商实际上都面临华为之前的问题。华为被迫选择了HMS之路，但其他中国厂商呢？

我觉得是时候由中国厂商联合比如欧洲或日韩厂商推出一个绕开GMS的，真正开放的andriod生态了。

---