LIVE555

live555简介

　　Live555 是一个为流媒体提供解决方案的跨平台的C++开源项目，它实现了对标准流媒体传输协议如RTP/RTCP、RTSP、SIP等的支持。Live555实现了对多种音视频编码格式的音视频数据的流化、接收和处理等支持，包括MPEG、H.263+、DV、JPEG视频和多种音频编码。同时由于良好的设计，Live555非常容易扩展对其他格式的支持。目前，Live555已经被用于多款播放器的流媒体播放功能的实现，如VLC(VideoLan)、MPlayer。                            

                                                                                                                                                                                                                                                                              

Live555 Streaming Media整体框架

 

　　UsageEnvironment模块是对系统环境的抽象，包括抽象类UsageEnvironment和TaskScheduler。UsageEnvironment主要用于消息的输入输出和用户交互功能；TaskScheduler实现事件的异步处理、事件处理函数的注册等，它通过维护一个异步读取源实现对诸如通信消息到达等事件的处理，通过使用DelayQueue实现对其他注册函数的延时调度。该模块还包含一个HashTable类，在整个项目中都可以用到它。程序设计者通过自定义该抽象了类UsageEnvironment和TaskScheduler类的子类，就可以在特定环境（如GUI环境）中运行，不需要进行过多的修改。
 

 　　BasicUsageEnvironment模块是UsageEnvironment的一个控制台应用的实现。它针对控制台的输入输出和信号响应进行具体实现。

　　GroupSock模块用于实现数据包的发送和接收。GroupSock主要被设计用以支持多播，但它也完全支持单播通信。 

　　LiveMedia模块是Live555最重要的模块。该模块声明了一个抽象类Medium，其他所有类都派生自该类，下面简要介绍这些类： 

　　Ø RTSPClient：该类实现RTSP请求的发送和响应的解析，同时根据解析的结果创建对应的RTP会话。 

　　Ø MediaSession：用于表示一个RTP会话，一个MediaSession可能包含多个子会话(MediaSubSession)，子会话可以是音频子会话、视频子会话等。 

　　Ø RTCPInstance：该类实现RTCP协议的通信。 

　　Ø Source和Sink：这两个概念类似DirectShow中的Filter。Source抽象了数据源，比如通过RTP读取数据。Sink是数据消费者的抽象，比如把接收到数据存储到文件，该文件就是一个Sink。数据的流动可能经过多个Source和Sink。MediaSink是各种类型的Sink的基类，MediaSource是各种类型Source的基类，各种类型的流媒体格式和编码的支持即是通过对这两个类的派生实现的。Source和Sink通过RTP子会话(MediaSubSession)联系在一起。

openRTSP客户端流程

　　1、创建TaskScheduler和BasicUsageEnvironment类；

　　2、命令行解析，获取流媒体地址和其他选项；

　　3、创建RTSPClient对象；

　　4、如果需要，RTSPClient对象发送OPTIONS命令并解析服务端响应，获取可以使用命令集。

　　5、RTSPClient对象发送DESCRIBE命令，并从获服务端反馈中获取流媒体相关描述SDP字串。

　　6、创建MediaSession对象，解析SDP字串，创建了相应的子会话对象。在这个过程中还完成了RTP和RTCP通信使用的GroupSock对象的创建，包括协议和端口的选择。

　　7、根据流媒体不同类型，实例化具体的RTP会话的Source和Sink对象。

　　8、RTSPClient对象发送SETUP和PLAY命令，服务端开始传输流媒体数据。

　　9、TaskScheduler开始事件处理循环，通过select监听数据包到达并调用注册函数进行处理。
 

=====================================================================

通过分析live库提供的例子程序OpenRTSP，可以清晰地了解客户端接收来自网络上媒体数据的过程。注 意，RTP协议和RTCP协议接收的数据分别是视音频数据和发送/接收状况的相关信息，其中，RTP协议只负责接收数据，而RTCP协议除了接收服务器的 消息之外，还要向服务器反馈。
A.        main函数流程
main(int argc,char *argv[])
{
1.            创建BasicTaskScheduler对象
2.            创建BisicUsageEnvironment对象
3.            分析argv参数，（最简单的用法是：openRTSP rtsp://172.16.24.240/mpeg4video.mp4）以便在下面设置一些相关参数
4.            创建RTSPClient对象
5.            由RTSPClient对象向服务器发送OPTION消息并接受回应
6.            产生SDPDescription字符串（由RTSPClient对象向服务器发送DESCRIBE消息并接受回应，根据回应的信息产生 SDPDescription字符串，其中包括视音频数据的协议和解码器类型）
7.            创建MediaSession对象（根据SDPDescription在MediaSession中创建和初始化MediaSubSession子会话对 象）
8.            while循环中配置所有子会话对象（为每个子会话创建RTPSource和RTCPInstance对象，并创建两个GroupSock对象，分别对应 RTPSource和RTCPInstance对象，把在每个GroupSock对象中创建的socket描述符置入 BasicTaskScheduler::fReadSet中，RTPSource对象的创建的依据是SDPDescription，例如对于MPEG4 文件来说，视音频RTPSource分别对应MPEG4ESVideoRTPSource和MPEG4GenericRTPSource对象。 RTCPInstance对象在构造函数中完成将Socket描述符、处理接收RTCP数据的函数 (RTCPInstance::incomingReportHandler)以及RTCPInstance本身三者绑定在一个 HandlerDescriptor对象中，并置入BasicTaskScheduler::fReadHandler中。完成绑定后会向服务器发送一条 消息。）
9.            由RTSPClient对象向服务器发送SETUP消息并接受回应。
10.        while循环中为每个子会话创建接收器(FileSink对象)，在FileSink对象中根据子会话的codec等属性缺省产生记录视音频数据的文件 名，视音频文件名分别为：video-MP4V-ES-1和audio-MPEG4-GENERIC-2，无后缀名
11.        while循环中为每个子会话的视音频数据装配相应的接收函数，将每个子会话中的RTPSource中的GroupSock对象中的SOCKET描述符， 置入BasicTaskScheduler::fReadSet中，并将描述符、处理接收RTP数据的函数 (MultiFramedRTPSource::networkReadHandler)以及RTPSource本身三者绑定在一个 HandlerDescriptor对象中，并置入BasicTaskScheduler::fReadHandler中,并将FileSink的缓冲区 和包含写入文件操作的一个函数指针配置给RTPSource对象，这个缓冲区将会在networkReadHandler中接收来自网络的视音频数据(分 析和去掉RTP包头的工作由RTPSource完成)，而这个函数指针在networkReadHandler中被调用以完成将缓冲区中的数据写入文件。
12.        由RTSPClient对象向服务器发送PLAY消息并接受回应。
13.        进入while循环，调用BasicTaskScheduler::SingleStep()函数接受数据，直到服务器发送TREADOWN消息给客户 端，客户端接收到该消息后释放资源，程序退出。

}

liveMedia项目的源代码包括四个基本的库，各种测试代码以及Media Server。四个基本的库分别是:

UsageEnvironment&TaskScheduler, groupsock, liveMedia和BasicUsageEnvironment。

1，基础类介绍：

BasicUsageEnvironment和UsageEnvironment中的类都是用于整个系统的基础功能类．用于事件的调度，实现异步读取事件的句柄的设置以及错误信息的输出。比如UsageEnvironment代表了整个系统运行的环境，它提供了错误记录和错误报告的功能，无论哪一个类要输出错误，就需要保存UsageEnvironment的指针．而TaskScheduler则提供了任务调度功能．整个程序的运行发动机就是它，它调度任务，执行任务（任务就是一个函数）．TaskScheduler由于在全局中只有一个，所以保存在了UsageEnvironment中．而所有的类又都保存了UsageEnvironment的指针，所以谁想把自己的任务加入调度中，那是很容易的．在此还看到一个结论：整个live555（服务端）只有一个线程．

类HashTable：实现了哈稀表．定义了一个通用的hash表，其它代码要用到这个表。

liveMedia库中有一系列类，基类是Medium，这些类针对不同的流媒体类型和编码。

基于liveMedia的程序，需要通过继承UsageEnvironment抽象类和TaskScheduler抽象类，定义相应的类来处理事件调度，数据读写以及错误处理。live项目的源代码里有这些类的一个基本实现，这就是“BasicUsageEnvironment”库。BasicUsageEnvironment主要是针对简单的控制台应用程序，利用select实现事件获取和处理。这个库利用Unix或者Windows的控制台作为输入输出，出于应用程序原形或者调试的目的，用户可以用这个库开发传统的运行与控制台的应用。

类DelayQueue：译为＂延迟队列＂，它是一个队列，每一项代表了一个要调度的任务（在它的fToken变量中保存）．同时保存了这个任务离执行时间点的剩余时间．可以预见，它就是在TaskScheduler中用于管理调度任务的东西．注意，此队列中的任务只被执行一次！执行完后这一项即被无情抛弃！

类HandlerSet：Handler集合．Handler是什么呢？它是一种专门用于执行socket操作的任务（函数），HandlerSet被TaskScheduler用来管理所有的socket任务（增删改查）．所以TaskScheduler中现在已调度两种任务了：socket任务（handlerSet）和延迟任务(DelayQueue)．其实TaskScheduler还调度第三种任务：Event，这个后面再说．

类Groupsock：这个是放在单独的库Groupsock中。它封装了socket操作，增加了多播支持和一对多单播的功能．但好像不支持TCP。它管理着一个本地socket和多个目的地址，因为是UDP，所以只需知道对方地址和端口即可发送数据。Groupsock的构造函数有一个参数是struct in_addr const& groupAddr，在构造函数中首先会调用父类构造函数创建socket对象，然后判断这个地址，若是多播地址，则加入多播组。Groupsock的两个成员变量destRecord* fDests和DirectedNetInterfaceSet fMembers都表示目的地址集和，但貌似这个变量DirectedNetInterfaceSet fMembers没有用到，且DirectedNetInterfaceSet是一个没有被继承的虚类，看起来fMembers没有什么用。仅fDesk也够用了，在addDestination()和removeDestination()函数中就是操作fDesk，添加或删除目的地址。

2，基本概念
    先来熟悉在liveMedia库中Source，Sink以及Filter等概念。Sink就是消费数据的对象，比如把接收到的数据存储到文件，这个文件就是一个Sink。Source就是生产数据的对象，比如通过RTP读取数据。数据流经过多个'source'和'sinks'，下面是一个示例：
          source1' -> 'source2' (a filter) -> 'source3' (a filter) -> 'sink'
    从其它Source接收数据的source也叫做"filters"。Module是一个sink或者一个filter。数据接收的终点是Sink类，MediaSink是所有Sink类的基类。Sink类实现对数据的处理是通过实现纯虚函数continuePlaying()，通常情况continuePlaying调用fSource -> getNextFrame来为Source设置数据缓冲区，处理数据的回调函数等，fSource是MediaSink的类型为FramedSource*的类成员。

3，计划任务(TaskScheduler)深入探讨

我们且把三种任务命名为：socket handler,event handler,delay task。

这三种任务的特点是，前两个加入执行队列后会一直存在，而delay task在执行完一次后会立即弃掉。

socket handler保存在队列BasicTaskScheduler0::HandlerSet* fHandlers中;

event handler保存在数组BasicTaskScheduler0::TaskFunc *

 fTriggeredEventHandlers[MAX_NUM_EVENT_TRIGGERS]中;

delay task保存在队列BasicTaskScheduler0::DelayQueue fDelayQueue中。

   下面看一下三种任务的执行函数的定义：
socket handler为
typedef void BackgroundHandlerProc(void* clientData, int mask);
event handler为
typedef void TaskFunc(void* clientData);
delay task 为
typedef void TaskFunc(void* clientData);//跟event handler一样。

    再看一下向任务调度对象添加三种任务的函数的样子：
socket handler为：
void setBackgroundHandling(int socketNum, int conditionSet　,BackgroundHandlerProc* handlerProc, void* clientData)
event handler为:
EventTriggerId createEventTrigger(TaskFunc* eventHandlerProc)
delay task为：
TaskToken scheduleDelayedTask(int64_t microseconds, TaskFunc* proc,void* clientData)

socket handler添加时为什么需要那些参数呢？socketNum是需要的，因为要select socket（socketNum即是socket()返回的那个socket对象）。conditionSet也是需要的，它用于表明socket在select时查看哪种装态，是可读？可写？还是出错？再看BackgroundHandlerProc的参数，socketNum不必解释，mask是什么呢？它正是对应着conditionSet，但它表明的是select之后的结果，比如一个socket可能需要检查其读/写状态，而当前只能读，不能写，那么mask中就只有表明读的位被设置。

event handler是被存在数组中。数组大小固定，是32项，用EventTriggerId来表示数组中的项，EventTriggerId是一个32位整数，因为数组是32项，所以用EventTriggerId中的第n位置１表明对应数组中的第n项。成员变量fTriggersAwaitingHandling也是EventTriggerId类型，它里面置1的那些位对应了数组中所有需要处理的项。这样做节省了内存和计算，但降低了可读性，而且也不够灵活，只能支持32项或64项，其它数量不被支持。

http://www.live555.com/