创建网站公司 徐州,岳塘区建设路街道网站,怎么做公司官方网站,网站推广主要用的软件延迟和抖动
延迟#xff1a;是网络传输中的一个重要指标#xff0c;测量了数据从一个端点到另外一个端点所需的时间。一般我们用毫秒作为其单位。通常我们也把延迟叫做延时#xff0c;但是延时有时还会表示数据包发送端到接受端的往返时间。这个往返时间我们可以通过网络监…延迟和抖动
延迟是网络传输中的一个重要指标测量了数据从一个端点到另外一个端点所需的时间。一般我们用毫秒作为其单位。通常我们也把延迟叫做延时但是延时有时还会表示数据包发送端到接受端的往返时间。这个往返时间我们可以通过网络监控工具测量测量数据包的发送时间点和接受到确认的时间点两者之差就是延时。单向时间就是延迟。
抖动由于数据包的大小网络路由的路径选择等众多因素我们无法保证数据包的延迟时间是一致的数据包和数据包延迟的差异我们称为抖动。也就是说因为数据包的延时值忽大忽小的现象我们称为是抖动。
可以看出延迟会造成抖动但是抖动并不完全等价于延迟所以有时我们分析实际问题时还是要加以区分。
大学经常看直播球赛记得舍友用笔记本看球都进了我这边用手机过了一会才看到刚才球进的画面。这就是典型延时场景其中各个行业对延时的容忍度不一样像K歌合唱就对低延时要求非常高。如果歌伴都唱完了上半句你由于没有及时听到下半句还没唱出来对方是非常疑惑的。
但是我们也不能一味的追求低延时低延时是好但是会带来成本的上升。在实时传输领域有一个著名的三角理论。 成本我们可以理解为购买服务器需要的硬件成本、软件开发的人力成本和通讯带宽的租赁费用延时就是上面理解的数据包端到端之间的时间差质量可以理解为视频的清晰度和细节音频的高保真以及数据的完备性。任何行业完成实时数据交互都要受这三方面的因素的限制。如果过分追求低延时要么我们要付出比较高的成本要么我们得下降我们的音视频质量。所以我们针对不同行业选择一个用户能接受和不影响体验的延时即可。
视频实时性的三个等级
伪实时视频消费延迟超过3 秒单向观看实时通用架构是 CDN RTMP HLS现在基本上所有的直播都是这类技术 准实时 视频消费延迟 1 ~ 3 秒能进行双方互动但互动有障碍。有些直播网站通过 TCP/UDP FLV 已经实现了这类技术YY 直播属于这类技术 真实时视频消费延迟 1秒平均 500 毫秒。这类技术是真正的实时技术人和人交谈没有明显延迟感。QQ、微信、Skype 和 WebRTC 等都已经实现了这类技术。对于严格的音频通话当延时低于200ms时就会影响到用户体验。达到400ms对方用户就容易感知出来1s以上的延迟对于交互式实时直播就不能接受了。 下面有一个表格基本列举了不同业务对于低延时的大致要求当然即使是同一个业务应用在不同的场景下对于低延时要求也经常不一样这就导致我们解决问题的技术手段也是不一样的。在视频监控业务下这种差异更大对于一些司法、监狱和博物馆实时性要求很高希望出现问题后立即能进行报警和进行查看但是对于一些景区直播和学校社区实时性的要求就低很多。 延迟产生
我们继续看下一个完整直播系统的示意图 音视频从生产到消费的各个环节都需要花费时间来处理这些时间之和就造成了视频观看方看的视频是视频产生方几秒之前产生的视频。我们对这些延时进行区分会总结出以下四种类型的延时 处理延时一般就是路由器要分析数据包头决定这个数据包要送到下一站花费的时间 Processing delay – time it takes a router to process the packet header 排队延时数据包从进入到路由器的发送队列到被发送之间经过的时间路由排队算法和网络都会影响这部分延时。 Queuing delay – time the packet spends in routing queues 传输延时将数据包传入到线路花费的时间跟数据包的大小和带宽有关系。 Transmission delay – time it takes to push the packet’s bits onto the link 传播延时是指数据包第一个bit位从发送端到接收端的时间其和传输距离和传播速度有关系。 Propagation delay – time for a signal to reach its destination
其实对于音视频系统我们可以将上面讲述的三种延时归纳为下面几种
设备端的延时包括数据的采集、前处理、编码、解码、渲染等处理阶段花费的时间。也就是A1和A5花费的时间。
音频部分
音频从采集后会经过模数转换将传统的模拟信号转换成数字信号就会产生延时一般在10ms级别采集后进行编码采用不同的音频编码器也会产生不同的延时以Opus为例延时也在2.5ms-60ms级别可以参考上篇文章分析。发送前还需要进行3A算法AEC、ANS、AGC的处理又需要十几ms.
视频部分
从自然采光到成像取决于CCD和CMOS的成像效率不过一般也需要几十ms.对采集的RGB数据要进行YUV转换和编码如果还有B帧会产生比较大的编码延时紧接着播放端的渲染也是需要一定时间的。
无论音频还是视频为了防止抖动我们一般会在播放端加上jitter buffer缓存数据从进入到缓存到出缓存以及当发生丢包时进行的一些传输算法处理也是需要一定的时间大概会在几十毫秒到几百毫秒之间。
设备端和服务器的延时也就是俗称的第一公里和最后一公里的延时包括了A1到A2推流产生的延时和A5向A4拉流的延时。这里的延时跟设备端距离服务器的物理距离服务器和设备端的网络运营商设备的网速和带宽设备端自己的负载都有密切关系。
服务器之间的延时包含了音视频数据在网络上进行再次转码、切片、转封装和协议以及分发CDN等花费的时间包含了A2到A4整个阶段花费的时间。这里要看设备的推流端和播放端是不是在同一个边缘节点如果属于同一个边缘节点那延时能小点。国内城市之间的传播延时也在几十毫秒如果跨洲延时会达到百毫秒以上。
所以单就降低实时音视频系统延时一项内容都不是靠只优化一个节点或者一个阶段就能达到你想要的预期效果必须站在音视频整个系统来看待。
延迟测量
测试方法1
实际最简单的做法就是我们让推流端也就是主播端比如手机或者IPC摄像头对着一个在线秒表然后同时我们用手机或者桌面播放器播放该路视频然后得到了在线秒表显示的时间等稳定一段时间后我们将在实际线秒表的时间减去播放器显示的该时间二者的差值就是当前的系统的延时。然后这种测试方法每隔一段时间测试多组求其平均值就得到了当前负载下的音视频延时。
测试方法2
我们也可以在编码端的视频帧前面加上SEI帧SEI的全称是补充增强信息Supplemental Enhancement Infomation,提供了一种向视频码流中增加额外私有信息的方法。我们可以隔一段时间就在I帧前面的SPS PPS后面增加SEI帧私有信息就是这时我们编码器的NTP标准时间当该SEI帧信息到达播放器端我们再计算下本地的NTP时间。这样本地的值减去SEI的NTP时间就是当前系统的延时。前提条件编码器和播放器进行过NTP校时保证毫秒级别的时间信息要一致。
注对于有些播放器如果增加SEI信息可能会导致播放失败所以解码前我们可以将使用过的SEI帧丢掉。
延迟优化
经过以上的分析我们就分析出延时产生的阶段和节点这样优化延时就有了方法。延时会产生在 音视频数据的前处理 音视频数据的编解码 音视频数据的网络传输 为了防止抖动业务代码中的缓冲区包括推流服务、转码服务、播放器的缓存等 音视频的渲染播放
当然上面会产生延时的地方对于最终的延时影响权重是不一样的其中数据的前处理、编解码、渲染对于延时影响比较小而网络传输和业务代码的缓存对于延时影响非常大。所以优化也要结合你的业务有重点进行。
优化思路1调整推流端和播放端的缓冲区大小对于25fps的视频流如果我们缓存25帧的数据就会在播放时产生1s的延时。所以我们要动态调整我们的缓冲区对于推流上行区我们如果带宽不够就会产生网络阻塞这时发送端的数据就会积累最终延时不断累加导致延时变大。我们此时就需要有一套机制来能够预测带宽降低发送码率减低当前发送数据量减少网络阻塞等网络好的时候再继续增大数据发送量增大码率。
上面说的这些算法有很多其中WebRTC方案就采用了GCC算法还有一些类似BBR的算法来实现上述想法。
对于播放端的缓存当网络不好产生的延时比较大时我们需要通过丢帧和加速播放方式快速消耗掉播放缓冲区的数据从而消除累计的延时。 优化思路2优化网络传输如果实时性要求很高的场景你如果选用基于TCP承载的网络传输协议无论你怎么优化也很难降低延时。因为TCP会进行三次握手而且它会对每一次发送的数据进行确认还要对丢包进行重传所以这些限制很不适合降低延时。我们要优化传输协议我们可以将基于TCP的RTMP、HLS协议切换到基于UDP的RTP、QUIC协议上或者自己开发基于UDP的私有协议栈这样我们就可以对一些TCP延时大的功能进行裁剪和修改对于一些不关重要的数据进行丢弃优先保障重要数据的传输。其中国内B站、虎牙直播在线k12教育等都进行了类似的处理
优化思路3选择优质的CDN加速服务保障传输的线路带宽和线路资源一般都会提供测速选线、动态监测、智能路由等功能。
优化思路4如果感觉自己的编解码前期处理等花费时间比较多我们就需要选择合适的音视频编解码器进行算法调优降低延时比如我们在播放端能支持硬解的优先选择硬解否则才选择软解。
上面所说的任何一种实践方法用一两篇文章都讲述不完特别对于一些GCC、BBR等网络传输算法依然是高校和大厂最前沿最热门的研究领域需要用心学习才能落地到工程项目上这里只是简单的提出有兴趣的需要进一步搜索学习和实践。后面本公众号也会进行逐渐介绍这些算法敬请期待。
案例分享
案例1
问题 前一阵我们做了一个项目就是将自家消费类摄像头的视频投屏到像Alexa的智能音箱上当然音箱就是带屏幕那种类似小度小度。实际测试发现延时比较大大概有七八秒钟的样子但是对于Alexa这种智能音箱也就是播放器我们能干预的很有限毕竟推动亚马逊研发给你优化这些都是不太可能的但是我们想把自家摄像头视频投屏到Alexa后这样在他们商场上架我们产品可以加快我们的硬件海外出货速度同时还可以增加我们视频云的套餐订阅量。
措施 最后我们采取了优化转分发服务器缓存的做法采取了服务端主动追帧和丢帧的策略使服务器端的缓存能够根据当前网络状态进行自动调节让Alexa播放器的播放缓存总是处于基本饥饿状态经过一番优化后延时从七八秒降低到一二秒达到了上架IPC摄像头的条件。
所以服务端和播放端的缓存优化是降低延时的一个比较重要手段。
案例2
问题 还有一个项目采用了自动切换网络传输协议的措施来降低延时摄像头的视频一般要推送到云服务器上然后才能进行大规模的转发和分发。这是因为摄像头毕竟是嵌入式设备并发量非常有限能同时推送的视频路数也就一两路如何想无限制进行分发和允许多客户端同时观看就需要先让摄像头的视频上云到服务端的流媒体再进行大规模的分发和转发这也是视频监控的基本玩法。但是我们摄像头以前只支持TCP长链接方式向服务器推流这样当网络不好就会丢包重传延时也逐渐积累增大。甚至网络非常不好时延时会达到几十秒用户体验很不好。
措施 我们流媒体服务端会收集播放器的延时数据和丢包然后当达到一定条件我们通过信令服务器进行传输协议切换重新让摄像头推流。将TCP推流改成UDP推流我们在流媒体服务器端重新实现组包和增加丢帧策略降低播放端延时效果最后也得到了客户的满意。
https://zhuanlan.zhihu.com/p/82854047
