开发者学堂课程【云上视界断无限2028里云直微峰会：云上“视界”创新无限|2022阿里云直播峰会】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/778/detail/15728
云上“视界”创新无限|2022阿里云直播峰会
多视角还有几个技术点值得跟大家分享一下，多视角服务其实是不需要对云导播输出的所有的信号进行解码，也不需要对发送给播放器的数据进行编码，因为这样会大量的消耗计算资源，我们只需要去把相应的流的音视频数据拷贝下来，然后通过RTP协议发送给播放器就好了，就像这张图上这个表示的一样，那个上面两路绿色和蓝色的流呢，代表主舞台视角和黄渤的特写视角，最下面的一路就是代表发送给播放器的用户的流量，那在切换前我们只需要拷贝绿色的流往那切完之后的话拷贝蓝色的流，但是如果这个切换发生在Group的中间的位置的时候，其实需要做一些特殊的处理，方式就是立刻拷贝立刻结束，当前拷贝的那把剩下的那半截用蓝色的流重新编码成新的一个GOP，也就是这个图中黄色的表示的那一部分，在发送完黄色的这部分之后再继续拷贝蓝色的流就好了，这样的基础方案既可以做到平滑的切换，也可以省掉非常多的计算资源。
下面我把自由视角展开给给大家做一个介绍。自由视角跟VR其实是类似的，他们都属于6DOF视频，其实都是对3D视频的一种呈现，VR的话其实是从一个点向外多个角度去看，主要适用于从一个点就环顾全场的这种场景。
自由视角恰恰相反，它更多的是从外向里看，适用于从多个视角去聚焦的去看一个舞台的这种场景，在优酷的应用场景主要应用在赛事直播和综艺直播。像CUBA的全明星赛和街舞的一些特定的一些效果呈现上。
这张图展现了自由视角技术的完整的链路，以这个完整电路上涉及到的一些核心的技术点。追源头就是自由视角的采集系统，包含36个相机，它就是部署在一个150度的圆弧的横架上，并且需要对每一路相机进行标定。
然后采集系统会将36路的信号以及标定的数据同时输出给3D重建的服务进行3D重建。所谓3D的重建其实就是对原始的画面和这个深度的图的提取的过程。原始的图像其实是二维的，图像中的每一个像素点，都有一个X坐标和Y坐标，如果再加上Z坐标的就可以完整的描述一个3D的画面，深度图其实就起到了这个作用。深度图其实是通过相机的原始画面和标定的数据一起计算得出的。提取出这些原始图和深度图之后我们就会把它们拼接成一个非常大的一个画面，就像右上角的这张图一样，就是完整描述一张3D图像的一个画面，然后对它进行编码，然后通过CDN的分发到端侧进行渲染。端侧拿到流之后首先会进行解码，并将刚才拼接的这些画面进行拆分。最后将试点渲染到手机的屏幕上即可。需要强调一点就是36路的相机其实是没有办法做到正负75度也就是150度范围的这种精确度的这种切换。因为两个相机之间是四度多一点空白在里面。这两个空白就需要使用到基于深度图的视点合成技术来实施。最终达到一度经度的这种切换的体验。
这个技术链路，如果要应用到直播的场景，其实还面临着一系列的技术挑战。第一个挑战就是在采集上传的一些挑战，因为3D重建是需要计算深度图的，这个过程是非常消耗计算资源的。另外我们还需要保证视频的清晰度，所以说拼接后的3D视频通常都是能达到8K的分辨率，8K分辨率进行编码也是需要非常大的计算资源的。第二个挑战就是客户端去下载8K视频带宽带来的压力，因为8K视频往往码率都在两百种上下的普通用户是很难把握这种网络条件的。即使是下载到终端，终端的渲染压力也是非常大的，因为只有极少数的高端机型才能对8K解码，何况我们还要对这些空白的试点进行实时合成，这都是一系列的挑战。
这张图的其实就是自由视角在直播上去解决掉这些挑战的一个最终落地的方案。跟上面这张图的变化，主要是引入了边缘计算层，主要是把8K的视频的解码以及试点的合成放到了边缘云上。端侧跟边缘只要通过DNS的RTP协议进行传输视频信号以及角度切换的信令，就能做到只给端车下发选择的那一个试点的画面进行编码下发就行了，所以他的分辨率只要1080P就够了。端侧的这些计算带宽压力也就都迎刃而解了，采集上传的压力，其实是通过一些特定的硬件和特定的一些板卡做集成来满足需求的，比如说我们继承了很多路的SD的采集卡以及集成了一个FPGA的板卡。
下面的话就对臻享数字影棚XR制作系统给大家做一个介绍，XR其实是可以让真实的舞者完全融入到现在的这个虚拟的空间中，光影的效果其实也挺棒的。整个画面其实是包含这么几个部分的。首先会包含真实的led的背景舞台，这个舞台包含了两个led的背景屏和一个led的背景地板，真实的舞者其实是站在这个真实的led的舞台上进行表演的，这个舞台外边就是这个扩展出来的虚拟背景。这些虚拟的背景其实是由蜘蛛系统里面那个虚拟渲染引擎实时渲染拼接而成的。在舞者前面的这部分AR前景的一些叠加，这部分也是由虚拟渲染引擎实时渲染出来的。其实现场的真实的拍摄场景就是这样。可以清楚地看到舞者是站在led的背景舞台上，舞台的外边其实是没有任何画面的，右下角的监视器其实是通过XR系统制作输出出来的完整的可播出的PDM信号，这里面已经包含了完整的扩展的背景以及叠加之后的AR前景。
技术链路上可以用这张图来给大家做一个介绍，首先在摄像机上其实是安装了摄像机的追踪系统会实时的跟踪摄像机的位置以及焦距等等一系列的信息。摄像机的追踪系统会输出给这个虚拟的渲染引擎服务，虚拟的渲染引擎服务会根据摄像机的追踪系统，最终把虚拟空间的内容进行渲染，然后通过led背景的投射系统最终投射到led背景上。投射到背景上之后摄像机去采集的视频信号就会包含真实的舞者以及led背景上渲染出来的一些虚拟的背景。最终这个虚拟的服务器会拿到摄像机的采集信号，然后结合着摄像机追踪的信号对真实的led背景屏进行扩展渲染，同时在前面叠加层叠加上真实的AR前景，最终就形成了最终的PGM的这个直播信号。整个XR直播技术链路大概就是这样的一个情况。
感谢戴洵的精彩分享，大型活动中的多视角、自由视角等技术的应用，给予观众带来更加沉浸式的体验。下面有请阿里巴巴国际贸易事业部直播负责人叶新军带来打造高性能、低延时、稳定可靠的跨境电商直播服务的主题分享。
大家好，我是来自阿里巴巴国际站ICBU的直播技术负责人，我叫叶新军，今天我给大家带来的是打造高性能、低延时、稳定、可靠的跨境电商直播服务。
全球直播发展的趋势其实是非常快的，像tick talk、Youtube、Facebook、big lifelive命运等等，在过去的几年都在快速的去发展他的直播业务。作为我们全球跨境贸易的我们的阿里巴巴国际站，这两年也在做我们的整个的直播的业务，整个的直播的业务也是呈现出了一个非常好的增长的情况。
在2021年整个的直播的开播场次，有200%的增长到了2020年上半年也有100%的增长。整个阿里巴巴国际站的直播形态，其实跟整个电商直播没有太大的区别。他也是有整个导购的，这样的一个场景，直播间里面可以评论、互动、营销、下单等等。也给商家侧提供app、策略工具、Windows策略工具等等，上面可以一键管理你的直播和买家的互动等等。总部阿里巴巴国际站在最开始做直播业务的时候，其实也是倚着四点或者快速执行这样的一个方式去做的，所以在最开始的时候其实选择了一个相对传统或者相对稳定直播的架构。就是从
主播侧通过RTMP推流，可以利用已有的整个CDN的网络。在观看侧通过HLS拉流和FLV拉流来账的方式去做。这样的价格其实在业务初期快速的帮整个业务快速的发展起来，然后整个形态快速的搭建起来也能够让商家和买家迅速的能够通过直播间去把业务玩转起来。
但是后面发现其实在整个跨境的这个贸易全球直播中其实还是有非常大的挑战，首先第一个挑战就是我们的直播绝大多数的情况，都是由中国推流全球观看。这样的一个情况天然的带来了一个非常长的距传输距离以及各种各样的网络情况等等，那不同的地方网络形态是有非常大的差别，所以对直播的播放性能是有一个非常非常高的挑战的对。
第二个就是低延时，核心上我们也是一个电商直播，其实是有着高互动的这样的诉求的。延时其实分了两个东西，首先就是画面的延迟，五秒过个十秒才能看到商家对你的回答，商家往往都是通过口播来进行回答，可能你会缺少耐心这是其一。其二就是消息的延迟，在我们的直播系统里面买家进到直播间买家去发评论商家都是能够收到这样的消息的。对于这个消息的延迟也是有非常高的诉求。如果一个消息要在五秒十秒才能够收到，商家其实是无法做出及时的回应的呢。
第三个就是稳定性，直播在让用户分散的情况下对整个的这种播放成功还是非常大的挑战，最开始的时候整个的播放成功率其实并不高。第二个就是直播这样的业务其实有非常强的实质性。就是一旦出问题了，其实就是灾难性的，就是你不像发一个商品还可能重新再发，可能这个直播可能就下调了要重新开播，这个对于直播带来的这种打击或者带来的问题是非常非常大的，所以推流的稳定性，主播的稳定性也是极其重要的。基于这样的挑战我们在过去的一年和阿里云一起对整个直播业务架构进行了一个全方位的升级。就从传统的直播架构升级到整个新一代的直播的架构。推流SDK也是从原来的JSP也升到了基于RTC的让那个AliRtc的这样的一个SDK上。推流协议也从原来基于TCP的RTMP升级到基于ARTC的会晤推流，就是RTC这样的一个推流协议上。分发网络也从原来传统的CDN的，这样的一个分发网络升级到我们有阿里云推出的GRTN这样的分发网络。拉流协议也从原来的flv/HLS基于ARTC的拉流协议。为了应对这样的协议的变化，整个观看SDK的播放器也做了升级，从原来的videoX这样的一个播放器升级到我们的能够支持ARTC播放的播放器。消息系统也做了升级就是刚刚提到前面提到的对于消息的诉求，原来用的是power message，从这样的系统升级到我们自研的这样的一个flash message这样的一个系统。
除此之外在能力上也进行了一些升级，包括了像连麦、云摄像头,云摄像头指的就是从一个摄像头里面把流拉过来，直接和到我们的直播间的画面里面对这样的一个升级。升级的架构可以看到就是我们从主播侧通过RTCRTS推流这样的一个形式推到网络中，然后通过整个加添的媒体网络去分发直播流，在此之上还有很多控制的能力，包括录制、截图、转码等等，以及对于选路径探测等等路径规划状态的一些能力，在观看侧核心就通过整个RTCRTS流当然也保留了FLV和HLS留着个可能在某些场景下用于降级播放的时候使用。
总结下来就是 基于整个家庭打造的这个低延时高稳定的这样的一个直播服务。低延时体现在在相同的卡顿率下，延时可以降低80%。相比传统的RTMPRHRSFRV的这种5到10秒的延迟呢，延迟可以到一秒上下。这个确实是一个非常大的提升。
第二个高稳定就是整个这一套架构，其实在阿里集团内部已经有多个业务，在使用包括淘宝直播，对淘宝直播在大促中也就经受住了考验。
第三个其实是开放的标准，就是因为使用这样的标准的能力，其实对我们有非常大的帮助，因为我们不是从头开始，是从原来的这样的一个系统升级上来，所以开放的标准就能够更加有利于快速、有效地、低成本的升级上来。在此基础上我们其实做了非常多直播性能提升的策略。总结下来其实核心就是以下三点。就是预热流、预播放、预建联。预热流指的是，因为我们观众在全球看来自五湖四海、世界各地，所以某些地区或者某一次访问它很有可能是这个LV节点，或者说甚至这个地区甚至这个国家第一个访问的。所以往往他看到的这个流是一个冷流，就是在整个媒体网络上都还没有没有别人拉过，所以我们和整个家庭团队配合做了一个能力，在整个家庭网络上提前做好这个建联的工作，这样的话用户过来的时候，可以减少整个建联工作能够快速的把这个流。
第二个是预播放。这个是核心是在我们在直播列表就对直播流提前启播。就是如果用户的访问路径是从直播列表页进到我们的直播间，那我们都在直播列表页就会对一些直播间，比如说用户停留在那里的直播间进行启播。另外就是对没有停留的会直接进入的就是会被进入的时候也会对直播流提前启播就不会等待直播间的其他的信息过来了以后再开始做这个播放。我们把整个播放的URL通过参数的方式直接传到直播间提前起播。
第三个是预建联，预建联的核心场景是在直播间上下划给这样的一个场景，通过预建联提前完成直播流的准备。单用户往下滑到下一个直播间的时候就直接起播，这个时候可以做到非常无感的顺势的直播。除此之外我们整个直播的互动消息系统叫flash message。
