androidrtsp流媒体播放介绍

1、android rtsp 流媒体播放介绍一、 rtsp 协议介绍：1二、 RTP 协议介绍：7三、 Android rtsp 播放的设计：8四、时间戳同步：10一、 rtsp 协议介绍：该协议用于 C/S 模型，是一个基于文本的协议，用于在客户端和服务器端建立和协商实时流会话。实时流协议（ RTSP ）是应用级协议，控制实时数据的发送。 RTSP 提供了一个可扩展框架，使实时数据，如音频与视频，的受控、点播成为可能。数据源包括现场数据与存储在剪辑中数据。 该协议目的在于控制多个数据发送连接， 为选择发送通道，如 UDP 、组播 UDP 与 TCP ，提供途径，并为选择基于 RTP 上发送机制提

2、供方法。实时流协议（ RTSP ）建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。 换言之，RTSP充当多媒体服务器的网络远程控制。 RTSP 连接没有绑定到传输层连接， 如 TCP 。在 RTSP 连接期间，RTSP 用户可打开或关闭多个对服务器的可传输连接以发出RTSP 请求。此外，可使用无连接传输协议，如UDP 。RTSP 流控制的流可能用到 RTP ，但 RTSP 操作并不依赖用于携带连续媒体的传输机制。协议支持的操作如下：(1）从媒体服务器上检索媒体： 用户可通过 HTTP 或其它方法提交一个演示描述。如演示是组播， 演示式就包

3、含用于连续媒体的的组播地址和端口。 如演示仅通过单播发送给用户，用户为了安全应提供目的地址。(2）媒体服务器邀请进入会议：媒体服务器可被邀请参加正进行的会议，或回放媒体，或记录其中一部分，或全部。这种模式在分布式教育应用上很有用，会议中几方可轮流按远程控制按钮。(3）将媒体加到现成讲座中：如服务器告诉用户可获得附加媒体内容，对现场讲座显得尤其有用。如 HTTP/1.1 中类似， RTSP 请求可由代理、通道与缓存处理。RFC 2326ProtocolmethodReal Time StreamingApril 1998directionobjectrequirementDESCRIBEC-&g

4、t;SP,SrecommendedANNOUNCEC->S,S->CP,SoptionalGET_PARAMETERC->S,S->CP,SoptionalOPTIONSC->S,S->CP,Srequired(S->C: optional)PAUSEC->SP,SrecommendedPLAYC->SP,SrequiredRECORDC->SP,SoptionalREDIRECTS->CP,SoptionalSETUPC->SSrequiredSET_PARAMETERC->S,S->CP,Soptional

5、TEARDOWNC->SP,SrequiredRTSP 命令的状态转换表Example:C->S:OPTIONS * RTSP/1.0CSeq: 1S->C:RTSP/1.0 200 OKCSeq: 1Public:DESCRIBE,SETUP, TEARDOWN,PLAY,PAUSEExample:C->S: DESCRIBE rtsp:/ RTSP/1.0CSeq: 312Accept: application/sdp, application/rtsl,pplication/mhegS->C: RTSP/1.0 200 OKCSeq: 312Date: 23

6、 Jan 1997 15:35:06 GMTContent-Type: application/sdpContent-Length: 376v=0o=mhandley 2890844526 2890842807 IN IP4s=SDP Seminari=A Seminar on the session descriptionprotocolu=http:/www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.pse=(Mark Handley)c=IN IP4 2/127t=2873397496 28734

7、04696a=recvonlym=audio 3456 RTP/AVP 0m=video 2232 RTP/AVP 31m=whiteboard 32416 UDP WBa=orient:portraitC->S: SETUP rtsp:/ RTSP/1.0CSeq: 302Transport:RTP/AVP;unicast;client_port=4588-4589S->C: RTSP/1.0 200 OKCSeq: 302Date: 23 Jan 1997 15:35:06 GMTSession: 47112344Transport: RTP/AVP;unicast;clien

8、t_port=4588-4589;server_port=6256-6257C->S: PLAY rtsp:/ RTSP/1.0CSeq: 835Session: 12345678Range: npt=10-15C->S: PLAY rtsp:/ RTSP/1.0CSeq: 836Session: 12345678Range: npt=20-25C->S: PLAY rtsp:/ RTSP/1.0CSeq: 837Session: 12345678Range: npt=30-S->C: RTSP/1.0 200 OKCSeq: 835Date: 23 Jan 1997

9、15:35:06 GMTC->S: TEARDOWN rtsp:/ RTSP/1.0CSeq: 892Session: 12345678S->C: RTSP/1.0 200 OKCSeq: 892二、 RTP 协议介绍：RTP 报文格式RTP 报文由两部分组成：报头和有效载荷。RTP 报头格式如图 6.7 所示，其中：V ：RTP 协议的版本号，占2 位，当前协议版本号为2。P ：填充标志，占 1 位，如果 P=1 ，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。X ：扩展标志，占 1 位，如果 X=1 ，则在 RTP 报头后跟有一个扩展报头。CC ：CSR

10、C 计数器，占 4 位，指示 CSRC 标识符的个数。M: 标记，占 1 位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。同步信源 (SSRC) 标识符：占 32 位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC 。特约信源 (CSRC) 标识符：每个 CSRC 标识符占 32 位，可以有 015 个。每个 CSRC 标识了包含在该RTP 报文有效载荷中的所有特约信源。PT: 有效载荷类型，占 7 位，用于说明 RTP 报文中有效载荷的类型， 如 GSM 音频、 JPEM 图像等。序列号：占 16 位，用于标识发

11、送者所发送的 RTP 报文的序列号，每发送一个报文，序列号增 1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。时戳 (Timestamp) ：占 32 位，时戳反映了该 RTP 报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。VPXCC MPT序列号时戳同步信源 (SSRC) 标识符特约信源 (CSRC) 标识符···这里的同步信源是指产生媒体流的信源，它通过RTP 报头中的一个 32 位数字SSRC 标识符来标识，而不依赖于网络地址，接收者将根据SSRC 标识符来区分不同的信源，进行 RTP 报文的分组。特约信源

12、是指当混合器接收到一个或多个同步信源的 RTP 报文后，经过混合处理产生一个新的组合RTP 报文，并把混合器作为组合 RTP 报文的 SSRC ，而将原来所有的 SSRC 都作为 CSRC 传送给接收者，使接收者知道组成组合报文的各个SSRC 。在发送端，上层应用程序以分组形式将编码后的媒体数据传给RTP 通信模块，作为 RTP 报文的有效载荷， RTP 通信模块将根据上层应用提供的参数在有效载荷前添加 RTP 报头，形成 RTP 报文，通过 Socket 接口选择 UDP 协议发送出去。在接收端， RTP 通信模块通过 Socket 接口接收到 RTP 报文后，将 RTP 报头分离出来作相应

13、处理，再将 RTP 报文的有效载荷作为数据分组传递给上层应用。三、 Android rtsp 播放的设计：Rtsp 播放涉及到rtsp 与 rtp/rtcp 两个协议， rtsp 用于控制流的交互，rtp 用于数据流的包的封装 ;在 android 里 MyHandle 做为一个引擎控制这两路流，ARTSPConnection 用于 rtsp 的处理， ARTPConnection 用于接收rtp 数据， ARTPAssembler 的子类负责对rtp 数据解析。解析完的数据上传到MyHandle的缓冲中， RTSPSource 从缓冲列表里读取数据给解码器使用。数据流图NuPlayer:RT

14、SPSourceMyHandlerARTPConnectionARTSPConnectionARTPSourceRtsp 流程处理ARTPAssembler注：黑色的是tcp 方式，蓝色的udp 方式来接收。下面以 h264 的流的 rtp 封装的方式来说明rtp 协议对音视频数据的封装 ,rfc3984 定义对 h264 的打包方式， 对 h264 的流的解析与打包都必须遵守这个协议， h264 的数据以 nal 单元为单位打包， H.264 Payload 格式定义了三种不同的基本的负载 (Payload) 结构 .接收端可能通过RTP Payload的第一个字节来识别它们 .这一个字节类

15、似NALU 头的格式 ,而这个头结构的NAL 单元类型字段则指出了代表的是哪一种结构,这个字节的结构如下 ,可以看出它和 H.264的 NALU 头结构是一样的 .+-+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|F|NRI|Type|1. 单一 NAL 单元模式即一个 RTP 包仅由一个完整的 NALU 组成 . 这种情况下 RTP NAL 头类型字段和原始的 H.264 的NALU 头类型字段是一样的 .2. 组合封包模式即可能是由多个NAL 单元组成一个 RTP 包.分别有 4 种组合方式 :STAP-A, STAP-B, MTAP16, MTAP24.那么这里

16、的类型值分别是 24, 25, 26以及 27.3. 分片封包模式用于把一个 NALU 单元封装成多个RTP 包.存在两种类型 FU-A 和FU-B. 类型值分别是 28和29.在android的代码处理了在AA VCAssembler:addNALUnit里面处理了单一NAL单元 ,STAP-A和 FU-A三种包。 这个类将会把接收的数据包处理成上层解码器能解码帧的数据上传给上层。四、时间戳同步：对于 rtsp 的流媒体播放， 时间多戳同步是十分重要的， 根据 RTP规范，不同的 RTP媒体流是分开传输的， 且使用各自独立的时间戳进行同步。 假设在一次视频点播中，传输两路 RTP媒体流，一路

17、视频，一路音频。根据视频帧时间戳，可以实现视频流内同步， 这很好理解，通过视频帧时间戳可以计算出相邻视频帧的时间间隔，也就是视频帧之间的相对时间关系很容易通过时间戳来确定， 按照这个间隔去呈现视频， 就可以获得较好的效果。 同理，音频流也可以实现自身的同步。 那么音频和视频这两路媒体间如何实现同步呢？我们只使用音视频的RTP时间戳，看能否实现媒体间的同步。音视频的 RTP时间戳的增长速率一般是不同的，但没关系，知道了具体的单位后， 两者是可以通过单位换算联系起来的。把音视频被映射到同一个时间轴上，音频和视频帧间的相对关系很清楚。慢着，RTP规范要求时间戳的初始值应该是一个随机值， 那么假设音频

18、帧时间戳的初始值是随机值 1234，视频帧时间戳的初始值是随机值 5678，看起来应该是下面这样：这么做合适吗？我们把音频帧时间戳 1234 和视频帧时间戳 5678对应到绝对时间轴的 0 上，我们这么做的理由是什么？你可能会说， 因为那是第一个音频帧和第一个视频帧， 所以可以对应到同一个点上， 在第一幅图中我们就是这么做的， 把音频帧时间戳 0 和视频帧时间戳 0 对应到绝对时间轴的 0 上。但是 RTP规范并没有规定第一个视频帧的时间戳和第一个音频帧的时间戳必须或者应该对应到绝对时间轴的同一个点上， 从整个 RTP规范中不能直接得出这样的结论， 也推导不出这样的结论。 上图所做的转换是不正

19、确的， 为什么呢？因为在做转换时， 隐含了一个假设，我们想当然地认为这个假设是成立的。 这个假设就是第一个视频帧和第一个音频帧的时间戳应该对应到同一个点上， 即无论它们时间戳是多少， 都应该在同一时间播放。 仅仅使用 RTP时间戳是无法实现媒体间同步的， 根本的原因是音频时间轴和视频时间轴是完全独立的， 通过音频帧和视频帧的时间戳， 无法确定一个视频帧和一个音频帧的相对时间关系， 也就是无法把它们都准确定位在绝对时间轴上，只能准确定位一个。在 rtp 的规范里，要实现 RTP媒体间同步，需要借助于 RTCP，在 RTCP的 SR包中，包含有 <NTP时间， RTP时间戳 >对，音频帧 RTP时间戳和视频帧 RTP时间戳通过 <NTP时间， RTP时间戳 >对，都可以准确定位到绝对时间轴 NTP上，