低延迟视频传输_网络延时

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

微信后台如何应对像跨年，特殊时刻(比如2022年2月22日22时22分22秒)这样的朋友圈突发流量，可做如下策略(只是比如)：

• 优先让发一张图片的成功。
• 九宫格只成功一部分，剩余的强有损压缩。
• 朋友多的优先成功。(也可以反过来)
• 设置三天可见的优先成功。(也可以反过来)
• 年轻女性优先成功。(这个没毛病)
• 历史点赞多的优先成功。(也可以反过来)
• 头像穿西装打领带的经理统统失败。
• …

在不影响P99用户体验的前提下，提供有损服务，保证核心可用性，这就是柔性。
但数据传输的思维定势并不认可柔性。

受TCP的影响，普遍认可的传输即确保传输，而TCP也确实能保证最低可用性，这便让它更加被认为“绝对正确”，即便UDP-based协议也常常看到TCP的影子，重传，保序，诸如此类。

TCP的普遍性使它几乎被认为是唯一的标准，故谈到传输优化，大多数人都会关联TCP优化(together with QUIC优化)那一套，实际的传输场景(比如，传输的内容)却很少被关注。

本文的话题有关音视频传输优化，优化目标：

• 低卡顿率，超流畅。
• 秒互动，超低延时。
• 超高清。

优化要点不外乎：

• 音视频传输优化不能基于TCP/QUIC。
• 音视频传输优化需要对高清做柔性。
• 高清要强依赖编码而非传输码率。

本文不含技术细节，更不会涉及API调用，但理解这些基本思路，胜过10倍的技术细节。

稍详细点说。

如TCP，QUIC类通用传输协议不适合传输音视频，更无助于其传输优化，极致体验需在音视频流中自行斟酌传输细节。

计算机科学有一铁律强调分层解耦解决一切，而上述结论却将分层逻辑进行杂糅，虽与铁律相违背，但有理由。

分层铁律外，计算机科学还有一个约束强调一切皆trade-off。有此约束，分层协议的代价就是层次之间细节互不沟通，只通过接口交流PDU，而极致优化必依赖细节。

极致优化诉诸差异，而非共性。通用不为性能，性能也不鸟通用。

通用的另一个代价是不易定制。诸如TCP类协议均集成在系统，系统并不易改，甚至无权限修改，若需修改手机端TCP，便无能为力。优化若收敛于应用本身，则无障碍。

企图基于TCP，QUIC等通用协议做音视频传输优化终究徒劳，结合业务细节做定制才是正道。

类似量体高定西装之于产线均码西装，后者换一个人都穿不合身，它只属个人，这便是它的昂贵。

值得期待的是，若音视频传输统一标准，则此基础上通用的极致优化便成可能，新的差异方可发芽，一个螺旋上升的韵脚支撑着这押韵的故事。

昨天(2月25日)的”火山引擎视频云科技原力峰会”上，提到火山引擎，腾讯云，阿里云三家联合发布了《超低延时直播协议信令标准》，依次标准，火山引擎宣称延迟控制在1s以内，但就在前几天的2月22日，腾讯云发布了《超低延时直播白皮书》，说是联合信通院发布的业内首份，据此提到的技术，延时可控制在500ms以内。我不晓得这个白皮书和那个标准有什么关联，我感觉这些更多的是在pr，标准是不可能标准的，基本还是各做各自的。所以我提到的通用性问题依然存在。事实上不管是火山引擎峰会还是腾讯云的白皮书，都是含糊其辞，没人知道这个标准或者这个技术的框架到底是什么，所承诺的github或许也只是在很久以后才能兑现的承诺，或者也将永远不能。对圈里人士三两句话就能点透的始终还是没人说，大家对标准化的憧憬或者就像凡卡在等他爷爷康斯坦丁玛卡里奇的回信一样。是故，所有人都各自去做吧，并不难。

音视频传输，必在流畅度，清晰度，通用性之间做trade-off。事情非往复，但押韵，重画之前的一幅图：

为什么延时不参与？流式传输的时间因子永远只是流畅度，延时属不得已而主动为之，不能算数。

若非要图示buffer，流畅度和清晰度两个圆之间交集的面积即为buffer的大小，而buffer大小直接表征延时：

延时受拥塞排队及重传共同影响，接收端部署buffer可抵抗排队或重传带来的延时抖动。总之，buffer的作用是，在网络由于排队或重传导致数据包无法持续到达的时间段，播放器仍有持续的数据。

类似水库，深浅宽窄各处蜿蜒不同的河道要保证出水率恒定，需建一座水库充作buffer。传统音视频传输场景下，buffer意义类似水库：

实属用主动的大buffer延时抵抗被动的延时抖动，就和在坑洼颠簸的路面上盖厚土一样。

传统TCP协议丢包重传带来的抖动非常大，若发生RTO重传，延时抖动将达400ms。相比而言，拥塞排队带来的抖动在100ms以内，还好。

但调转视角，何必引入大buffer只为坚持速率，损失掉速率保持流畅于体验更好，若不再重传，延时大降低，所需buffer将大减少，若在小速率下只保障关键帧传输，效果亦然，此即为柔性策略，属无级变速。

再和坑洼颠簸的路面上盖厚土类比，柔性相当于不动路面而改造车辆，经理座驾加装避震，工人只能在班车里忍着。

前面一个图，将代表流畅度和清晰度的两个圆交集面积看作buffer大小，该视角下，buffer越大，为了既流畅又清晰的延时代价就越大，这显然是既要也要还要模式，但在柔性视角下，则是舍鱼而取熊掌模式了，解释就有了大不同：

不再将两个圆的交集视为合作，而视为互斥侵蚀，代表流畅度的圆“吃掉”代表清晰度的圆的面积，就是损失清晰度而额外获得的流畅度。这就是柔性，二者不可得兼，损失一个取另一个。这个一模一样的图示中，再没了buffer的位置。在现实实现中为了实施柔性，需要一个极小的buffer。

柔性又称“松弛吧”，“放松吧”，诸如此类，典型的例子就是旅行商问题退而求其次的解，也叫松弛解。现实中任何事我们都要避开既要也要还要，如此的话，代价巨大，同样在阿里听到的话，我倒喜欢第二句，“你有什么，你要什么，你能放弃什么”，总之，一切都是交换，或者说生意。

小buffer只为感知网络变化，为无级变速提供依据，由柔性替代重传和gap，同时小buffer平滑微弱的拥塞。2～3个RTT的buffer足以感知网络变化，另一方面，所谓微弱平滑拥塞的背后是对互联网公平收敛的信任。

如果可以通过历史预测拥塞，再好不过了，不过要当心，很多大V主播直播的时间(此时必然会有拥塞)并不是固定的，这种情况就需要实时预测了。不过无法预测只是信息不够，如果是他女朋友，预测就容易多了。

宁愿相信公平收敛原则被普遍遵守，拥塞总是不下心而为之转瞬即逝，受益者将是大家：

• 接近0的小buffer带来极低延时。
• 几RTT的小buffer感知网络变化。
• 柔性策略保证平滑流畅。

这就闭环了，但它背后的信任很脆弱，任何激进行为都能破坏平衡：

• 激进发送导致排队，排队导致延时增加，增大接收端buffer进行平滑，端到端延时增加。

后果就是集体堕落，所以，不要透支信任。

所有流量复用带宽，不光音视频流不能激进，其它UDP，TCP流量也不能。虽然运营商有一定的惩戒措施，但还是要自觉。

再详细点说。

信息交互之根本即消除不确定性，亦是信息论的核心。

人体器官可在很宽的分辨率范围识别信息，若信息受体如此类介质，便无需精确复制比特。音视频传输正在此列，这便存在一个关键，在必要时柔性降级清晰度，确保流畅。

TCP，QUIC类仅适用精确复制，如文件传输诉诸文件系统，便要求精确复制，对于音视频流诉诸器官，柔性传输便有更多弹性。

精确拷贝每一个比特的信息最终目的仍然是消除不确定性，若它不是最后的终点，若只是经由一个只能精确处理的途径，便需保持精确性。

遗憾的是，包括TCP，QUIC在内的通用协议，无法做柔性。

通用协议不理解传输细节，如TCP只是死磕确保传输每一个字节，即便允许不可靠，也不晓得丢弃哪一个包。若音视频协议自行做传输控制，就是另一局面。

例如根据网络实时质量决定如何柔性降级，牺牲清晰度保障流畅：

• 网络好时，按下面的序列正常传输：1，2，3，4，5，6，7，8
• 网络不好时，按照下面的序列传输：1，1，3，5，5，7，8，8

音视频流知道1，5，8关键，而2，3，4，7非关键，非关键序号可牺牲，亦可将其占位作关键序号的冗余，增加关键序号传输成功率，进一步避免卡顿。即便是发送轻微拥塞，该策略亦可保证关键序号到达。柔性既可抵抗丢包，亦可抵抗拥塞。

损失了清晰度，灵活性就多了，可以关键帧冗余做填充，可乱序发送，比如合并或拆分关键帧，可以做任意FEC，诸如此类。

这种细节信息，无法通过通用接口传递，若通用协议自行丢包，则不光通用协议需善后，也极易制造上层协议叠加效应，比如重传叠加，无论如何，效果总是卡顿。故柔性只能业务自己做。

柔性不意味着一味退让适配，probe带宽也是必须，但这是别的话题了。

柔性后，画质有损，但卡顿率无损。若使用TCP，弱网环境，丢包明显，为确保传输，仍坚持重传每一个包，滑动窗口自然卡死。

这就手机接入WI-FI，有时视频非常流畅，网页却死活打不开的原因。视频做了柔性，网页是HTTP，没这能力。HTTP的最大柔性只在TCP连接之间，网页元素独立使用TCP连接，若网络不给力，则放弃不重要的，通常图片位置会打叉。

WebRTC是个好东西，但BBR不是。基于RTP/RTCP定制的私有协议都好，但想要优化到极致，这些依然是通用的东西，忘记它们的具体形式，只将思想融入业务逻辑本身，事竟成。

说完了技术，说人。

专有协议优化容易出绩效，却难pr，针对专有协议优化的推广相当于暴露细节，降低进场门槛，属自废武功。

相反，通用协议优化，比如TCP优化在业内很容易pr，却难出绩效，其复制推广的简易程度抹平了差异。

大概就是此意，公开渠道的技术秀以及对应的招聘更多是广而告之，加入团队也不一定能取真经，若不跟随从零到一的过程，就只能维护一个成熟系统。教会徒弟便饿死师父，话不好听，但是事实，秀场就是名利场，有人图名图晋升，有人卖货拿提成，怎么可能让人予取予求。

这实属另一个困局。

当音视频传输优化很难进行下去时，不妨换个思路，与其费劲纠结于低卡顿，低延时，高清晰度如何实现，不如看看能放弃些什么。人们绞尽脑汁设计的那些个复杂无比且脆弱并且不一定有效的算法真的必要吗？大部分诉诸人体器官的信息并不需要精确传输，还不如直接有损传输，就像在大雾天出行一样，要做的是走慢一点，而不是试图去驱散迷雾，弱网就算一场雾，图像模糊点总比卡死强。周二和周五分别了解到腾讯云和火山引擎的超低延时直播技术，但也只是了解，我相信这两个是一回事又不是一回事，我也看不到技术细节，无论怎样，作为一个属于这个细分领域又不属于这个细分领域的我而言，总要写点自己的想法，就是本文。

浙江温州皮鞋湿，下雨进水不会胖。