在媒体服务器中实施WebRTC-做法和政策

1.实时流向浏览器-没有解决方案。还是在那里？

大约20年以来，计算机的网络带宽和计算能力已使IP协议能够以接近实时的方式压缩和广播声音和视频。在此期间，W3C和IETF等中央标准化组织以及许多大小公司已经开发了数百种标准和协议，以在计算机和移动设备上有效地压缩，打包，转发，同步和播放音频-视频内容。 IP上的实时视频捕获，压缩和广播受到了特别的关注，因为，首先，IP是所有级别上最便宜，最易访问的，其次，视频会议和视频监视技术至关重要，并且需求很大。

似乎已经过去了很多年，已经完成了很多工作。 20年后，我们可以在这方面观察到哪些出色的成就？让我们卸下盒盖（当然，这不是Pandora的盒，也不是“蠕虫的罐头”），然后看看经过成千上万有才华的软件工程师的多年工作之后，可获得了哪些奇妙的技术和机会。一位1998年的程序员，他首先通过网络发送声音，一位医生想要一个简单，便宜且可靠的远程医疗解决方案，一位老师需要进行远程授课-现在他们打开这本书，充满了光明的希望，他们看到了什么？在充满令人难以置信的行销，愤世嫉俗的资本主义以及发烧友为改善事物而进行的拼命尝试的进攻性锅中，各种编解码器，协议，格式和应用程序都在浮动。这就是“社区” IT汤实时为消费者提供的功能。赶上闻起来少的自己，尝试，测试，购买。没有简单有效的解决方案。与流传输不同，流传输不需要实时：毕竟已经有大约5年的历史了，HLS标准可在任何浏览器和设备上运行，解决方案提供商只需在您的服务器上安装HLS分段器即可安然入睡。

这是RTSP-许多控制台和专业设备都在播放它，但浏览器却无法播放。这是RTMP-Safari不想在iOS上播放，而且并非所有Android都可以播放。 Chrome浏览器将其禁止为不可信任。这是MPEG2-TS-浏览器也不播放它。 HTML5媒体源扩展（MSE）-适用于5-10秒长的视频段（即适用于HLS / Dash），但短于1秒的短段-并非始终稳定，在不同的浏览器中效果不同iOS不支持。

一个人想知道，幼儿园如何将成组安装的摄像机中的视频发送给希望在任何设备上随时打开浏览器，而无需安装任何插件来实时观看孩子的家长呢？为什么所有的幼儿园都不提供这种服务？是的，因为提供这样的服务非常昂贵。我们需要为将在其中播放视频的移动设备开发Apps-因为浏览器无法播放。需要更多。

让我们定义“接近实时”的概念。对于视频监视，此延迟少于5秒，对于视频会议，此延迟少于1秒。 HLS协议的平均延迟为20-30秒。也许它某种程度上适合幼儿园，但是对于安全视频监视，视频会议和网络研讨会，则需要另一种技术。

因此，直到现在，更确切地说，直到2017年夏天，还没有统一的标准或协议可以将音频视频实时广播到任何设备上的任何浏览器。出现这种情况的原因，我们将在以后的文章中考虑。这些原因都不是技术性的。同时，让我们看一下至少在2017年夏天发生的事情，但是仍然提供了一种技术，可以解决上述问题。这项技术是WebRTC，在此资源和整个网络上都写有很多关于它的文章。它不再是全新的，在撰写本文时，W3C认为WebRTC 1.0已完成。这里我们不会谈论WebRTC是什么。如果读者不熟悉这项技术，那么我们建议您在中心或Google上进行搜索并结识，它的用途以及它的一般工作方式。在这里，我们只是说这项技术是为浏览器中的对等通信而开发的，有了它，您可以在没有任何服务器的情况下实现视频聊天和语音应用程序-浏览器直接与浏览器通信。 WebRTC受到所有设备上所有浏览器的支持，并且在2017年夏天，Apple最终向我们求助，并将其添加到iOS的Safari中。自RTMP于2015年开始失效以来，正是这一事件使WebRTC成为了向浏览器实时流式传输的最通用和普遍接受的技术。WebRTC受到所有设备上所有浏览器的支持，并且在2017年夏天，Apple最终向我们求助，并将其添加到iOS的Safari中。自RTMP于2015年开始失效以来，正是这一事件使WebRTC成为了向浏览器实时流式传输的最通用和普遍接受的技术。WebRTC受到所有设备上所有浏览器的支持，并且在2017年夏天，Apple终于找到了我们并将其添加到iOS的Safari中。自RTMP于2015年开始失效以来，正是这一事件使WebRTC成为了向浏览器实时流式传输的最通用和普遍接受的技术。

但是，从摄像机流向浏览器的流与它有什么关系呢？但是事实是WebRTC在功能上非常灵活，并且允许您仅将音频视频发送给两个参与者（对等方）中的一个，而只接受另一个。因此，产生了使WebRTC适应媒体服务器的想法。媒体服务器可以从摄像机接收视频，与浏览器建立通信，并同意只有它会发送，浏览器才能接收。因此，媒体服务器可以同时将视频从摄像机发送到许多浏览器/查看器。相反，媒体服务器可以从浏览器接收流，并将其转发到其他许多浏览器，从而实现人们所期望的“一对多”功能。

那么，最终一切都形成了吗？ Akuna Matata和幼儿园将能够在主机上或AWS上的某处安装这样的媒体服务器，从那里的每个摄像头发送一个流，然后从那里将其分发给父母的浏览器，所有延迟都不会超过一秒钟。总的来说-是的，生活越来越好。但是有问题。这些问题与以下事实有关：WebRTC实际上对于此类任务而言牵强附会；它不是为它们而设计的，也不是很适合他们。除编解码器兼容性外，问题主要与此类媒体服务器的可伸缩性有关。也就是说，同时可以在一台服务器计算机上为100位父母提供服务，而500位父母已经很困难。虽然网络允许。并查看具有100个连接的服务器上的处理器负载-它已经接近90％。为何如此？毕竟，只是发送声音视频。

如果使用同一流，如果通过RTMP协议发送到Flash Player，则可以轻松地支持来自一台服务器的2000个同时连接。 WebRTC只有100个吗？
为什么？原因有两个：首先，WebRTC协议在计算上要昂贵得多-例如，在那里所有数据都被加密，并且占用了大量处理器时间。我们将更详细讨论的第二个原因是协议的创建者Google的效率极低。Google为该实现提供了源c ++代码，以适应服务器，网关和其他希望支持WebRTC的应用程序：webrtc.org/native-code

2 Google的本机WebRTC API和媒体服务器兼容性

回想一下，WebRTC的创建是为了将音频视频从浏览器传输到浏览器，并且没有支持许多同时连接的任务。因此，不仅如此，在浏览器中实施WebRTC并没有完全忽视技术系统的设计和体系结构的基本原理-优雅（仅此而已），效率，高性能。重点是可靠性和可管理性，以及网络中的错误和极端情况-数据包，连接等的丢失。那当然是好的。但是，仔细研究后发现，这是Google在WebRTC实施中唯一的优点。

让我们看一下要点，因为这些要点对于媒体服务器使用Google WebRTC实现非常困难。

2.a代码是应有代码的十倍，效率极低，

这是一个经过验证的数字。首先，您下载约5 GB的代码，其中只有500 MB与WebRTC有关。然后，您尝试摆脱不必要的代码。毕竟，对于媒体服务器的需求，您不需要编码/解码；服务器应该只接收内容并将其转发给所有人。当您删除了所有不必要的内容（并且删除的内容远远少于您想要的）时，您仍然拥有100 MB的代码。这是一个了不起的人物。是她，她比应该的大十倍。

顺便说一句，在这一点上，许多人会说-怎么不需要编码/解码？从AAC转换为Opus，反之亦然呢？ VP9-> H264转码怎么样？如果要在服务器上进行此类转码，则也不能同时拉5个连接。如果确实需要，则代码转换不应由媒体服务器执行，而应由另一个程序进行。

但是，让我们回到code肿的代码问题并进行说明。当发送已压缩的视频帧时，您认为函数调用堆栈的深度是多少？一个调用winsock（在Windows上）的send或sendto函数（WSASend / WSASendTo）？不，当然，还需要做更多的工作。对于WebRTC，您需要通过RTP协议打包帧并对其进行加密，这总共为我们提供了SRTP协议。有必要在丢包的情况下保存该帧，以便以后再次发送。这应该涉及多少个c ++对象和线程？

这就是WebRTC 61的



操作方式：从此屏幕快照中可以看到，从我们将压缩的帧馈送到WebRTC直到Paced_Sender对象的队列为止，调用堆栈深度为8（！），其中涉及7个对象！

然后，一个单独的线程（线程）PacedSender从队列中拉出我们的帧并将其进一步发送以进行处理：



最后，我们进入第4步，在该步骤中，已经RTP打包和加密的帧依赖于要发送到网络的队列，该队列与另一个线程进行通信。此时，调用堆栈的深度（在PacedSender线程上）为7，并且还涉及3个新对象。繁忙的线程发送也将在3-4个嵌套函数调用之后调用最终的WSASend / WSASendTo，并将涉及3-4个新对象。

因此，我们看到了3个线程，每个线程都做得很好。对此类系统进行编程的每个人都有这样的想法，以及真正需要做什么。根据我们的估计，这里至少有90％的对象和代码是多余的，并且违反了面向对象编程的原理。

2.b每个连接分配4-5个线程

毫无疑问，在此示例中，线程数使一切正常。必须提供异步处理，而不要阻塞任何人，并且需要所有3个线程。通常，一个PeerConnection WebRTC分配4-5个线程。好吧，有可能保持在3以内。问题是，这适用于每个连接！例如，在服务器中，您可以保存3个线程，但是它们将为所有连接提供服务，而不是为每个连接分配3个线程。线程池无疑是用于此类任务的服务器解决方案。

2.c通过Windows消息工作的异步套接字

Windows上的Google WebRTC代码通过WSAAsyncSelect使用异步套接字。服务器编程人员知道，在服务器上使用select函数很容易自杀，而WSAAsyncSelect虽然可以改善这种情况，但幅度不大。如果要支持成千上万的连接，则Windows上有比异步套接字更好的解决方案。必须启用重叠的套接字和IO完成端口，将通知发送到正在工作的线程池。

2.d结论

因此，我们可以得出结论：可以在没有重大更改的情况下将Google的WebRTC代码应用于媒体服务器，但是该服务器将无法拉动数百个同时连接。可能有两种解决方案：

毫不夸张地说，要对Google代码进行重大更改几乎是不可能的-毕竟，所有这些对象彼此之间都非常紧密地契合在一起，没有封装功能，也不是执行某些工作的独立模块。在其他情况下，使它们保持不变是不可能的。

完全不要使用Google代码，而要使用libsrtp之类的开放库自己实现所有功能。也许这是正确的方法，但是除了这也是一项艰巨的任务之外，您还可能会遇到这样一个事实，即您的实现将与Google完全不兼容，因此将无法使用，或者在所有情况下都无法使用，例如，铬是不能容忍的。然后，您可以与Google的员工争论很长时间，证明您已遵循标准，但没有遵循，您将获得一千次的正确答案。但是他们充其量只能说-“我们会修复它，也许以后会解决。”您需要立即调整为Chrome。和重点。

3.为什么一切都如此悲伤

实时流向浏览器的这种情况非常典型地说明了“业务驱动技术”有时会导致什么。以业务为动力的技术正在朝着业务必不可少的方向发展，并在使该业务令人满意的范围内发展。由于现在有了业务方法，我们有了个人计算机和移动电话-没有政府或中央计划部会对开发和将所有这些消费类技术引入大众如此感兴趣。受其所有者的个人利益推动，私人企业在出现技术机会后便立即这样做。

长期以来，人们已经知道，理解并接受了非必需的消费品和服务，如果没有这些消费品和服务，私营企业可以更好地开发它们，那么对人来说至关重要的东西-能源，道路，警察和学校教育-应该集中开发。国家控制的机构。

我们，苏联的孩子们和他们的心态“让我们制造技术上正确且强大的技术，以便人们可以使用它，一切都很好。”当然可以说，在计划中的苏联系统中（如果政府突然决定），流技术实时IP可以在一年内开发和实施，并且比20年后的业务现在好一个数量级。但是我们也知道，那时它不会发展，变得过时，最终从长远来看，仍然会失去一些西方商业技术。

因此，由于无需流填充就能相处得很好，所以理应由私人企业摆布。开发它是为了他们自己的利益，而不是为了消费者的利益。它怎么不符合消费者的利益？但是供应和需求呢？消费者需要什么，企业才能提供？但它不提供。所有消费者都在大喊大叫-Google在WebRTC中支持AAC音频，但是Google绝不会这样做，尽管它只是吐槽而已。 Apple绝对不会提供该死的东西，也不会在其小工具中实施任何急需的流技术。为什么？是的，因为企业并非总是能够满足消费者的需求。当他是垄断者并且不害怕消费者流失时，他不会这样做。然后，企业正忙于巩固其地位。因此，Google近年来收购了许多声音编解码器制造商。现在，它推动了Opus音频，并迫使整个世界对AAC-> Opus进行转码以匹配WebRTC，因为所有技术都已长期转换为AAC音频。据称，谷歌以AAC是一项付费技术而Opus是免费的这一事实为证。但是实际上，这样做是为了将其技术确立为标准。就像苹果曾经使用它令人讨厌的HLS一样，或者像Adobe以前使用它不负责任的RTMP协议一样。小工具和浏览器在技术上仍然是相当困难的事情，从这里开始出现垄断者，从那里开始，正如他们所说的，事情就在那里。而且W3C和IETF是由同一垄断者赞助的，因此“永远制造技术上正确且强大的技术，使人们可以使用它并且一切都很好”的心态已经不复存在了。但是应该如此。

如何解决这种情况？显然，只要等待“正确”的业务驱动技术，竞争的结果以及各种其他奇妙的事情，最终，他们就会想到一些民主的，适合简单农村医生的东西，以便他可以通过普通的互联网提供远程医疗服务。确实，有必要进行修改，而不是针对简单的乡村医生，而是针对那些可以支付大笔费用的人，该业务长期以来一直在提供实时流媒体解决方案。良好，可靠，需要专用网络和专用设备。在许多情况下，不能使用IP协议。哪一个（这是造成这种情况的另一个原因）不是实时创建的，因此并不总是可以保证。并非总是如此，但不是在紧急情况下，它目前非常合适。因此，让我们尝试WebRTC。迄今为止，在所有罪恶之中，他是最小，最民主的。毕竟，您需要为此感谢Google。

4.有关实现WebRTC的媒体服务器的一些知识

Wowza，Flashphoner，Kurento，Flussonic，Red5 Pro，虚幻媒体服务器-这些都是支持WebRTC的媒体服务器。它们提供从浏览器到服务器的视频发布，并通过WebRTC从服务器向浏览器广播视频。

这些软件产品解决了本文中描述的问题，它们以不同的方式和不同程度的成功。其中一些（例如Kurento和Wowza）直接在服务器中进行音频视频转码，其他一些（例如Unreal Media Server）不进行自身转码，而是为此提供其他程序。某些服务器（例如Wowza和Unreal Media Server）支持通过一个中央TCP和UDP端口在所有连接上进行流传输，因为WebRTC本身为每个连接分配了一个单独的端口，因此提供程序必须在防火墙中打开许多端口，这会造成安全问题。

所有这些服务器都以不同的方式实现了许多要点和精妙之处。尊贵的用户，您认为这多少适合消费者。