live555 rtsp rtp学习笔记

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); 

函数中的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相同的分发机制,实现流量控制和拥塞控制