作者:咕唧咕唧liukun321
来自:http://blog.csdn.net/liukun321
上一篇文章简要介绍了如何以共享库的方式交叉编译Live555,今天再来介绍live源码框架。先对live555有一个宏观的认识,为今后的实战打个基础。
liveMedia项目的源代码包括四个基本的库,各种测试代码以及IVE555 Media Server。四个基本的库分别是UsageEnvironment&TaskScheduler,groupsock,liveMedia,BasicUsageEnvironment。
这几个类都是整个系统的基础功能类,这些都是抽象类,在应用程序中基于这些类实现自己的子类。
UsageEnvironment:代表了整个系统运行的环境,它提供了错误记录、报告和log输出的功能,无论哪一个类要输出错误,就需要保存UsageEnvironment的指针(例如:可以通过
UsageEnvironment* env; UsageEnvironment* env =BasicUsageEnvironment::createNew(*scheduler); *env << "Play this stream usingthe URL \"
这种操作可以实现log的输出。
TaskScheduler:则提供了任务调度功能.整个程序的运行发动机就是它,它调度任务,执行任务(任务就是一个函数).TaskScheduler由于在全局中只有一个,所以保存在了UsageEnvironment中.而所有的类又都保存了UsageEnvironment的指针,所以谁想把自己的任务加入调度中,那是很容易的.
在此还看到一个结论:整个live555(服务端)只有一个线程.当然现在有网友已经实现了服务端的多线程.
Groupsock:类是对网络接口的封装,用于收发数据包。这个是放在单独的库Groupsock中。它封装了socket操作,增加了多播放支持和一对多单播的功能.同时支持UDP和TCP协议传输,两种方式可供选择。它管理着一个本地socket和多个目的地址,只需知道对方地址和端口即可发送数据。Groupsock的构造函数有一个参数是struct in_addr const& groupAddr,在构造函数中首先会调用父类构造函数创建socket对象,然后判断这个地址,若是多播地址,则加入多播组。Groupsock的两个成员变量destRecord* fDests和DirectedNetInterfaceSet fMembers都表示目的地址集和,但我始终看不出DirectedNetInterfaceSet fMembers有什么用,且DirectedNetInterfaceSet是一个没有被继承的虚类,看起来fMembers没有什么用。仅fDesk也够用了,在addDestination()和removeDestination()函数中就是操作fDesk,添加或删除目的地址。
BasicUsageEnvironment:主要是针对简单的控制台应用程序,利用select实现事件获取和处理。
HashTable:实现了哈稀表.
DelayQueue:译为"延迟队列",它是一个队列,每一项代表了一个要调度的任务(在它的fToken变量中保存).同时保存了这个任务离执行时间点的剩余时间.可以预见,它就是在TaskScheduler中用于管理调度任务的东西.注意,此队列中的任务只被执行一次!执行完后这一项即被抛弃!
HandlerSet:Handler集合.Handler是什么呢?它是一种专门用于执行socket操作的任务(函数),HandlerSet被TaskScheduler用来管理所有的socket任务(增删改查).所以TaskScheduler中现在已调度两种任务了:socket任务(handlerSet)和延迟任务(DelayQueue).其实TaskScheduler还调度第三种任务:Event,后面再说.
以上各关系见如下UML图:
liveMedia: 库中有一系列类,基类是Medium,这些类针对不同的流媒体类型和编码。
这里还要再说明一下Sink source,这两者的概念及关系:
liveMedia库中Sink就是消费数据的对象,比如把接收到的数据存储到文件,这个文件就是一个Sink。
Source就是生产数据的对象,比如通过 RTP读取数据。数据流经过多个source和sinks。
继承Medium基类的类,及他们间的关系见如下UML图:
到此,我们已经对Live555基类和框架有了一个初步的认识。这对我们今后将live555灵活运用到实际项目中起了至关重要的作用。
后面会用几篇博文,通过讲解实例代码的方式,直观阐述live555在嵌入式系统中视频转播、直播中的应用。