首先，如果你还没有看过该系列文章的上篇，请移步这里。在下篇中我要讨论的是：为什么我认为音视频会议时长会解构，以及由此产生的大好机遇。 上篇文章的内容如图所示： 除此之外，我们还有一个棘手的问题需要解决。当然，你可以很快组建一个用户体验更好、功能更齐全的会议平台。但是无论你的屏幕共享效果如何，平台的音频和视频信令处理性能总归是一塌糊涂，你的客户会感到失望。做好信号处理需要专业人士和大量投资，但现在没

我们能做出哪些改进？ 由于工作，我每年要坐50次飞机，参加各种语音和视频会议。我的脑海里不断浮现一个问题——为什么所有会议平台都这么难用？我们都能用 AI 让已去世的人出现在 4K+杜比环绕立体声的视频中了，但开会时屏幕上我同事的脸仍然是让人抓狂的延迟像素，卡到不同步的那种。另外，好像大家都不会共享屏幕。我只能看到人的画面。 去年，我辞掉了一家跨国技术公司的好工作，想要努力解决这个问题。之前我也这

对WebRTC的错误认知 WebRTC最初是作为Google Hangouts的基础迭代技术而面世的。当时这种技术给大众的惯常印象是低质量的视频。这导致了之后WebRTC被谣传成无法规模化、不可用于ABR以及其视频都是低分辨率和低质量的技术。 确实，WebRTC需要在服务器和播放器之间建立持久连接才能保证其可扩展性。但大型流媒体商店在自己的交付基础架构中已经解决了这一问题。这就是为何要吸引成千上万

第二个级别是“提前剧透”，比如你邻居是个体育粉，他在隔壁看电视播放的体育比赛。突然他因为某个球员触地得分激动地狂喊，还发了推特。但你在30秒后才在电视上看到这一情景。这个例子和延迟的道理一样。大多数广播频道的延迟时间约为平均5-10秒；如果不要求提供显著优于广播方式的流媒体传输，则基于HTTP的技术大多数延迟时间约为2至5秒。 第三个级别是“实时”，多见于交互式应用程序，比如对用于赌博或拍卖的应用

还有一些通用媒体应用程序格式（CMAF）块编码解决方案，这些方案允许单个文件集传递到HLS和DASH客户端。其中，基于低延迟CMAF的方案有许多优点，包括对传统播放器的支持。如果播放器没有低延迟的能力，它可以正常延迟速度来检索和播放片段。 此外，由于文件格式是基于标准的，因此现今支持DRM、字幕和广告插入的技术应能正常工作。并且HTTP段应该是可缓存的，防火墙也不会因此出现任何问题。 在大多数情况

根据Bitmovin发布的《2019年视频开发人员报告》，有54％的受访者关心延迟问题。 深入调查后发现，将近50％的调受访者计划在未来1-2年内使用低延迟技术，其中50％以上的受访者寻求不到5秒的延迟，30％寻求不到1秒的延迟。（图1）。 综上所示，是时候有一篇低延迟选项的文章供大家参考了，不是吗？ 在本文中，我首先会讲一些低延迟技术的基础知识，然后是一些选择技术的注意事项。 图1 Bitmov