为什么现在的视频会议体验这么烂?!(下)

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

为什么现在的视频会议体验这么烂?(上)

我们能做出哪些改进? 由于工作,我每年要坐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