据报道，如今已安装数亿台视频监控 IP 摄像机。当然，并非所有这些都需要低延迟视频播放。视频监控通常是静态的——流记录到存储中并被分析以检测运动。有很多软件和硬件视频监控解决方案可以很好地完成它们的工作。

在本文中，我们将介绍IP 摄像机的稍微不同的用法，即 -需要低延迟通信的应用程序中的在线广播。

首先，让我们来解决关于网络摄像头和 IP 摄像头的常见术语误解。

 

网络摄像头是一种没有自己的 CPU 和网络接口的视频捕获设备。网络摄像头需要连接到计算机、智能手机或任何其他设备才能使用其网络功能和 CPU。

IP 摄像机是一个独立的设备，具有自己的网络接口和一个 CPU，用于压缩捕获的视频并将其发送到网络。因此，IP 摄像机是一台独立的微型计算机，可以连接到网络，不需要任何其他设备。也就是说，它直接向 Internet 广播。

低延迟是 IP 摄像机和在线广播的罕见要求。当视频信号源与该流的观众交互时，就会出现对低延迟连接的需求。

低延迟通常是各种游戏使用场景的要求。例如：实时视频拍卖、真人荷官视频赌场、带主播的交互式在线电视节目、远程四轴飞行器控制等。

现场赌场经销商在工作。

典型的 RTSP IP 摄像机通常将视频压缩为H.264编解码器，并且可以在两种传输模式下工作：交错和非交错。

交错模式更加流行和方便，因为在这种模式下，视频数据通过封装在网络连接内部的 TCP 协议发送到摄像机。要在交错模式下从 IP 摄像机广播流，您只需打开或重定向摄像机的一个 RTSP 端口（例如，554）。然后，播放器只需通过 TCP 连接到摄像机并获取已封装到此连接的视频流。

相机的第二种操作模式是非交错的。在这种情况下，通过RTSP / TCP建立连接，并且流量通过创建的 TCP 通道之外的RTP / UDP协议独立传输。

非交错模式更适合低延迟的视频广播，因为它使用的是RTP/UDP协议，但同时如果播放器在NAT后面会导致更多的问题。

当 NAT 后面的播放器连接到 IP 摄像机时，播放器需要知道它可以用来接收音频和视频流量的外部 IP 地址和端口。这些端口在建立 RTSP 连接时传递给摄像机的文本 SDP 配置文件中指定。如果 NAT 是正确的并且 IP 地址和端口被正确识别，那么一切都会正常工作。

因此，要以最小延迟从摄像机获取视频，我们需要使用非交错模式并通过 UDP 协议接收视频流量。

浏览器不直接支持RTSP/UDP协议栈，但支持嵌入式WebRTC技术的协议栈。

浏览器和相机的技术非常相似。特别是，SRTP是加密的RTP。但要正确地将视频直接广播到浏览器，IP 摄像机需要部分支持 WebRTC 堆栈。

为了消除这种不兼容性，我们需要一个中间转播服务器来弥补 IP 摄像机和浏览器协议之间的差距。

服务器通过RTP / UDP从 IP 摄像机获取流，并通过 WebRTC 将其共享给所有连接的浏览器。

WebRTC 技术通过UDP协议工作，因此允许服务器 > 浏览器方向的低延迟传输。IP 摄像机还通过RTP / UDP工作，并在摄像机 > 服务器方向提供低延迟传输。

由于资源和带宽有限，摄像机只能处理有限数量的流。使用代理可以扩大从 IP 摄像机到大量观众的广播。

另一方面，在使用服务器时，我们有两个通信桥：

1. 观众和服务器之间；
2. 服务器和摄像头之间。

这种拓扑结构有其自身的优点和注意事项。让我们仔细看看它们。

警告 #1 – 编解码器

编解码器是可能导致性能下降和危及低延迟操作的障碍之一。

例如，摄像头发送 720p 的 H.264 视频流，而查看器是仅支持 VP8 的 Android 设备上的 Chrome 浏览器。

如果启用转码，则每个连接的 IP 摄像机都需要一个转码会话来解码H.264并将其编码为VP8。在这种情况下，一个 16 核 2-CPU 服务器只能处理 10-15 个 IP 摄像机，每个内核大约一个摄像机。

这就是为什么如果服务器的能力不允许对来自所需数量的摄像机的信号进行转码，则应避免转码的原因。例如，我们只能为兼容 H.264 的浏览器提供服务，并建议安装适用于 iOS 或 Android 的原生应用程序，以支持 H.264 编解码器。

作为在移动浏览器中绕过转码的一个选项，我们还可以使用HLS。但通过 HTTP 流式传输不具备低延迟功能，目前不能用于交互式广播。

警告 #2 – 摄像机的比特率和丢失的数据包

UDP 协议有助于对抗延迟，但允许丢失数据包。因此，尽管延迟很低，但相机和服务器之间的严重损失可能会导致图像损坏。

为防止丢包，请确保摄像机生成的流具有适合摄像机和服务器之间的专用频段的比特率。

警告 #3 – 观看者的比特率和损失

每个连接到广播的观众都有自己的下载带宽。

如果 IP 摄像头发送的流超过观看者的资源（例如，摄像头发送1 Mbps，而观看者只能接收500 Kbps），则频道将遭受重大损失，因此 - 很多冻结和伪影在视频。

在这种情况下，我们有三个选项：

1. 针对请求的比特率，为每个查看器单独转码视频流。
2. 为观众组转码流，而不是单独转码。
3. 初步准备来自摄像机的多种分辨率和比特率的流。

转码的第一个选项可能不适合某些观众，因为 CPU 资源将在 10-15 个连接的观众之后耗尽。值得一提的是，正是这个选项带来了最大的灵活性和最大的 CPU 使用率。当您向地理上相隔约 10 人广播流时，这是理想的选择，每个人都接收动态比特率和低延迟。

第二个选项通过启用转码组来减少 CPU 负载。服务器按比特率创建几个组，例如：

• 200 Kbps
• 1 Mbps

如果观众缺乏所需的带宽，它会自动切换到可以舒适地接收视频流的组。因此，转码会话的数量不等于观看者的数量，这样在第一个选项中，而是固定的。例如，如果有两个转码组，则为 2。

第三种选择建议完全拒绝在服务器端进行转码以及使用预先准备好的具有不同分辨率和比特率的视频流。在这种情况下，摄像机被配置为发送两个或三个具有不同分辨率和比特率的流，并且观众根据其带宽切换到特定的流。

在这种情况下，转码的负担从服务器转移到摄像头，因为摄像头必须编码两个或多个流，而不仅仅是一个。

因此，我们审查了所有三个选项，以使广播与观众的带宽相匹配。假设一个转码会话占用服务器的一个核心，我们得到如下CPU负载对比表：

	调整选项	服务器上的核心数
1	为每个用户为请求的比特率转码视频流	N - 观众人数
2	为用户组转码视频流	G – 用户组数
3	初步准备来自摄像机的多种分辨率和比特率的流	0

该表清楚地表明，我们可以将转码委托给相机或服务器。选项 2 和 3 看起来最佳。

将 RTSP 测试为 WebRTC

现在，让我们进行一些测试，看看在上述场景中到底发生了什么。我们使用了一个 IP 摄像机并对其进行了测试以测量广播延迟。

在测试中，我们采用了支持RTSP和H.264 和 G.711编解码器的老式IP 摄像机D-link DCS-2103。

相机在壁橱里等待了很长时间，所以我们不得不按住相机背面的按钮 10 秒钟来重置它。

摄像机连接到网络后，绿灯亮起，路由器检测到网络中还有一台 IP 为 192.168.1.37 的设备。

然后，我们进入摄像头的网页界面并指定编解码器并允许测试：

我们需要摄像机的 RTSP 地址，所以我们打开了网络设置。在我们的例子中，RTSP-address 是live1.sdp，即摄像头在rtsp://192.168.1.37/live1.sdp可用

使用VLC Player可以轻松检查相机的可用性。媒体 – 开放网络流。

因此，我们确保相机正常工作并通过 RTSP 输出视频。

我们将使用Web Call Server 5作为测试服务器。这是一个支持RTSP 和 WebRTC协议的流媒体服务器。它应该通过RTSP连接到 IP 摄像机并获取视频流。然后，通过WebRTC广播流。

您可以将 Web Call Server 安装到您自己的主机或在 Amazon EC2 上运行预配置的实例。

安装后，将服务器切换到前面讨论的 RTSP非交错模式。您可以通过添加以下参数来做到这一点

此设置添加到 flashphoner.properties 配置的末尾，并且需要重新启动服务器：

因此，我们有一个非交错服务器，它通过 UDP 接受来自 IP 摄像机的数据包，然后通过 WebRTC (UDP) 共享流。

测试服务器部署在位于法兰克福数据中心的 VPS 服务器上。它有 2 个内核和 2 GB 的 RAM。

摄像头位于本地框架 192.168.1.37。

鉴于上述情况，我们需要做的第一件事是将端口 554 重定向到 IP 地址 192.168.1.37 用于传入的TCP / RTSP连接，以允许服务器与我们的 IP 摄像机建立连接。为此，我们只在路由器的设置中添加一条规则：

此规则告诉路由器将所有入站流量从端口 554 转换为指定的 IP 地址。

最后，我们需要知道我们的外部 IP 地址。大约需要 5 到 15 秒，只需要在 whatismyip 上进行一些搜索

如果您拥有友好的 NAT 并且知道您的外部 IP 地址，则可以使用服务器运行测试。

Google Chrome 中的标准演示播放器如下所示：

要开始播放 RTSP 流，只需在Stream字段中输入其地址。

在我们的例子中，流的地址是：rtsp://ip-cam/live1.sdp

这里，ip-cam是您的摄像机的外部 IP 地址。服务器将尝试与此地址建立连接。

测试延迟 VLC 与 WebRTC

在我们安装和配置 IP 摄像机并在VLC中对其进行测试后，配置服务器并测试通过服务器发送并通过WebRTC投射的RTSP流，我们终于可以比较延迟。

我们为此使用了一个计时器。计时器在屏幕上显示几分之一秒。我们打开计时器并通过远程服务器在本地VLC和 Firefox 浏览器上同时运行播放。

服务器 ping 100 毫秒。
本地 ping 1 毫秒。

使用计时器的第一个测试如下所示：

在这里，在黑色背景上有一个参考计时器。它显示零延迟。左侧是VLC，右侧是Firefox，它从远程服务器接收WebRTC流。

	零	VLC	火狐，WCS
时间	50.559	49.791	50.238
延迟毫秒	0	768	321

与 Firefox + Web Call Server相比，该测试表明VLC的延迟是Firefox + Web Call Server的两倍，即使 МДС 中的视频在本地网络中播放，而 Firefox 中播放的视频路由到德国的数据中心并返回。差异可能是由于 VLC 通过 TCP（交错模式）工作并使用一些缓冲来确保视频的流畅播放。

我们拍了几张照片来记录延迟值：

以下是测量结果：

	公制	零	VLC	火狐，WCS
测试1	时间	50.559	49.791	50.238
	潜伏	0	768	321
测试2	时间	50.331	49.565	49.951
	潜伏	0	766	380
测试3	时间	23.870	23.101	23.548
	潜伏	0	769	322
平均			768	341

因此，在本地网络中使用 VLC 进行测试时的平均延迟为768 毫秒. 同时，通过远程服务器路由的视频平均延迟为341 毫秒，即由于使用了UDP 和 WebRTC ，它降低了 2 倍。

测试延迟 RTMP 与 WebRTC

现在，我们通过Wowza 服务器对 RTMP 播放器进行类似的测量，并使用Web Call Server对 WebRTC 播放器进行同步测试。

左侧部分是使用 Wowza 和 RTMP 连接获取视频流。正确的部分是使用 WebRTC 获取。参考时间高于（零延迟）。

测试 - 1

测试 - 2

测试 - 3

测试 - 4

将测试结果编译到与之前相同的表中：

	公制	零	实时多播	网络RTC
测试1	时间	37.277	35.288	36.836
	潜伏	0	1989	441
测试2	时间	02.623	00.382	02.238
	潜伏	0	2241	385
测试3	时间	29.119	27.966	28.796
	潜伏	0	1153	323
测试4	时间	50.051	48.702	49.664
	潜伏		1349	387
平均			1683	384

因此，通过 RTMP在Flash Player中播放RTSP流期间的平均延迟为1683 毫秒。通过 WebRTC 的平均延迟为384 毫秒。因此，WebRTC在延迟方面要好 4 倍。

参考

WebRTC 技术
RTSP – RFC
RTSP interleaved – RFC, 10.12 Embedded (Interleaved) Binary Data
RTMP – 规范
Web Call Server – 支持 RTSP 的 WebRTC 媒体服务器
VLC – 播放 RTSP 的播放器