LIVE555研究之三:LIVE555基础

LIVE555基础

LIVE555是为流媒体提供解决方式的跨平台C++开源项目。从今天起我们将正式開始深入LIVE555代码。

一、各库简要介绍

LIVE555下包括LiveMedia、UsageEnvironment、BasicUsageEnvironment、GroupSock库,MediaServer简单server程序以及其它多个測试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 server程序:该程序使用BasicUsageEnvironment库实现,因此是一个控制台程序。

任务调度类是BasicTaskScheduler类,因此使用Select模型且仅有一个线程在循环处理各种事件。

后期假设有时间会实现基于IOCP的MediaServerserver程序。

    其它測试Demo:基于LIVE555实现的client程序,会在须要的时候介绍。

二、涉及到的基本概念

1.  Souce、Sink

Souce :翻译为源、源头。表示数据的提供者,比方通过RTP读取数据,通过文件读取数据或者从内存读取数据,这些均能够作为Souce。

Sink:翻译为水槽。表示数据的流向、消费者。

比方写文件、显示到屏幕等。

Filter:翻译为过滤器。

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

在整个LiveMedia中,数据都是从Souce,经过一个或多个Filter。终于流向Sink。在server中数据流是从文件或设备流向网络,而在client数据流是从网络流向文件或屏幕。

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

从类数量和代码规模能够看到。LiveMedia类是整个LIVE555的核心,其内部包括数十个操作详细编码和封装格式的类。LiveMedia定义的各种Souce均是从文件读取,假设想实现从设备获得实时流的传输,能够定义自己的Souce。

2.  ClientSession

对于每一个连接到server的client。server会为其创建一个ClientSession对象,保存该client的socket、ip地址等。

同一时候在该client中定义了各种响应函数用以处理和回应client的各种请求。

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

3.  MediaSession、MediaSubsession、Track

LIVE555使用MediaSession管理一个包括音视频的媒体文件。每一个MediaSession使用文件名称唯一标识。

使用SubSession管理MediaSession中的一个音频流或视频流。

为行文方便我们称音频或视频均为一个媒体文件里的媒体流。

因此一个MediaSession能够有多个MediaSubsession。一个管理音频流一个管理视频流。

在上一篇介绍RTSP协议时。client在给server发送DESCRIBE查询某个文件的SDP信息时,server会给client返回该媒体文件所包括的多个媒体流信息。

并为每一个媒体流分配一个TrackID。

如视频流分配为Track1,音频流分配为Track2。

此后client必须在URL指定要为那个Track发送SETUP命令。

因此我们能够觉得MediaSubsession代表Server端媒体文件的一个Track,也即相应一个媒体流。

MediaSession代表Server端一个媒体文件。

对于既包括音频又包括视频的媒体文件,MediaSession内包括两个MediaSubsession。

但MediaSession和MediaSubsession仅代表静态信息。若多个client请求同一个文件,server仅会创建一个MediaSession。各个client公用。为了区分各个MediaSession的状态又定义了StreamState类,用来管理每一个媒体流的状态。在MediaSubsession中完毕了Souce和Sink连接。Souce对指针象会被设置进sink。在Sink须要数据时,能够通过调用Souce的GetNextFrame来获得。

LIVE555中大量使用简单工厂模式,每一个子类均有一个CreateNew静态成员。该子类的构造函数被设置为Protected,因此在外部不能直接通过new来构造。同一时候。每一个类的构造函数的參数中均有一个指向UsageEnvironment的指针,从而能够输出错误信息和将自己增加调度。

4. HashTable

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

5. SDP

SDP是Session Description Protocol的缩写。是一个用来描写叙述多媒体会话的应用层协议。它是基于文本的,用于会话建立过程中的媒体类型和编码方案的协商等。

client会通过DESCRIBE命令请求查询指定文件的媒体信息。有不明确的能够看下上一篇介绍RTSP、RTP、RTCP的文章。

6.  LIVE555中的关键类继承层次(均以对H264码流的处理为例)

大家能够先混个脸熟。以后会详细介绍。

Souce

LIVE555研究之三:LIVE555基础

H264VideoStreamFramer是真正的Souce,它用于从h264文件里读取数据,并组装成帧。在Sink调用GetNextFrame时将帧数据返回给Sink。

Sink

LIVE555研究之三:LIVE555基础

H264VideoRTPSink是真正的Sink,用于完毕帧数据的发送。

SubSession

LIVE555研究之三:LIVE555基础

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvaXRoemhhbmc=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" />

SubSession用于完毕Souce和Sink的连接,同一时候用于管理每一个媒体流。

对于H264码流。数据流的流动方向为:

server端:H264VideoStreamFramer ->H264Or5Fragmenter (Filter)r->H264VideoRTPSink

client:H264RTPSouce ->Sink(不同client实现不同)

LIVE555类之间关系非常是复杂。类之间犬牙交错的关系增大了学习LIVE555的难度,深入学习之前应先熟悉基本流程,对各类的大概功能有所了解,至于细节问题可临时略过。

对于LIVE555的代码风格,本人不是非常喜欢:一是成员变量命名方式。二是花括号({)紧跟在上一行的末尾。没有上下对齐层次清晰。

三是多句代码位于同一行,多见于if语句。当然这不过是个人喜好。欢迎大家表达自己的见解。

文章的最后。让我们来探讨下LIVE555应该怎样发音的问题。听过不少人都读成: [liv](力V555)。个人感觉不正确。由于live作为动词讲时。确实是读成:力V,但此时是居住、生存、经历的意思。作为形容词讲时是活的、直播、生动的。此时应读成:赖V。作为一个为流媒体提供解决方式的开源C++项目,应该离直播更近一些吧!

个人觉得应该读成赖V555。更洋气的读法:赖V Triple Five!

这都是个人想当然的读法。没有听过老外怎样读。欢迎拍砖!

下节我们将从server程序入手。開始介绍LIVE555源代码。

2014.8.16于浙江杭州

上一篇:struct 类型指针技巧


下一篇:【转载】Manacher算法