??前段時(shí)間著手實(shí)現(xiàn)了一個(gè)RTSP Server，能夠正常實(shí)現(xiàn)多路RTSP流的直播播放，因項(xiàng)目需要，只做了對(duì)H.264和AAC編碼的支持，但是相信其他編碼的實(shí)現(xiàn)基本邏輯也是想通的。這里我把主要設(shè)計(jì)和思考過程，以及實(shí)現(xiàn)框架分享一下。因?yàn)殛P(guān)注的是直播，這里只討論RTSP直播協(xié)議。

RTSP協(xié)議概述與RTSP2.0

??眾所周知，RTSP協(xié)議是一個(gè)流媒體協(xié)議，可以實(shí)現(xiàn)直播和點(diǎn)播形式的音頻與視頻流的播放。RTSP協(xié)議定義了多種服務(wù)器-客戶端之間交互的接口，主要有OPTIONS，DESCRIBE，SETUP，PLAY，TEARDOWN，RECORD，ANNOUNCE。網(wǎng)絡(luò)上已經(jīng)有很多針對(duì)RTSP協(xié)議的文章，我這里不準(zhǔn)備進(jìn)行過多介紹，詳細(xì)的協(xié)議定義，可以參見RFC2326。RTSP并不包括具體數(shù)據(jù)的傳輸，該功能一般由RTP與RTCP協(xié)議來實(shí)現(xiàn)，并可以通過TCP或UDP兩種底層傳輸方式進(jìn)行。

??下圖是典型的RTSP直播過程中服務(wù)端-客戶端主要交互過程：

??當(dāng)然，直播過程中也可能在服務(wù)器與客戶端之間調(diào)用GET_PARAMETER等其他接口，上圖偷懶省略了。上圖綠色部分表示的是數(shù)據(jù)傳輸。之前說過，流媒體數(shù)據(jù)傳輸不是RTSP協(xié)議的內(nèi)容，由RTP包來做。但是具體在實(shí)現(xiàn)上，RTP包可以通過UDP或TCP的方式來進(jìn)行，而且這兩種傳輸方式，區(qū)別其實(shí)還不小，下面具體說下。

RTSP 數(shù)據(jù)傳輸流程

1. RTSP over UDP

??對(duì)于udp模式，客戶端在發(fā)送PLAY以后，就開始建立udp端口，以接收服務(wù)器發(fā)來的RTP包，同樣，服務(wù)器也會(huì)建立udp端口，并向客戶端發(fā)送RTP包。這是網(wǎng)上大部分程序所采用的方式，優(yōu)點(diǎn)是邏輯清晰，實(shí)現(xiàn)方便，不過缺點(diǎn)也很明顯，就是udp所固有的，容易丟包，尤其是在高分辨率高碼率下。

??

2. RTSP over TCP

??對(duì)tcp模式，通過SETUP接口來指定傳輸方式，服務(wù)器返回同樣數(shù)據(jù)以確定雙方通過tcp方式來傳輸數(shù)據(jù)。不過跟udp最大的不同是，rtsp over tcp的形式，不再創(chuàng)建單獨(dú)的tcp通道，而是直接使用之前rtsp通信所使用的tcp通道，流程如下所示：

??

??由于跟rtsp消息使用同一個(gè)tcp端口，為了區(qū)分，rtp以及rtcp包，增加了4個(gè)字節(jié)額外的字段，并通過特殊的標(biāo)識(shí)'$'，與正常的rtsp消息進(jìn)行了區(qū)分。

RTSP Live Server 設(shè)計(jì)與實(shí)現(xiàn)

1. 程序框架

??我這次所實(shí)現(xiàn)的RTSP Server，主要功能是采集攝像頭和麥克風(fēng)數(shù)據(jù)，進(jìn)行h.264編碼以及aac編碼，并對(duì)外提供RTSP直播流服務(wù)。我在實(shí)際寫代碼中，也是首先實(shí)現(xiàn)了rtsp over udp的模式，然而，通過實(shí)際測(cè)試，我發(fā)現(xiàn)在高分辨率高碼率情況下，由于h.264 NAL單元過大，會(huì)拆分成很多的rtp包，而udp不可靠的傳輸方式，總是難免丟包，在低碼率的時(shí)候還不明顯，高碼率情況下，丟包導(dǎo)致的花屏?xí)l繁出現(xiàn)，這樣體驗(yàn)特別差。于是我重新實(shí)現(xiàn)了一份rtsp over tcp模式的代碼，順利解決了這個(gè)問題。

??

2. 關(guān)于h264在sdp中的描述

??h264在sdp中的媒體信息,大多都是可以直接填寫的，但是有兩項(xiàng)數(shù)據(jù)需要根據(jù)編碼后的數(shù)據(jù)來提取，就是profile-level-id和sprop-parameter-sets。這兩項(xiàng)字符串?dāng)?shù)據(jù)的計(jì)算公式

• profile-level-id = "Base16(sps[1])" "Base16(sps[2])" "Base16(sps[3])"

• sprop-parameter-sets = "Base64(sps)" "," "Base64(pps)"

3. 主要代碼

3.1 Rtsp服務(wù)接口

3.2 RtspSession在TCP通道里處理RTSP消息與RTP報(bào)文

4. 運(yùn)行效果

??同時(shí)用vlc和ffplay進(jìn)行多路播放，以tcp請(qǐng)求的方式，效果如下，延遲極低。

關(guān)于RTSP 2.0

??2016年IETF發(fā)布了新的RTSP標(biāo)準(zhǔn)，這就是就是RTSP2.0協(xié)議（RFC7826），新標(biāo)準(zhǔn)還是有不少修改的，除了完善一些原協(xié)議的中的定義，還有一些我覺得比較重要的是，對(duì)接口method進(jìn)行了修改，比如刪除了RECORD和ANNOUNCE方法，新增了PLAY_NOTIFY方法。

• 刪除了RECORD，這表示你不能再通過這個(gè)接口來控制服務(wù)器進(jìn)行數(shù)據(jù)的錄制了，可以選擇在PLAY方法中，添加一些參數(shù)，來實(shí)現(xiàn)服務(wù)器對(duì)直播數(shù)據(jù)進(jìn)行錄制，還可以分隔錄制。

• 刪除了ANNOUNCE，這意味著，不能像RTMP一樣，客戶端通過向服務(wù)器推送數(shù)據(jù)，來實(shí)現(xiàn)本機(jī)數(shù)據(jù)對(duì)外直播了，這可能需要其他的推送途徑來進(jìn)行替代了。

• 至于PLAY_NOTIFY，它替代來原來Server向Client端發(fā)送ANNOUNCE方法，所實(shí)現(xiàn)的功能，也就是告訴客戶端，需要根據(jù)新參數(shù)來調(diào)整直播播放狀態(tài)。

• 刪除通過UDP傳輸RTSP消息的形式

• 刪除通過發(fā)PLAY消息來keep alive的方式（用SET_PARAMETER來做）

• RTSP Server也可向Client發(fā)TEARDOWN消息

• 支持IPV6

• RTSP請(qǐng)求，支持pipelining的形式，也就是聚合Request。比如可以不等服務(wù)器返回，把SETUP和PLAY一起發(fā)送，這樣可以提高至少一個(gè)RTT的啟動(dòng)時(shí)間。當(dāng)然需要在消息里加上相關(guān)字段。

• 重寫了狀態(tài)機(jī)，完善了服務(wù)器對(duì)客戶端來說在各個(gè)狀態(tài)之間的轉(zhuǎn)換和行為

• RTSP消息內(nèi)支持URI了

• 擴(kuò)展了REDIRECT方法，等，等等。

haibindev.cnblogs.com，合作請(qǐng)聯(lián)系QQ。（轉(zhuǎn)載請(qǐng)注明作者和出處~）

基于Live555實(shí)現(xiàn)RtspServer及高清高碼率視頻傳輸優(yōu)化

最近做了一些pc和嵌入式平臺(tái)的RTSP服務(wù)器項(xiàng)目，大多數(shù)的要求是簡(jiǎn)單但是功能全面，并且性能還要強(qiáng)勁。綜合考慮后，基本都是在基于live555的基礎(chǔ)上進(jìn)行開發(fā)，在進(jìn)行Live555本身的優(yōu)化以及程序內(nèi)部視頻數(shù)據(jù)傳輸?shù)膬?yōu)化后，不僅實(shí)現(xiàn)了需求而且性能還超出預(yù)期，實(shí)現(xiàn)了10Mbps高碼率的1080p以上高分辨率高清視頻的流暢直播。這里將一些優(yōu)化點(diǎn)分享一下：

為什么基于Live555開發(fā)

其實(shí)之前我就已經(jīng)開發(fā)過一個(gè)RTSP Server程序，并且寫了一篇文章進(jìn)行了介紹“一個(gè)RtspServer的設(shè)計(jì)與實(shí)現(xiàn)和RTSP2.0簡(jiǎn)介”,不過當(dāng)時(shí)開發(fā)的目的除了實(shí)現(xiàn)RTSP直播以外，主要目的還是簡(jiǎn)化代碼以方便定制，因此并沒有完全實(shí)現(xiàn)RTSP協(xié)議里的所有交互細(xì)節(jié)，要在它的基礎(chǔ)上擴(kuò)展全面，可能會(huì)拖延項(xiàng)目進(jìn)展。基于項(xiàng)目考慮，選擇了自己比較了解也認(rèn)為比較優(yōu)秀的RTSP開源項(xiàng)目Live555作為基礎(chǔ)，開發(fā)RTSP Server程序。

Live555是一個(gè)跨平臺(tái)的流媒體解決方案，以C 為開發(fā)語言，實(shí)現(xiàn)了RTSP包括服務(wù)器-客戶端的整套結(jié)構(gòu)，并且支持H.264, H.265, MPEG, AAC等多種視頻和音頻編碼，是很知名的一個(gè)開源項(xiàng)目。作為RTSP Server，源碼里只有對(duì)于本地文件的視頻源，不過它的擴(kuò)展性強(qiáng)，可以在Live555提供的一些基類基礎(chǔ)上開發(fā)出適合自己項(xiàng)目需求的服務(wù)程序。

Live555架構(gòu)和RTSP數(shù)據(jù)流程

Live555的核心模塊

RTSP服務(wù)器和客戶端的交互流程

Live555流媒體模塊及服務(wù)端的處理流程

Live555的流媒體模塊基本分為Source和Sink兩大部分，當(dāng)然他們也有一個(gè)共同的基類Medium。對(duì)服務(wù)器來說，Source為數(shù)據(jù)來源，Sink為數(shù)據(jù)輸出，視頻數(shù)據(jù)就通過MediaSource傳遞給MediaSink，最終通過RTPInterface網(wǎng)絡(luò)傳輸給客戶端。一下為服務(wù)端所用到的模塊以及繼承關(guān)系:

如同上圖所示意的，通過完成自己的ServerMediaSubsession和MediaSource來實(shí)現(xiàn)將需要直播的H.264編碼數(shù)據(jù)傳遞給live555，以實(shí)現(xiàn)RTSP直播。

高碼率視頻數(shù)據(jù)傳輸?shù)膬?yōu)化點(diǎn)

對(duì)高清高碼率的視頻畫面，每一幀的視頻數(shù)據(jù)就會(huì)比較大，這個(gè)數(shù)值往往會(huì)超出live555內(nèi)部默認(rèn)的內(nèi)存處理大小，因?yàn)閷?duì)于live555的優(yōu)化，主要就是集中在內(nèi)存緩沖大小的擴(kuò)大，以及避免內(nèi)存數(shù)據(jù)拷貝。以下為根據(jù)實(shí)際開發(fā)和測(cè)試所總結(jié)出來的有效的優(yōu)化點(diǎn)：

1. 擴(kuò)展幀解析buffer大小，即BANK_SIZE，默認(rèn)值為150k，根據(jù)傳輸?shù)腍264數(shù)據(jù)幀大小，至少設(shè)置為300k。否則超出大小，可能會(huì)被Live555拋棄。

2. 增加OutPacketBuffer::maxSize大小，同樣為了容納超大幀數(shù)據(jù)，否則可能會(huì)導(dǎo)致數(shù)據(jù)丟失。

3. 在RTPInterface中，增加socket發(fā)送緩沖區(qū)大小，即increaseSendBufferTo函數(shù)的參數(shù)值

4. 對(duì)MultiFramedRTPSink::sendPacketIfNecessary中，可以直接調(diào)用sendNext嘗試組建RTP報(bào)文發(fā)送數(shù)據(jù)包，這樣修改的優(yōu)點(diǎn)是已讀取的數(shù)據(jù)會(huì)被盡快發(fā)送出去，不過也多占用一些線程時(shí)間。

5. 對(duì)于應(yīng)用程序?qū)?shù)據(jù)從自己的線程傳遞給Live555的時(shí)候，應(yīng)該盡量減少內(nèi)存拷貝，最好是通過內(nèi)存池的形式，以避免拷貝內(nèi)存阻塞Live555事件循環(huán)

經(jīng)過以上修改，以及應(yīng)用程序內(nèi)部代碼的優(yōu)化，在實(shí)際應(yīng)用中，已經(jīng)實(shí)現(xiàn)了10Mbps高碼率的1080p以上高分辨率高清視頻的流暢直播。