从基于云的视频监控系统工作的第一天起，我们就遇到了一个问题，如果没有这个问题，就有可能终结艾维丹-那是我们的珠穆朗玛峰，攀登它消耗了很多精力，但是现在我们终于将冰斧插入了跨平台的王冠中。
通过Internet传输声音和视频的系统不应依赖于设备，Web客户端及其支持的标准，也不能与网络地址转换器和防火墙一起正常工作。 即使使用模拟摄像机，云视频监控用户也希望访问该服务，并且更喜欢在最现代的设备上观看直播视频。
用户希望以最小的延迟观看视频非常重要。 在浏览器中显示低延迟视频的几乎唯一方法是使用WebRTC（网络实时通信）。 WebRTC是用于在浏览器中进行对等视频和音频传输的一组技术，最初旨在以低延迟传输和播放视频流。 为此，使用了UDP协议。
在告诉您新引擎为用户提供了什么之前，我们将提醒您为什么以及为什么我们支持HLS技术，以及我们决定继续前进的原因。
HLS引擎：优点和缺点
（
c ）
HLS（HTTP实时流）技术是由Apple开发的，因此它的支持首次出现在该特定品牌的设备上就不足为奇了。 迄今为止，几乎所有的电视机顶盒和运行在Android OS上的许多设备都可以播放HLS格式的素材。
HLS引擎将著名的H264视频编解码器与AAC或MP3音频流结合使用以进行视频流传输。 整个音频和视频流都包装在MPEG-TS传输容器中。 为了通过HTTP进行传输，流中包含的信息分为m3u8播放列表中描述的片段。 只有到那时，这些片段以及播放列表才通过HTTP传输。 自动分割成片段意味着几秒钟的延迟。 MPEG-TS容器的这种功能。
HLS引擎还支持实时/ VOD多比特流。
HLS的主要优点：- 所有主要浏览器的内置支持；
- 易于实施（与WebRTC相比）；
- 由于您可以一次将片段加载到CDN上，因此将各种广播组织给大量观众非常方便，高效。
对于引擎的所有简单性，并不是所有的事情都像看起来那样平滑。 主要问题是第三方播放器的开发人员已偏离了苹果的建议，例如在支持的音频格式方面。 特别是，许多开发人员开始增加了使用流行音频流的功能：mpeg2视频，mpeg2音频等。结果，我们不得不为不同的播放器创建不同的播放列表格式。
但是HLS引擎的最大问题之一是数据传输的高延迟。
“刹车”的由来
HLS的高延迟的主要原因在于，程序员创建了一个引擎来获取最高质量的图片。 因此，所使用的帧间隔的参数和回放缓冲器的大小根本不适合进行实况视频广播。 因此，视频序列的传输会出现相当高的延迟，可能会是5到7秒。
一方面，这对于那些从视频托管服务器观看电影的人来说有点。 但是对于视频监视系统，镜头传输的延迟可能非常重要。
如果您正在观察一个每小时有员工下班的办公室，那么5秒钟的延迟并不重要。 但是人们开始抱怨说，例如，在广播足球比赛时，聊天中已经写了GOOOOOOL，但这不在视频中：）。 我们已经有很多自定义案例，其中Ivideon应该几乎取代skype。
是否可以克服HLS的延迟？ 这个问题的答案听起来像是经验丰富的斗士在新手干扰者面前的演讲中的演讲：“无法灭绝老鼠，但可以将老鼠的数量减少到合理的最低水平。” 因此，由于HLS延迟，将其删除为零将不起作用，但是市场上有一些解决方案可以显着减少延迟。
浅切
该引擎的另一个缺点是使用小型文件进行数据传输。 看来这不好吗？
任何试图将大量小文件从一种介质复制到另一种介质的人，都可能会注意到，写入这样的文件集的速度比同大小的一个大文件要低得多。 是的，对硬盘驱动器的访问强度显着增加，通常会对整个计算机的性能产生负面影响。 因此，以较小的10秒片段的形式传输视频数据也有助于增加引擎延迟。
简要概述HLS技术的所有优点和缺点。
HLS的优点：- 能够与任何设备一起使用。 您可以在任何现代设备上观看视频，无论是智能手机，平板电脑，笔记本电脑还是台式机。 最主要的是Web浏览器是最新的，并且与HTML5和Media Source Extensions兼容。
- 出色的画质。 使用自适应数据传输功能，您可以根据Internet连接的带宽动态更改传输的视频序列的质量，而算法则力求保持最高质量。
- 不需要用户设备的复杂配置。
缺点：- 在某些设备上使用引擎的支持有限。
- 图像传输中的高延迟。
- 由于使用了小文件，因此开销和优化的复杂性大大增加。 由于容器的性质，我们永远不会获得小于段大小的延迟。
HLS的弊端超过了它对我们的优势，并迫使我们寻找其他选择。
什么是WebRTC？
（
c ）
WebRTC由Google于2011年开发，旨在以最小的延迟在浏览器和移动应用程序之间流式传输视频和音频。 为此，使用了标准的UDP协议和特殊的流控制算法。 今天，它是一个开源项目，它得到了Google的积极支持并正在开发中。
WebRTC是用于视频和声音的对等传输的一组技术。 也就是说，例如，使用WebRTC的用户浏览器可以直接相互传输数据，而无需使用远程服务器来存储和处理数据。 最终用户的浏览器和移动应用程序还将处理所有信息。
所有流行浏览器的开发人员都赞赏这项技术的便利性和强大功能。 如今，WebRTC支持已在Mozilla Firefox，Opera，Google Chrome（以及所有基于Chromium的浏览器）以及适用于Android和iOS的移动应用程序中实现。
WebRTC具有所有无疑的优点，但有几个明显的缺点。
困难的选择
WebRTC在网络方面要复杂得多，因为它与P2P有关。 调试，测试很困难，它的行为可能无法预测。 在这种情况下，我们需要克服NAT和防火墙，我们需要在UDP被阻止的网络中提供工作。
Google的WebRTC实施很难使用。 甚至有一家提供SDK组装服务的公司。 另外，Google的实施很难与我们的系统集成，因此不会对所有视频进行转码。
但是，长期以来，我们一直希望为用户提供处理完整的“实时”视频序列的机会，并最大程度地减少屏幕上图像与事件本身的滞后。 另外，我们希望在延迟很关键的情况下，更舒适地使用PTZ摄像机。
考虑到到目前为止，与滞后作斗争的其他实现方式功能有限且工作效果明显较差，我们决定使用WebRTC。
我们做了什么
正确实施WebRTC平台并非易事。 任何错误的计算或不准确都可能导致以下事实：与其他平台相比，视频序列传输的延迟不仅不会减少，而且还会增加。
为了使WebRTC正常工作，首先，有必要对堆栈进行技术更新以处理Web视频。 我们做到了。
首先，我们在Websocket的顶部实现了WebRTC信令协议服务器，还基于webrtc.org SDK在Web上部署了WebRTC对等服务器。 它的任务是将视频流以H.264 + Opus / G.711格式分发给客户端WebRTC对等方，而不进行视频转码。
我们选择Websocket作为信令协议，因为它已经在所有流行的Web浏览器中提供了质量支持。 因此，与AJAX相比，不仅可以大大减少开发开销，而且可以不浪费时间和资源进行重复的TCP和TLS握手。
事实是，默认情况下，WebRTC不提供正确配置，支持和中断源和客户端应用程序之间的实时视频通信所必需的信令协议。
为了独立实现信号技术，我们需要开发自己的信号服务器，并支持多种Web协议（Websocet，WebRTC）。 还具有实时安全地管理会话和通知，视频管理和许多其他参数的能力。
通过减少延迟（不是由于P2P，而是由于UDP和旨在减少延迟的流控制），我们克服了P2P的局限性。 这也嵌入在WebRTC中，因为主要用例是通过浏览器进行p2p对话。
在移动客户端中，我们使用webrtc.org SDK实现了播放器，因为只有在其中正确地实现了流控制，才存在所有已知的前向纠错（FEC）方案，并且正确实现了为所有浏览器重新发送数据包的机制。 Google积极开发SDK webrtc.org也很重要。
实施WebRTC有什么结果？
为了观看摄像机的实时视频，我们在帐户中添加了一个基于WebRTC的新优化播放器。 它提供了高速录像，并完全消除了随着观看时间增加而产生的延迟累积问题。
在Ivideon云服务中实现WebRTC支持后，我们可以放心地说，现在我们的客户可以观看完整的实时视频。 现在，播放镜头的延迟不超过一秒钟！ 为了进行比较，以前的HLS引擎提供了5-7秒的延迟的视频传递。 视频演示速度的差异非常明显，用户在开始使用我们的视频服务后会立即注意到它。
如我们所料，新播放器的实施使我们能够提高PTZ的响应速度以及与摄像机的语音通信。
我们只想提请注意一点。 新的WebRTC播放器仍处于测试模式。 这就是为什么我们默认情况下不将其连接到所有客户的原因。 但是您可以通过启用相机设置中的相应项目来自己激活它（为此，您需要进入您的
个人帐户 ）。
Ivideon服务中WebRTC实施的功能
WebRTC目前仍是一项实验技术。 尚未在所有浏览器和用户设备中，也并非在所有相机中，都正确实现了对它的支持。
这说明了我们尚未将WebRTC播放器设为所有用户的默认默认设置的事实。
目前，我们建议仅在Google Chrome浏览器中使用WebRTC。 Firefox和Safari的最新版本也支持该技术，但不幸的是，仍然不稳定。
我们尚未为移动设备上的浏览器实现WebRTC支持。 现在，如果您从移动设备登录并激活WebRTC，则此模式将不起作用。 但是，WebRTC位于我们用于
Android和
iOS的移动应用程序中。
在结束有关我们服务中WebRTC实施功能的故事时，我们注意到了另外两点。
首先，该技术致力于实时广播实时视频。 因此，如果您的频道带宽不足以进行视频传输，则会注意到帧数减少（使用HLS时，您会注意到视频衰落和延迟增加，而帧不会丢失），但是视频仍将实时广播。
其次，由于该技术旨在实时处理实时视频，因此我们不使用它来处理存档的视频数据。
其他服务变更
自动引擎选择机制不再包含Flash。 您仍然可以使用这样的播放器，但是为此您需要在帐户或相机设置中手动选择它。 这不是时尚，仅根据我们使用Flash的用户提供的服务统计数据，实际上没有更多了。 为了确定用户的浏览器是否支持它，我们损失了大约2秒钟的宝贵时间。
这是我们基于云的视频监控系统和个人帐户中等待您进行更改的简要摘要。 敬请期待，敬请期待！