产品经理或工程师希望让他们的用户能够在他们的平台内建立社区和流畅的社交体验。为实现这一目标,他们决定在其产品中添加实时音频、视频和文本聊天模块,以便用户无需跳转到其他平台即可进行交流。他们开始研究和评估 WebRTC 解决方案——或者至少是他们认为的WebRTC 解决方案。
只有在启动正式的供应商选择过程后,他们才会意识到,即使不是全部,他们一直在寻找的大多数 WebRTC 解决方案根本不提供 WebRTC 功能。它们实际上是视频流解决方案。虽然他们可能没有意识到,简单地说,视频流解决方案并不是他们想要的。
在这里,我们必须重点强调:WebRTC 和视频流不一样。将两者混为一谈会使你对实时社交工具的追逐变为徒劳。在不知不觉中,你已经投入了大量的时间来评估一个平台,而这个平台并不能给你的用户提供你想要的沟通方式。
以下是你需要知道的关于WebRTC和视频流之间的关键区别。
流媒体:一种单向内容流
虽然WebRTC和视频流都是在线提供内容的方式,但WebRTC有一个关键方面是流媒体所缺乏的:双向通信。当你用流媒体播放你最喜欢的电影时,你并不是在交流,你只是在消费内容。
换句话说,流媒体平台只将内容移动到一个方向:从服务器到消费者。例如,让我们使用将视频流媒体带入主流的公司:Netflix。当 Netflix 将电影添加到他们的服务时,他们通过利用称为内容分发网络 (CDN) 的东西来实现。它是这样工作的:
首先,Netflix将电影作为视频文件加载到电脑上,并将其分成小段。然后,这些内容被分发到世界各地的服务器网络上(这就是CDN)。当你带着爆米花坐在沙发上,打开电影时,Netflix从离你最近的CDN服务器上调取电影,并将其逐段送到你的屏幕上。
WebRTC:真正的实时通信
另一方面,通过WebRTC,用户并不是从遥远的服务器上拉出预先制作、预先加载的内容供单方消费。相反,音频和视频内容是实时采集的,来自每个参与方和他们的设备,并在双方之间进行双向流动交换。所有这些都在几毫秒内发生。
除了通信方面,另一个关键区别是,WebRTC是一个真正的硬件密集型过程。当你使用WebRTC与人聊天时,你手机或电脑上的摄像头、麦克风和扬声器正在捕捉音频和视频内容,对其进行转换、压缩,并将其发送给你的对话伙伴。
为什么把 WebRTC 和视频流混为一谈是危险的
那么为什么了解 WebRTC 和视频流之间的区别很重要呢?在我们看来,将这些技术混为一谈可能会带来两个主要危险:
它破坏了你的产品目标
如果你正在寻找一种方法,使你的应用程序或网站能够进行音频或视频通信,你不会在流媒体技术中找到它。了解WebRTC和流媒体的不同之处将帮助你避免误入歧途,评估那些与你的目标不一致的供应商和解决方案。在家看流媒体电影很有趣,但它与社区建设完全相反。对于这一点,你需要到其他地方去寻找。
它可以帮助你避免不必要的滞后
你知道当Netflix停止并开始缓冲,同时显示红色小旋转圈的那些时刻吗?这是最糟糕的,而且它似乎总是发生在电影的高潮部分。造成这种困扰的原因通常是某种瞬时的网络事件,如数据包丢失的爆发或延迟的激增。但尽管它很烦人,在流媒体背景下,它至少是可以容忍的。你可以利用这个机会跑到厨房再吃点爆米花,无伤大雅。
在 WebRTC 背景下,情况就不同了。当你的用户在你的平台上进行交流时,像这样的延迟会扰乱他们的对话,并迅速破坏他们的体验。人与人之间的对话不会受到延迟或音频质量差的影响——如果你的目标是复制这些体验,那么在你的平台上的对话也不应该。这就是为什么如果平台内的社交互动是你的目标,WebRTC而不是流媒体才是你需要的解决方案的另一个原因。
结论
将WebRTC与视频流混为一谈,对于产品和工程团队来说是一个非常普遍的错误。对于那些正在寻找通过他们的平台提供真实社区的方法的公司来说,WebRTC是一个好办法。
最后,广告一下,看看即构的实时音视频SDK,看看接入到你的产品中的无缝平台通信会是什么样子。
本文来自作者投稿,版权归原作者所有。如需转载,请注明出处:https://www.nxrte.com/jishu/webrtc/23142.html