WebRTC 和 IP 摄像头的交互

过去的几个月中,越来越多的开发者希望获得如何连接WebRTC与IP摄像头的信息。解决这个问题通常需要大量对底层媒体协议细节的深入了解。此外,在创造“Demo”和实际产品之间的距离也很大。我们将在本文中介绍如何利用Kurento的媒体服务器来正确地实现它。

WebRTC Media Gateways for media interoperability

对于集成IP摄像头到WebRTC应用,首先需要实现媒体交互。这意味着摄像头提供的媒体流需要和WebRTC编解码器和浏览器支持的格式兼容。这也意味着将IP摄像头吐出的内容翻译成WebRTC浏览器支持的内容。为了实现这一点,通常需要一个被称为WebRTC 媒体网关的技术。为了理解这样一个网关的工作,来看以下几点:

Most IP cameras available in the market (excluding exotic ones) publish media through any of these mechanisms:

市面上大部分的IP摄像头(国外产品除外)通过以下几种机制来发布media:

  • RTSP/H.264: 这类型的摄像头通常用于安防场合。它们使用RTSP协议来建立一个RTP媒体会话。换句话说,媒体传输时通过RTSP发生的信令基于plain(简单的)RTP。不同的摄像头厂商可能支持不同的RTP规格,但是就我看到的大部分摄像头而言,AVP是唯一可用的选项。在这些摄像头中,同样典型的,H.264是编解码器唯一的选项。

  • HTTP/MJPEG: 这类型摄像头使用HTTP流来signaling,传输,将一系列的JPEG图像编码为视频。这些摄像头的硬件相对更简单,只需要很少的资源来操作。这就是为什么他们被更多用在电池功耗或者在意负载的场合(如机器人,无人机等)。不足的是,它们的视频质量显著下降。

因此,为了实现WebRTC交互性,媒体网关要求执行如下图所示的媒体管理程序。网关首先要有可以说同一门语言(如RTSP/RTP或HTTP)的能力,其次是解码从摄像头收到的视频流(如H.264或MJPEG),然后重新将它编码成VP8格式(WebRTC最普遍的编码),最后使用WebRTC协议栈将其发送到WebRTC客户端。

这里写图片描述

图1:WebRTC媒体网关在RSTP/H.264-HTTP/MJPEG摄像头和WebRTC浏览器之间提供媒体交互性的通用方案。媒体信息(暗红线)需要恰当的协议和编解码器适配来将摄像头提供的格式转换成WebRTC客户端支持的格式。但是,这还不足以在真实的网络中工作,因为真实网络需要考虑浏览器提供的RTCP反馈来管理丢包和拥塞。这对于达到令人满意的QoE是非常重要的,因为不是所有的WebRTC网关都有能力对RTCP反馈提供恰当的终止语义。

Dealing with the network: making a production ready application.

媒体适配对于实现可工作的应用是不够的。你还需要管理真实网络是如何工作的。为了实现这一点,WebRTC协议栈使用SAVPF规格,最后一个’F‘ 表示“Feedback”。这个Feedback组成了图1场景描绘的RTCP包,它包含了可能影响质量的网络条件的信息,从WebRTC客户端发往网关。

如上所述,大部分IP摄像头仅支持AVP(没有’F‘),这意味着网关不能传送反馈给摄像头(如发生在很多SFU架构中的那样),但是需要完全控制它。用术语说就是,网关必须终结RTCP反馈。

这是非常重要的。你必须确信你使用的WebRTC网关是真实的,并且完全终结和为RTCP传输提供语义。当RTCP传输未被终结时,你能感受到的是毁灭性的QoS,基本上视频停滞了。

为了理解视频停滞的原因,让我们分析一下当网关没有终结两种简单的反馈RTCP包:PLI和REMB时发生了什么:

  • 如果网关没有管理PLI RTCP包的能力,一旦网络发生丢包时,视频就会停滞。这是由于VP8编码器的工作方式。 它可能不会在长时间周期内(通常是分钟)产生关键帧。Every time a PLI packet is not managed by the gateway by generating a new key frame,WebRTC客户端将不能解码直到一个新周期的关键帧抵达(重申,这可能需要几分钟)。一些网关使用一些技巧来处理这个问题:以很高频率(如每隔两秒钟)产生关键帧,但是这会显著降低VP8 编解码器的视频质量,因为关键帧消耗掉了更多的带宽。

  • 如果网关不管理REMB RTCP请求,并且不考虑任何的协商控制机制,网关将不会对VP8编码器要求降低比特率的拥塞控制命令做出响应。这意味着,一旦网关和WebRTC客户端之间的连接被堵塞,WebRTC浏览器将会被视频传输超负荷,相关的丢包也会发生,导致体验质量的进一步下降,然后视频停滞。

Doing it right with Kurento Media Server

Kurento媒体服务器工具箱可以灵活创造丰富的WebRTC媒体网关,编程语言可以使用Java或者JavaScript。对于Kurento媒体服务器的介绍,可以参见 文档。在Kurento实现WebRTC媒体服务器与IP摄像头的交互是简单且安全的。你只需要考虑三个方面:

  • Kurento 媒体服务器 PlayerEndpoint 支持从不同来源读取视频流,包括RTSP/RTP和HTTP/MJPEG。换句话说,PlayerEndpoint有能力管理对IP摄像头媒体的捕获。

  • Kurento 媒体服务器 WebRtcEndpoint 支持发布媒体流到WebRTC浏览器,提供对RTCP反馈的完全终结。这意味着,每次PLI包被收到时,WebRtcEndpoint 应该命令VP8编码器生成一个新的关键帧。这同时也意味着通过命令VP8编码器降低质量,来实现对REMB反馈和拥塞控制的响应。

  • Kurento 媒体服务器发挥“不可知媒体能力”,当两个不兼容的媒体元素互联时,所有适当的转换对开发者来说都是透明的。因此,连接PlayerEndpoint源到WebRtcEndpointsink,H.264/MJPEG到VP8的转码就会被执行。

这里写图片描述

图2:Kurento媒体服务器实现了一个WebRTC网关,可以支持RTSP/H.264和HTTP/MJPEG。仅仅几行代码实例化PlayerEndpoint和WebRtcEndpoint元素,然后将它们连接,就可以创建一个网关。Kurento媒体服务器的内部逻辑负责执行必要的编解码适配,以及RTCP反馈的管理,而不需要开发者去关注。

因此,如图2所示,创建WebRTC媒体网关来实现RTSP/H.264,HTTP/MJPEG摄像头与WebRTC的交互是简单的。实现这部分逻辑的JavaScript源代码如下:

var pipeline = ...//Use Kurento Client API for obtaining your pipeline.

//Create the PlayerEndpoint for receiving from the IP camera. HTTP and RTSP uris are supportd
pipeline.create("PlayerEndpoint", {uri: "rtsp://your.rtsp.address"}, function(error, playerEndpoint){

    //Create the WebRtcEndpoint
    pipeline.create("WebRtcEndpoint", function(error, webRtcEndpoint){

    //If working with trickle ice, some code for candidate management is required here.

        //Connect playerEndpoint to webRtcEndpoint. This connection activates the agnostic media
        //capability and the appropriate transcodings are configured and activated.
    playerEndpoint.connect(webRtcEndpoint, function(error){

                //Media starts flowing ... enjoy
                player.play(function(error){
        });
    });
    });
});

如果你需要JavaScript的完整可用例程,可以访问 GitHub repository.

所有这些的亮点是向你的网关添加更多的能力,如视频记录甚至是内容分析,它们仍然是非常简单的,你只需要实例化相应的媒体元素并将它们连接到期望的媒体拓扑。这便是使用Kurento的优势:模块化。

你是否有使用Kurento实现WebRTC和IP摄像头交互的经验?欢迎分享给我们。

展开阅读全文

没有更多推荐了,返回首页