Live555基础

1 Live555组成

LIVE555下包含LiveMedia、UsageEnvironment、BasicUsageEnvironment、GroupSock库，MediaServer简单服务器程序以及其余多个测试demo。

LiveMedia库：包含一系列处理不一样编码格式和封装格式的类。

    基类是Medium。

UsageEnvironment库：环境类，用于错误信息的输出。

    LIVE555中多数类中均包含此类对象指针。

    其内部包含TaskSchedule抽象类的指针，该类用于任务调度，所以全部包含UsageEnvironment指针的类都可将本身加入到调度中。

BasicUsageEnvironment库：包含具体环境类和具体TaskScheduler类。

    UsageEnvironment用于对错误信息的处理，BasicUsageEnvironment类用于以控制台方式输出错误信息。所以想要以其余方式输出错误信息的类，能够从UsageEnvironment派生。

    BasicTaskSchedule类继承自TaskScheduler抽象类，用以定义具体的调度策略。

    任何基于LIVE555的应用程序均须要定义本身的BasicEnvironment和TaskScheduler库。

    若是建立窗口应用程序，在重定义TaskScheduler时，须要与图形环境本身的事件处理框架集成。

    BasicTaskSheduler使用select模型实现事件的获取和处理。若是想使用更高效的IOCP模型，能够定义本身的BasicTaskScheduler类。BasicTaskScheduler内部有一个循环，循环读取队列中的消息并处理。整个基于BasicTaskScheduler的程序只有一个线程驱动。

GroupSock库：对各类socket操做的封装

     用于收发数据，主要面向组播，但也能够进行单播的收发数据，仅支持UDP，不支持TCP。

MediaServer 服务器程序：

     该程序使用BasicUsageEnvironment库实现，所以是一个控制台程序。任务调度类是BasicTaskScheduler类，所以使用Select模型且仅有一个线程在循环处理各类事件。后期若是有时间会实现基于IOCP的MediaServer服务器程序。

其余测试Demo：

       基于LIVE555实现的客户端程序，会在须要的时候介绍。

2 基本概念

2.1 Source、Sink、Filter

Source：表示数据的提供者。好比经过RTP读取数据，经过文件读取数据或者从内存读取数据，这些都可以做为Souce。

Sink：表示数据的流向、消费者。好比写文件、显示到屏幕等。

Filter：在数据流从Souce流到Sink的过程当中能够设置Filter，用于过滤或作进一步加工。

在整个LiveMedia中，数据都是从Souce，通过一个或多个Filter，最终流向Sink。

     在服务器中数据流是从文件或设备流向网络。

     在客户端数据流是从网络流向文件或屏幕。

MediaSouce是全部Souce的基类，MediaSink是全部Sink的基类。

从类数量和代码规模能够看到，LiveMedia类是整个LIVE555的核心，其内部包含数十个操做具体编码和封装格式的类。LiveMedia定义的各类Souce均是从文件读取，若是想实现从设备得到实时流的传输，能够定义本身的Souce。

2.2 ClientSession

对于每个链接到服务器的客户端，服务器会为其建立一个ClientSession对象，保存该客户端的socket、ip地址等。

同时在该客户端中定义了各类响应函数用以处理和回应客户端的各类请求。

新版（2014.7.4）的LIVE555增长了ClientConnection类。用于处理一些与正常播放无关的命令。如命令未找到、命令不支持或媒体文件未找到等。在ClientConnection处理DESCRIBE命令时会建立ClientSession对象，其余命令在ClientSession中处理。

2.3 MediaSession、MediaSubsession、Track

    LIVE555使用MediaSession管理一个包含音视频的媒体文件，每一个MediaSession使用文件名惟一标识。

    使用SubSession管理MediaSession中的一个音频流或视频流。为行文方便咱们称音频或视频均为一个媒体文件中的媒体流。所以一个MediaSession能够有多个MediaSubsession，一个管理音频流一个管理视频流。

    在上一篇介绍RTSP协议时，客户端在给服务器发送DESCRIBE查询某个文件的SDP信息时，服务器会给客户端返回该媒体文件所包含的多个媒体流信息。并为每一个媒体流分配一个TrackID。如视频流分配为Track1，音频流分配为Track2。此后客户端必须在URL指定要为那个Track发送SETUP命令。所以咱们能够认为MediaSubsession表明Server端媒体文件的一个Track，也即对应一个媒体流。MediaSession表明Server端一个媒体文件。对于既包含音频又包含视频的媒体文件，MediaSession内包含两个MediaSubsession。

    但MediaSession和MediaSubsession仅表明静态信息。若多个客户端请求同一个文件，服务器仅会建立一个MediaSession。各个客户端公用。为了区分各个MediaSession的状态又定义了StreamState类，用来管理每一个媒体流的状态。在MediaSubsession中完成了Souce和Sink链接。Souce对指针象会被设置进sink。在Sink须要数据时，能够经过调用Souce的GetNextFrame来得到。

    LIVE555中大量使用简单工厂模式，每一个子类均有一个CreateNew静态成员。该子类的构造函数被设置为Protected，所以在外部不能直接经过new来构造。同时，每一个类的构造函数的参数中均有一个指向UsageEnvironment的指针，从而能够输出错误信息 和 将本身加入调度。

2.4 HashTable

LIVE555内部实现了一个简单哈希表类BasicHashTable。在LIVE555中，有不少地方须要用到该哈希表类。如：媒体文件名与MediaSession的映射，SessionID与ClientSession的映射，UserName和Password的映射等。

2.5 SDP

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

2.6 LIVE555中的关键继承层次（以对H.264码流的处理为例）

                          Source                                                                      Sink                                                                              SubSession

H264VideoStreamFramer是真正的Source，它用于从H.264文件中读取数据，而且组装成帧。在Sink调用GetNextFrame时将帧数据返回给Sink。

H264VideoRTPSink是真正的Sink，用于完成帧数据的发送。

SubSession用于完成Source和Sink的链接，同时用于管理每一个媒体流。

对于H264码流，数据流的流动方向为：

    服务器端：H264VideoStreamFramer ->H264Or5Fragmenter (Filter)r->H264VideoRTPSink

    客户端    ：H264RTPSouce ->Sink（不一样客户端实现不一样）

学习方法的注意：LIVE555类之间关系非常复杂，类之间犬牙交错的关系增大了学习LIVE555的难度，深刻学习以前应先熟悉基本流程，对各种的大概功能有所了解，至于细节问题可暂时略过。