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的難度，深刻學習以前應先熟悉基本流程，對各種的大概功能有所瞭解，至於細節問題可暫時略過。