live555 rtsp rtp学习笔记

文章来源：http://blog.csdn.net/keen_zuxwang/article/details/71439457

live555 rtsp rtp学习笔记

live555： 
live555是一种跨平台流媒体解决方案(C++开源项目，是基于RTSP+RTP协议的，RTSP带外协议控制，而多媒体流RTP带内传输） 
总体框架：RTSP + RTP 
RTSP：控制多媒体流的传送, TCP协议 
RTP：多媒体流数据传输, UDP协议

live555基本概念： 
1、LiveMedia： 
一系列处理不同编码格式和封装格式的类，基类是Medium 
MediaSouce是所有Souce的基类，MediaSink是所有Sink的基类 
Souce：数据的提供者，文件数据\内存数据等。 
Sink： 数据的消费者 
Filter：数据流从Souce流到Sink的过程中可以设置Filter，用于过滤或做进一步加工。 
LiveMedia中数据都是从Souce，经一个或多个Filter，最终流向Sink。在服务器中数据流是从文件或设备流向网络，而在客户端数据流是从网络流向文件或屏幕。

2、UsageEnvironment： 
环境类，用于错误信息的输出，LIVE555中多数类中均包含此类对象指 
BasicUsageEnvironment：包含具体环境类和具体TaskScheduler类，用于以控制台方式输出错误信息，其内部有一个循环， 
循环读取队列中的消息并处理。整个基于BasicTaskScheduler的程序只有一个线程驱动 
3、GroupSock： 
各种socket操作的封装，用于收发数据。主要面向组播，但也可以进行单播的收发数据，仅支持UDP，不支持TCP 
4、MediaServer： 
该程序使用BasicUsageEnvironment库实现，服务器的ClientConnection处理DESCRIBE命令时会创建ClientSession对象（连接到服务器的客户端，服务器会为其创建一个ClientSession对象， 
保存该客户端的socket、ip地址等）

MediaSession 
管理一个包含音视频的媒体文件，使用文件名唯一标识, 一个MediaSession可以有多个MediaSubsession 
MediaSubSession 
管理MediaSession中的一个音频流或视频流, 在MediaSubsession中完成了Souce和Sink连接。Souce对象指针会被设置进sink，即应是sink跟source要数据。 
在Sink需要数据时，可以通过调用Souce的GetNextFrame来获得 
StreamState: 
定义MediaSession的状态类，管理每个媒体流的状态。

HashTable 
媒体文件名与MediaSession的映射，SessionID与ClientSession的映射

SDP: Session Description Protocol 
一个用来描述多媒体会话的应用层协议，它是基于文本的，用于会话建立过程中的媒体类型和编码方案的协商等。客户端会通过DESCRIBE命令请求查询指定文件的媒体信息

rtp传送过程的函数调用流程： 
RTSPClientSession类成员函数handleCmd_PLAY()处理客户端的播放请求，调用子会话的startStream()，内部调用MediaSink::startPlaying()函数

1、Boolean MediaSink::startPlaying(MediaSource& source, afterPlayingFunc* afterFunc, void* afterClientData) {}sink从source（该source会在MediaSubsession创立Souce和Sink连接时，以设置到sink中，此处为调用）取数据，afterPlayingFunc为回调函数//MultiFramedRTPSink是与帧有关的类，它要求每次须从source获得一个帧的数据:2、Boolean MultiFramedRTPSink::continuePlaying(){}3、void MultiFramedRTPSink::buildAndSendPacket(Boolean isFirstPacket){}4、void MultiFramedRTPSink::packFrame(){} 5、void MultiFramedRTPSink::afterGettingFrame(void* clientData, unsigned numBytesRead, unsigned numTruncatedBytes,  struct timeval presentationTime, unsigned durationInMicroseconds) {}6、void MultiFramedRTPSink::afterGettingFrame1(unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime,          unsigned durationInMicroseconds) {}7、void MultiFramedRTPSink::sendPacketIfNecessary(){}   // Delay this amount of time:     nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo,                  (TaskFunc*) sendNext, this); 
1
2
3
4
5
6
7
8
9
10
11
12
13
1
2
3
4
5
6
7
8
9
10
11
12
13

函数中的nextTask()（(TaskFunc*) sendNext）又调用了buildAndSendPacket()函数，从而实现rtp的循环打包发送过程

RTSP—Real Time Streaming Protocol实时流媒体协议属应用层协议，其协议在语法和操作上类似于HTTP/1.1 (写法上如：RTSP/1.0) 
RTSP协议一般传输的是ts, mp4格式的流，RTSP传输一般需要2-3个通道，命令和数据通道分离

RTSP报文： 
请求报文和响应报文两种,请求报文是指从客户向服务器发送请求报文，响应报文是指从服务器到 
RTSP报文由三部分组成，即开始行、首部行和实体主体

请求报文： 
方法 URI RTSP 版本CR LF 
消息头CR LF CR LF 
消息体CR LF

请求示例： 
OPTIONS rtsp://××× RTSP/1.0 
CSeq: 1 
User-Agent: ×××

响应报文： 
RTSP 版本状态码解释CR LF 
消息头CR LF CR LF 
消息体CR LF

响应示例： 
RTSP/1.0 200 OK 
CSeq: 1 
Date: 
Server: ××× 
Public: OPTIONS, DESCRIBE, ANNOUNCE, PLAY, PAUSE, SETUP, GET_PARAMETER, SET_PARAMETER, TEARDOWN 
TurboPlay: 1 
RealChallenge1: ××× 
StatsMask: 8

RTSP请求报文的方法：OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。 
方法 作用 
OPTIONS 获得服务器提供的可用方法 
DESCRIBE 得到会话描述信息 
SETUP 客户端提醒服务器建立会话，并确定传输模式 
TEARDOWN 客户端发起关闭请求 
PLAY 客户端发送播放请求

客户端建立会话：OPTIONS -> DESCRIBE（获取SDP） -> SETUP -> PLAY

RTP: 
RTP网络传输是基于UDP/IP协议，网络最大传输单元(MTU)最大为1500字节，在RTP/UDP/IP的协议层次结构中，RTP头12字节, UDP头8字节的, IP头至少20字节 
，头信息至少要占用40个字节，RTP载荷的最大尺寸为1460字节。 
H264为例: 
如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放

RTP协议头： 
内容 长度 
V： RTP协议的版本号 2bits，当前协议版本号为2 
P： 填充标志 1bit， P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。 
X： 扩展标志 1bit， X=1，则在RTP报头后跟有一个扩展报头 
CC：CSRC计数器 4bits，指示CSRC 标识符的个数 
M: 标记 1bit， 视频，标记一帧的结束；音频，标记会话的开始。

PT: 有效荷载类型 7bits， 
RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。

sequence number：序列号 16bits 
发送的RTP报文的序列号，每发送一个报文，序列号增1。用UDP协议，当网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，序列号的初始值是随机的，同时音频包和视频包的sequence是分别记数的。

timestamp：时间戳 32bits 
必须使用90 kHz 时钟频率。时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

SSRC：同步信源 32bits， 
标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

CSRC：特约信源，每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

RTP荷载H264码流: 
定义三个不同的基本荷载结构(根H264 NAL Header结构相同F NRI TYPE，只是type值有所不同)，接收者可以通过RTP荷载的第一个字节后5位识别荷载结构。 
1)单个NAL单元包：荷载中只包含一个NAL单元。 
NAL头类型域等于原始NAL单元类型,即在范围1到23之间 
2)聚合包：聚合多个NAL单元到单个RTP荷载中 
聚合类型 NAL type 
单时间聚合包类型A(STAP-A) 24 
单时间聚合包类型B(STAP-B) 25 
多时间聚合包类型16位位移(MTAP16) 26 
多时间聚合包类型24位位移(MTAP24) 27 
3)分片单元：分片单个NAL单元到多个RTP包 
分组类型 NAL type 
FU-A 28 
FU-B 29 
FU indicator: F NRI TYPE 
FU header: S E R TYPE

S: 1bit, 分片NAL单元的开始 
E: 1bit, 分片NAL单元的结束 
R: 1bit, 保留位必须设置为0

RTCP 
会采用与RTP相同的分发机制,实现流量控制和拥塞控制