来源：云算计
每当我连写几篇行业分析的虚文以后，我都会做一两篇技术科普和产品分析的硬核分享。最近看到PPIO王闻宇在LiveVideoStack做的视频云技术分享，抛开其中对云游戏和边缘计算的推演不谈，我学习了很多视频技术常识，也向其请教了一些专业知识。
本文就是对视频云常见技术名词做总结分享，这篇分享对专业产品研发太浅了，但对于其他产品线的技术人员、视频云市场营销、售前售后和客户，都能起到科普分享的作用。
(相关资料图)
码率和带宽
视频要从云端分发到客户端就需要消耗带宽，云销售最关注的就是客户要用多少带宽。
视频云还经常会提到“视频码率”一词，码率的学名是“单位时间内传输的数据位数”。在流媒体视频云科普场景下，我们并不关注其他类型的码率，只关注数据从服务端传输到播放器的码率，所以说码率可以等于带宽。
虽然码率的单位是Mbps、带宽的单位是Mbit，但两者基本上数值相等。两者默认有个千分之一的差值，那是应用层的码流和链路层的数据帧那点包头的差异。
如果是在特别差的网络环境里，会出现网络折损系数，比如视频生成了1M码流，但是因为网络太差反复重传，可能会消耗2M带宽，但国内已经较少见到这种网络环境了。
视频点播的过程中，视频并不是一直下载实时播放，而是会预先做一段时间的缓冲，在缓冲数据用尽之前，播放器断网也能继续流畅播放，而用户随意拖动播放进度条，也会感觉到网络卡顿。
视频点播大客户都是基于带宽峰值付费，这时就会有小伙伴担心了，视频既然会提前预缓存，那么一条视频的带宽波形图应该是“断断续续的波峰和归零”了，这会不会打出新的波峰，让客户多付费？其实这事很好理解，一个客户的带宽波形有波动，但是只要客户多了，带宽总量的波形就会很均匀了。
分辨率和带宽
视频的分辨率比较好理解，就是一幅图一共有多少个像素，其描述单位就是像素点的高宽比。比如“1280*720”的分辨率，意思就是宽度有1280个像素点，高度上有720个像素点。
大家经常听到“720P/1080P/2K/4K”，这是美国电影电视工程师协会制订的视频格式标准，该标准仅用于做技术评估和沟通，如果一个视频达到“1280*720”的分辨率标准，我们就可以将其称为720P视频；而同样是2K或4K视频，可以有16比9和16比10等多种分辨率存在，以适应电视和电脑的不同场景。
每一路视频所需的带宽，可以参考下表来推导。注意下表各要素中，除了像素数和图像位深可以直接相乘以外，其他角色都只是“强相关但不固定数值”地影响带宽，所以本文只能给出参考带宽。
本表中的图像位深，就是每个像素点可能有多少种颜色，像素点能存储的颜色越多，带宽码率就越大。常见的图像位深有8比特和10比特，8比特可以记录256种色阶，10比特可以记录1024种色阶。
编码格式和帧率比较复杂，简单总结是：编码器越优秀带宽压缩越狠，帧率越高带宽用的越多，但压缩和放大比例要具体视频具体分析，后续也有两个单独章节讲解这两块内容。
视频帧率或刷新率
原始视频占用空间非常大，并不适合直接放在网上传输，视频云厂商首先要给视频编码进行压缩瘦身。
视频编码的具体工作机制非常复杂，就是用数学方法描述一堆像素的排列机制。非专业人员可以将其理解为给视频打压缩包。
计算机从业者可以参考下图，这是对H265的某个比较优势的介绍，也能说明编码器的一部分工作原理：
左侧是H264编码默认用16*16的像素块进行编码；
右侧是H265使用从8*8到64*64的可变长度像素块对图片进行编码。
常见的视频编码方法有H264、H265、AV1等等。以H264为标准，H265和AV1都能比H264节省大约30%~40%的带宽。这俩新兴编码器只能承诺大致效果，是因为每个视频的内容都不同。
A类视频，大部分时间是静止，比如主播离开直播间、慢镜头长焦风景视频；这类视频的编码压缩效果都出奇的好。
B类视频，镜头剧烈晃动、大量光照和色彩变化，比如专业电竞主播、4K演示视频等等；这类视频哪种编码器也压不下去码率。
大部分视频介于A类和B类之间，所以我们只能说，新编码器比旧编码器能节省大约30%~40%的带宽。
但是H264并没有退出历史舞台，那是因为客户需要在三个开销之间找平衡，这三个开销是：“带宽开销”+“编码器开销”+“编码算力开销”，也要兼顾编码耗时和设备兼容性。
H265是商业收费产品，客户节省的带宽费通过软件授权的方式又涨回来了。
AV1是开源产品，需要自己组建AV1研发团队，既需要钱也需要时间；
有一些软件编码和硬件编码卡创业团队，据说收费更贵但压缩效果更好。
编码器需要大量消耗CPU或者专用板卡，一般情况下算力比带宽便宜，但算力资源也不是白送的。
媒体编码是需要时间的，大部分点直播里不在意那5毫秒10毫秒的延迟，但云游戏和RTC直播很介意这些延迟。
10年前，经常有老设备不支持H265只支持H264；5年前，经常有老设备不支持AV1。
视频帧率或刷新率
视频本质上是一张张的图片连续起来的动画，某个视频在一秒钟内有多少张图片，这就是帧率或者刷新率。经过多年的业务摸索，大部分场景该看什么刷新率的视频，业内已有共识。
传统电影、点播视频、秀场带货直播，可以接受匀速播放的24~30帧；如果帧率提高到60~120帧，客户也会有更细致的观感；这就跟用传统手机和高刷屏手机是类似的体验升级。
在游戏舞蹈类直播和云游戏领域里，提高视频帧率就成了刚需，因为游戏或舞蹈的视频并不是均匀变化的，无法预估下一张图片是一动不动还是电光火石。如果是客户在观看直播内容，可以接受60帧的帧率，如果客户是在自己电脑上玩游戏或云游戏，需要将帧率提高到120Hz以上。
下图就是一块高刷新率电竞显示器的示意图，如果低刷新率玩射击游戏，那就真要“靠感觉蒙一枪”了。
视频帧率对带宽占用比例有一定影响，但是对视频的影响一般较小，这主要是前文提到的视频编码器起效果了。因为大部分视频都不是关键帧，只是上一张图片里简单改了几个像素，视频编码器可以将其深度压缩。
常规视频从30帧翻到60帧，视频体积一般只增大10%~30%。
视频帧率对算力的开销影响很大，因为每一张图片都是要GPU计算渲染出来的，虽然有局部渲染等技术减负，但是总体来说帧率越高工作强度越大。
最典型的例子在2017~2019年，一个游戏主播做60帧的直播，云厂商就要一台完整的服务器陪绑串流。
立体视觉和虚拟现实
人的大脑产生3D立体视觉效果，主要是依靠左右眼看到的图像有轻微差别。这是个复杂但并不难实现的高科技，小朋友拿来玩的一些“光栅装饰画”，就是类似的原理，3D眼镜和3D广告牌也很便宜。
我们平时戴眼镜的3D视觉，就是用左右镜片不同的偏光角度，让两只眼看到的视频有轻微差异。裸眼3D屏幕，就是把镜片遮挡光线的功能挪到了特制的屏幕上，观众的左右眼看屏幕有轻微的角度差异，进而产生3D视觉效果。
VR眼镜做3D有个天然的优势，它天生就有两个可以独立输出图像的显示屏，只要两个显示屏能各自输出无限逼真的图像，那么虚拟现实就是现实的图像。
现在的问题是——无限逼真，究竟要到多逼真呢？
无限逼真的视频：视网膜级分辨率
相比很多动物的眼睛，人的眼睛是一个比较粗糙但善于脑补的光线感受器。最早推出视网膜屏幕的苹果公司，就给人眼定义了一个识别像素的数值上限，这个上限大约是“PPD：每度有60个像素”。
为了实现PPD能达到60像素，主打视网膜屏功能的手机、电脑、VR的屏幕，都要堆叠“PPI每英寸像素数”。
早期视网膜屏手机，假设人眼到手机屏幕的距离是40厘米，对PPI的要求是300；
现在视网膜屏手机，假设人眼到手机屏幕的距离是25厘米，对PPI的要求就提高到了460。
网上其他专家的评论认为，仅有60的PPD可能还不够，需要将PPD翻2.5倍，那就是PPI也要增加2.5倍。
经过一系列复杂的像素和人眼视角转换，王闻宇的演讲原稿中得出了一个比较理性的结论：VR眼镜要想达到视网膜级分辨率，实现虚拟现实和生理感觉相适应，每个屏幕都要显示8k以上的分辨率的视频。
即使不考虑8K素材的缺乏，也不考虑VR显示屏是否支持8K显示，单纯从视频生产方的显卡来看，至少要两块3080Ti的显卡才支持8K分辨率120帧的视频输出。这一类显卡新款高配的价格要过万，3080Ti已经算落伍硬件了也要4000多块钱。
这方面还没大范围普及的产品和应用场景。
游戏时延和边缘计算
我当年写边缘计算和云游戏的文章，就模糊地提到了操作时延问题，这次补齐了VR时延的认知缺憾。
我们需要了解，射击类游戏能接受多大的时延，这是云游戏云桌面的体验红线。
我们也需要了解，VR游戏能接受多大的延迟，超过这个延迟用户就会感觉到就会眩晕。
在VR游戏里，从用户开始运动到对应画面展示的时间，其专用名词为“Motion-to-photons Latency”，简称M2P时延。
VR用户可以接受M2P时延为小于20ms，超过这个时长，用户就会出现眩晕等不适感。这20ms的时延范围内，可以留给往返网络传输5~8ms的时间，也就是说VR设备只能使用来自同城边缘端的算力支持。如果客户的VR设备需要边缘计算支援高端显卡，可以从同城边缘端租赁显卡。
现在云游戏使用的是3060这类主流显卡，这款显卡玩游戏时可以2K120帧稳定输出，正好和主流VR头盔的显示屏匹配上。估计VR头盔和素材支持8K了，主流显卡也就都支持8K了。
在射击类游戏里，从用户操作跳跃开枪等动作，到用户看到游戏人物跳起开火，这一整套动作反馈过程，可以接受不超过80ms的操作时延。如果云游戏超过这个时长，用户玩游戏基本就是送人头坑队友了。
这80ms的操作延迟里，可以留给往返网络传输50~60ms。这么大的网络延迟，都不用边缘计算，苏北机房就足以覆盖北京和上海用户了。
对射击类游戏的操作时延探索，出自我本人超过300小时的《堡垒之夜》游玩经历，包括高延迟国际服和START云游戏国内测试服。
标签：
