基于android手机实时监控ipcam视频之一:RTSP

       我以前做过一个这样的项目,基于android实现手机实时监控ipcam,ipcam厂商提供控件,该控件安装以后,在IE上面输入ipcam的ip地址,就可以实时查看ipcam的图像,这实时视频是通过HTTP协议来实现,HTTP的缺点是延时大,带宽消耗大,不能实时查看高分辨率的视频,优点是实现简单,基于TCP的传输机制能保证系统的稳定性。但ipcam同时也支持RTSP的方式来传输视频流,RTSP的优点是能保证较低的延时和带宽,缺点是RTSP协议需要自己来实现,RTSP协议是用RTP协议来传输流媒体,因此在网络带宽不好的情况下,会有丢包,抖动的现象。

       目前在windows上RTSP支持的比较多,但在android上,android支持RTSP,但只限于有限的媒体格式,而且还支持文件播放形式。在我们的项目中,是要实时监控ipcam的视频流,要求支持H.264 MPEG4,因此决定自己实现一套这样的软件。

     RTSP协议采用live555,软解码采用ffmpeg,框架采用mediastream2。我们先来了解一下RTSP协议。

    RTSP协议栈分客户端和服务端,客户端请求视频流,双方约定一些参数信息,然后服务端就发送视频流发送到客户端指定的接收端口。服务端是通过RTP协议打包媒体流到客户端,客户端相应地要进行RTP解析才能播放,因此RTSP协议上是一个会话控制协议,媒体播放是基于RTP协议,网络拥塞控制也是基于RTP协议里面的RTCP来实现的,如下图所示:

  RTSP控制分组是通过TCP协议来传输的,首先客户端要创建一个与服务端的TCP连接,也称会话。接下来的信令交互都在这个会话上来进行。RTSP是通过报文的传输来交互的

RTSP有两类报文:请求报文和响应报文。请求报文是指从客户向服务器发送请求报文,响应报文是指从服务器到客户的回答。

由于 RTSP 是面向正文的(text-oriented),因此在报文中的每一个字段都是一些 ASCII 码串,因而每个字段的长度都是不确定的。

RTSP报文由三部分组成,即开始行、首部行和实体主体。在请求报文中,开始行就是请求行,RTSP请求报文的结构如图2所示。


图2 RTSP请求报文的结构

RTSP请求报文的方法包括:OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。RTSP请求报文的常用方法及作用如表1所示。

表1 RTSP请求报文的常用方法及作用

 

方法

作用

OPTIONS

获得服务器提供的可用方法

DESCRIBE

得到会话描述信息

SETUP

客户端提醒服务器建立会话,并确定传输模式

TEARDOWN

客户端发起关闭请求

PLAY

客户端发送播放请求

 

响应报文的开始行是状态行,RTSP响应报文的结构如图3所示。


图3 RTSP响应报文的结构

1.3.    RTSP交互过程

C表示RTSP客户端,S表示RTSP服务端

 C->S: OPTION request            //询问S有哪些方法可用

S->C: OPTION response        //S回应信息中包括提供的所有可用方法

 C->S: DESCRIBE request      //要求得到S提供的媒体初始化描述信息

S->C: DESCRIBE response      //S回应媒体初始化描述信息,主要是sdp

 C->S: SETUP request         //设置会话属性,以及传输模式,提醒S建立会话

S->C: SETUP response         //S建立会话,返回会话标识符及会话相关信息

 C->S: PLAY request          //C请求播放

S->C: PLAY response          //S回应请求信息

S->C: 发送流媒体数据

 C->S: TEARDOWN request     //C请求关闭会话

S->C: TEARDOWN response     //S回应请求

上述的过程是标准的RTSP流程,其中第3步和第4步是必需的。

我们要注意的是,在第2步中,服务端返回的SDP信息非常重要,客户端通过这个SDP来获取服务端媒体信息,比如编码方式(决定了客户端采用何种解码器),RTP的payload(决定如何接收RTP包),音频的采样率,以及mepg4编码和H.264编码的一些额外信息(比如config字段,pps和sps字段)。在第3步中,发送setup报文,要带上端口号,这个端口号是客户端创建的用于接收服务端媒体流的端口,因此客户端需要将此端口号告诉服务端,服务端才能将媒体流发送到该端口,客户端才能正确接收,对于RTP over tcp的情况,情况就不一样了,媒体流会在会话里面进行传输,因为客户端与服务端已经创建了一条TCP连接,在这个连接里面既要完成信令的交互,也要完成媒体传输,因此在setup报文里要带上是否是RTP over UDP和RTP over TCP的标示。另外,在SDP里面定义了几个媒体,就要发送几个setup报文。比如SDP里面有一路video和一路audio,则要分别向video和audio发送setup请求。



你可能感兴趣的:(流媒体)