live555原始碼分析 live555大致流程

今天大致分析了下live555的流程，以h264為例子進行的分析.

從連線到傳送rtp/rtcp資料報。

首先分析呢，不能太關注細節，先整體再區域性。

在分析的過程中，設計到live555自己封裝的乙個高階類：比如迭代器，雜湊表，而且這2個類在live555中運用的範圍還非常的廣，但是無不例外都是用鍊錶進行實現的。

後面我們會專門花時間來分析live555是如何實現迭代器和雜湊表的.

接著二的分析，這個時候客戶端會傳送options,descriptur,setup等命令過來，還會傳送，快進，暫停，停止等資訊過來，完成後，伺服器就開始傳送rtp/rtcp資料報.

闡述下rtp包和rtcp包得關係.

rtp/rtcp資料報的傳輸是基於udp，這是一種無連線的傳輸方式，也就是說伺服器無法判斷出客戶端和伺服器是否依然還在保持聯絡中，rtcp包就是專門解決這個問題的. rtcp包含了雙邊傳送rtp資料報的資訊，包括傳送了多少資料報等資訊。

那麼客戶端和伺服器就可以通過對rtcp包得分析來統計傳輸過程中丟了多少包，還有如果超過一定時間沒有接收到rtcp資料報，那麼客戶端和伺服器就會終止雙邊的連線。

說了這麼多，分析下live555處理的業務流程.

客戶端傳送descripture命令過來後，伺服器會建立乙個servermediasession,seervermediasession本身會放到一張雜湊表中，這張雜湊表的作用其實就是繫結字尾名和具體的mediasession.

比如:rtsp: ，所有的264檔案都有乙個servermediasession對應，同理，所有的aac,***....對會有乙個對應的servermediasession.

servermediasession自己也是乙個鍊錶(單向還是雙向沒分析),裡面的元素為servermediasubsession。

servermediasubsession的子類很多，比如：h264filemediasubsession,aacfilemediasubsession,光看這些個類的命名，大家也基本猜測出這部分的設計思路.

比如使用者同時訪問：

rtsp:

rtsp:"554/tv2.264

那麼live555，就會分配乙個servermediasession，然後再servermediasession中包含2個h264filemediasubsession,這2個h264filemediasubsession乙個對應tv.264,另乙個對應tv2.264.

h264filemediasubsession的功能猜測應該是解析檔案，並從中提取h264 nalu單元，並封裝為rtp包.(這個類的設計也很複雜，主要是細節多.)

descriptur完成後，客戶端就知道了伺服器傳遞過來的資料的很多資訊呢，比如sps，pps，這個時候客戶端會進行解碼器的初始化等操作。

然後完成相關操作後，便會傳送setup，告訴伺服器rtp/rtcp的傳遞埠，讓伺服器知道資料報具體傳到哪個埠.

然後客戶端傳送play，伺服器邊開始傳送資料報:

fstreamstates[i].subsession->startstream(foursessionid,

fstreamstates[i].streamtoken,

(taskfunc*)noteclientliveness, this,

rtpseqnum, rtptimestamp,

handlealternativerequestbyte, this);

const char *urlsuffix = fstreamstates[i].subsession->trackid();

if (!farecurrentlyplaying && fmediasource != null) else if (fudpsink != null)

}因為裡面的設計的類過多，擷取一下一些比較重要的**.

簡單說就是接收到play命令後，就開始傳送rtp資料報和定時接受/傳送rtcp資料報了