iOS流媒体直播整个框架介绍(HLS、RTSP)
iOS流媒體直播整個(gè)框架介紹(HLS、RTSP)
目錄技術(shù)文章2016年7月17日一、HTTP（WebService）
基于HTTP的漸進(jìn)下載Progressive Download流媒體播放僅是在完全下載后再播放模式基礎(chǔ)上做了一些小的改進(jìn)。與下載播放模式中必須等待整個(gè)文件下載完畢后才能開始播放不同，漸進(jìn)下載客戶端在開始播放之前僅需等待一段較短的時(shí)間用于下載和緩沖該媒體文件最前面的一部分?jǐn)?shù)據(jù)，之后便可以一邊下載一邊播放。在正式開始播放之前的這一小段緩沖應(yīng)使得后續(xù)即使在網(wǎng)絡(luò)較為擁塞的情況下媒體數(shù)據(jù)也能夠得以不間斷地連續(xù)播放，通常需要幾十秒甚至上百秒的時(shí)間。在這種模式下，客戶端以自己以及Web服務(wù)器和網(wǎng)絡(luò)所能允許的最大速度盡可能快地從服務(wù)器索取數(shù)據(jù)，而不考慮當(dāng)前所播放壓縮碼流的實(shí)際碼率參數(shù)。只有滿足特定封裝條件的媒體文件格式才支持這種類型的漸進(jìn)下載播放，例如用于初始化解碼器的編碼參數(shù)必須放置在媒體文件的起始部位，音視頻數(shù)據(jù)完全按照時(shí)間順序進(jìn)行交織等。
漸進(jìn)下載流媒體播放采用標(biāo)準(zhǔn)HTTP協(xié)議來(lái)在Web服務(wù)器和客戶端之間遞送媒體數(shù)據(jù)，而HTTP又承載于TCP之上。TCP最初是為非實(shí)時(shí)性數(shù)據(jù)傳輸而設(shè)計(jì)的，其優(yōu)化目標(biāo)在于在保證整個(gè)網(wǎng)絡(luò)總的穩(wěn)定性和高吞吐量的前提下，最大化數(shù)據(jù)傳輸速率。為達(dá)到這個(gè)目的，TCP采用了一種稱之為慢啟動(dòng)的算法，它首先以一個(gè)較低的速率來(lái)發(fā)送數(shù)據(jù)，然后再逐漸提高這個(gè)速率，直到接收到來(lái)自目的方的分組丟失反饋報(bào)告。此時(shí)TCP認(rèn)為它已達(dá)到最高帶寬限制或者網(wǎng)絡(luò)中出現(xiàn)了擁塞，于是重新開始以一個(gè)較低速率來(lái)發(fā)送數(shù)據(jù)，然后逐漸提高，這個(gè)過(guò)程不斷地重復(fù)下去。TCP通過(guò)重傳丟失的分組來(lái)達(dá)到可靠傳輸?shù)哪康摹Ｈ欢?#xff0c;對(duì)于流媒體數(shù)據(jù)來(lái)說(shuō)，TCP 無(wú)法保證所有重傳的數(shù)據(jù)能在它們預(yù)定的播放時(shí)刻之前按時(shí)到達(dá)客戶端。當(dāng)這種情況出現(xiàn)時(shí)，客戶端不能跳過(guò)這些丟失或遲到的數(shù)據(jù)直接播放時(shí)間上靠后的媒體數(shù)據(jù)，而必須停下來(lái)等待，從而導(dǎo)致播放器畫面停頓和斷斷續(xù)續(xù)的現(xiàn)象發(fā)生。在漸進(jìn)下載播放模式中，客戶端需要在硬盤上緩存所有前面已經(jīng)下載的媒體數(shù)據(jù)，對(duì)本地存儲(chǔ)空間的需求較大。播放過(guò)程中用戶只能在前面已經(jīng)下載媒體數(shù)據(jù)的時(shí)間范圍內(nèi)進(jìn)行進(jìn)度條搜索和快進(jìn)、快退等操作，而無(wú)法在整個(gè)媒體文件時(shí)間范圍內(nèi)執(zhí)行這些操作。
嚴(yán)格意義上，基于HTTP的VOD不算是真的流媒體，英文稱為“progressive downloading”或者“pseudo streaming”，為什么這樣呢？因?yàn)镠TTP缺乏流媒體基本的流控，由此基于HTTP協(xié)議很難實(shí)現(xiàn)媒體播放的快進(jìn)，快退，暫停。那么，通常的媒體播 放器又是如何利用HTTP來(lái)實(shí)現(xiàn)這樣的功能呢？
我們都知道，不管媒體文件有多大，HTTP都只是視它為一個(gè)HTTP的元素，可以只需要發(fā)送一個(gè)HTTP請(qǐng)求，WEB Server就會(huì)源源不斷地將媒體流推送給客戶端，而不管客戶端是否接受，這就是HTTP協(xié)議本身沒有流控的原因，那這樣會(huì)帶來(lái)什么后果呢？
如果服務(wù)器的推流速度和客戶端同步， 那么基本不會(huì)出現(xiàn)什么大問題；如果小于客戶端的接收流的速度，那么播放就會(huì)一卡一卡的；如果大于或者遠(yuǎn)大于客戶端的接收速度，那又會(huì)是怎么樣的結(jié)果呢？很 不幸，在我們所有的ISTV項(xiàng)目中，只要是基于HTTP的VOD，都無(wú)一例外是第三種情況。因?yàn)槲覀僔OD是基于局域網(wǎng)的，大家都知道，局域網(wǎng)的帶寬資源 是很豐富的，服務(wù)器的推流的速度肯定大于播放器的播放速度，那么在這么速度極端不協(xié)調(diào)的情況下，服務(wù)器的推流速度究竟由誰(shuí)來(lái)限制呢？
答案是：TCP協(xié)議棧。我們的VOD點(diǎn)播是基于TCP的HTTP協(xié)議。TCP是安全的，可靠的，包肯定不會(huì)丟，服務(wù)器檢測(cè)到客戶端的接收緩沖區(qū)滿了，就會(huì)減小發(fā)送數(shù)據(jù)滑動(dòng)窗口的大小。所以HTTP的流控是通過(guò)TCP協(xié)議棧來(lái)調(diào)節(jié)的，不是HTTP本身。試想，這樣對(duì)服務(wù)器造成的壓力有多大!
下面就分析基于HTTP協(xié)議如何實(shí)現(xiàn)SEEK，PAUSE等操作
1.SEEK（快進(jìn)和快退）
先關(guān)閉之前的tcp連接，重新連接，發(fā)送http請(qǐng)求，該請(qǐng)求帶了媒體的偏移位置。由此可見，每一次的快進(jìn)和快退，都等于是重新開始播放，只是每次開始播放的位置不一樣。
2.PAUSE
該操作就更有意思了，客戶端暫停了播放，也就是不從緩沖區(qū)讀取數(shù)據(jù)了，但是服務(wù)器不知道客戶端停止了播放，依然不停地發(fā)送數(shù)據(jù)給客戶端，直到客戶端的接收 緩沖區(qū)已滿，然后服務(wù)器的數(shù)據(jù)發(fā)送不出去了，理論上是服務(wù)器端的滑動(dòng)窗口的大小估計(jì)就是0了，然后協(xié)議棧還在不停在嘗試發(fā)送數(shù)據(jù)，因?yàn)槭腔趖cp，這些 數(shù)據(jù)還不能丟。nnd，這種方式實(shí)現(xiàn)暫停，協(xié)議棧都哭了。很不幸，MPLAYER就是這么干的。所以暫停的時(shí)間長(zhǎng)了，就容易出現(xiàn)問題。
雖然HTTP沒有PAUSE的支持，但是針對(duì)PAUSE是可以優(yōu)化的，優(yōu)化的方法是，將媒體文件分片，分片的大小以稍小于TCP協(xié)議棧的緩沖區(qū)大小為宜。 HTTP請(qǐng)求一次只請(qǐng)求一個(gè)分片的大小，暫停播放后，就不在發(fā)送分片請(qǐng)求了。這樣可以保證讓服務(wù)器運(yùn)行的時(shí)間長(zhǎng)一些，播放器暫停理論上可以無(wú)限長(zhǎng)了。
?
二、HTTP Live Streaming
HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實(shí)現(xiàn)的基于HTTP的流媒體傳輸協(xié)議，可實(shí)現(xiàn)流媒體的直播和點(diǎn)播，主要應(yīng)用在iOS系統(tǒng)，為iOS設(shè)備（如iPhone、iPad）提供音視頻直播和點(diǎn)播方案。HLS點(diǎn)播，基本上就是常見的分段HTTP點(diǎn)播，不同在于，它的分段非常小。要實(shí)現(xiàn)HLS點(diǎn)播，重點(diǎn)在于對(duì)媒體文件分段，目前有不少開源工具可以使用，這里我就不再討論，只談HLS直播技術(shù)。一個(gè)典型的HTTP Live Streaming流媒體系統(tǒng)由內(nèi)容準(zhǔn)備、內(nèi)容分發(fā)和客戶端軟件三部分組成，如圖所示。
?
1. 內(nèi)容準(zhǔn)備
內(nèi)容準(zhǔn)備部分負(fù)責(zé)將輸入的音視頻媒體內(nèi)容轉(zhuǎn)換成為適合于內(nèi)容分發(fā)組件進(jìn)行遞送的格式。對(duì)于視頻直播，編碼器首先將攝像機(jī)實(shí)時(shí)采集的音視頻數(shù)據(jù)壓縮編碼為符合特定標(biāo)準(zhǔn)的音視頻基本流(目前蘋果的系統(tǒng)僅支持H.264視頻和AAC音頻)，然后再?gòu)?fù)用和封裝成為符合MPEG-2系統(tǒng)層標(biāo)準(zhǔn)的傳輸流(TS)格式進(jìn)行輸出。流分割器(Stream Segmenter)負(fù)責(zé)將編碼器輸出的MPEG-2 TS流分割為一系列連續(xù)的、長(zhǎng)度均等的小TS文件(后綴名為.ts)，并依次發(fā)送至內(nèi)容分發(fā)組件中的
Web服務(wù)器進(jìn)行存儲(chǔ)。與此同時(shí)，為了跟蹤播放過(guò)程中媒體文件的可用性和當(dāng)前位置，流分割器還需創(chuàng)建一個(gè)含有指向這些小TS文件指針的索引文件，同樣放置于Web服務(wù)器之中。這個(gè)索引文件可以看作是一個(gè)連續(xù)媒體流中的播放列表滑動(dòng)窗口，每當(dāng)流分割器生成一個(gè)新的TS文件時(shí)，這個(gè)索引文件的內(nèi)容也被更新，新的文件URI(統(tǒng)一資源定位符)加入到滑動(dòng)窗口的末尾，老的文件URI則被移去，這樣索引文件中將始終包含最新的固定數(shù)量的x個(gè)分段，如圖所示。流分割器還可以對(duì)其生成的每個(gè)小TS文件進(jìn)行加密，并生成相應(yīng)的密鑰文件。
之所以采用MPEG-2 TS格式來(lái)對(duì)編碼后的媒體流進(jìn)行統(tǒng)一封裝，是因?yàn)樗軌驅(qū)⒁粢曨l媒體流嚴(yán)格按時(shí)序進(jìn)行交織復(fù)用，任意截取和分段后，每一個(gè)分段都可能不依賴于之前的分段而獨(dú)立進(jìn)行解碼和播放。為此，TS文件中必須僅包含一個(gè)MPEG-2節(jié)目，在每個(gè)文件的開頭應(yīng)包含一個(gè)節(jié)目關(guān)聯(lián)表(PAT)和一個(gè)節(jié)目映射表(PMT)，包含視頻的文件中還必須含有至少一個(gè)關(guān)鍵幀和其他足夠信息(如序列頭)用以完成解碼器的初始化。索引文件采用擴(kuò)展的M3U播放列表格式，后綴名為.m3u8。M3U播放列表是一個(gè)由若干文本行組成的文本文件，其中每一行要么是一個(gè)URI，一個(gè)空行，或者是一個(gè)以注釋符“#”起始的行。每個(gè)URI行指向一個(gè)分段的媒體文件，或者一個(gè)衍生的索引(播放列表)文件。除了以“#EXT”起始的行是標(biāo)簽行外，其他以“#”起始的行是注釋，應(yīng)予忽略。下面是一個(gè)簡(jiǎn)單的.m3u8索引文件例子，其所表示的媒體流由3個(gè)未加密的長(zhǎng)度為10秒的TS文件組成。
對(duì) 于 視 頻 點(diǎn) 播 ( V O D ) ， 文 件 分 割 器 ( F i l e Segmenter)首先將預(yù)編碼存儲(chǔ)的媒體文件轉(zhuǎn)碼為MPEG-2 TS格式文件(已經(jīng)封裝為TS格式的文件則忽略這一步)，然后再將該TS文件分割成一系列長(zhǎng)度均等的小TS文件。文件分割器同樣也生成一個(gè)含有指向這些小文件指針的索引文件。與直播型會(huì)話不同的是，這里的索引文件是一個(gè)不隨時(shí)間而更新的靜態(tài)文件，其中包含一個(gè)節(jié)目從頭到尾所有分段文件的URI列表，并以#EXT-X-ENDLIST標(biāo)簽結(jié)尾。可以通過(guò)下述方法將一個(gè)直播事件轉(zhuǎn)換成VOD節(jié)目源供以后點(diǎn)播：在服務(wù)器上不刪除已經(jīng)過(guò)期的分段媒體文件，同時(shí)在索引文件中也不刪除這些文件所對(duì)應(yīng)的URI索引項(xiàng)，在直播結(jié)束的時(shí)候?qū)?EXT-X-ENDLIST標(biāo)簽添加至索引文件的末尾。
?
2. 內(nèi)容分發(fā)
內(nèi)容分發(fā)系統(tǒng)用于通過(guò)HTTP協(xié)議將分割后的小媒體文件及其索引文件遞送至客戶端播放器，它既可以是一個(gè)普通的Web服務(wù)器，也可以是一個(gè)Web緩存系統(tǒng)。幾乎不需要對(duì)Web服務(wù)器做任何特殊的配置，以及增加其他定制的模塊。推薦的配置僅限于對(duì).m3u8文件和.ts文件的MIME類型關(guān)聯(lián)，如表所示。
由于索引文件需要頻繁更新和下載，因此在Web cache的配置中有必要對(duì).m3u8文件的TTL(time-to-live)值進(jìn)行微調(diào)以保證客戶端每次請(qǐng)求該文件時(shí)都能夠下載到它的最新版本。
?
3. 客戶端軟件
通常情況下，客戶端軟件通過(guò)訪問Web網(wǎng)頁(yè)中的URL鏈接來(lái)獲取和下載一個(gè)流媒體會(huì)話的索引文件。這個(gè)索引文件進(jìn)一步指定了服務(wù)器上當(dāng)前可用的TS格式媒體文件、解密密鑰和其他替換流的位置。對(duì)于選定的媒體流，客戶端依次下載索引文件中列出的每一個(gè)可用媒體文件。當(dāng)這些媒體文件緩沖夠一定數(shù)量后，客戶端將它們按順序重新拼裝成一個(gè)連貫的TS流，然后發(fā)送至播放器進(jìn)行解碼和呈現(xiàn)。對(duì)于加密的媒體文件，客戶端還負(fù)責(zé)根據(jù)索引文件的指引來(lái)獲取解密密鑰，提供用戶認(rèn)證接口，并按需進(jìn)行解密。對(duì)于視頻點(diǎn)播，上述過(guò)程不斷持續(xù)下去，直到客戶端碰到索引文件中的#EXT-X-ENDLIST標(biāo)簽。對(duì)于視頻直播，索引文件中不存在#EXT-X-ENDLIST標(biāo)簽，客戶端將周期性地向Web服務(wù)器重新請(qǐng)求獲取該索引文件的更新版本，然后在這個(gè)更新版的索引文件中查找新的媒體文件和解密密鑰，并將它們的URI添加至下載隊(duì)列的末尾。需要注意HTTP Live Streaming并不是一個(gè)真正實(shí)時(shí)的流媒體系統(tǒng)，這是因?yàn)閷?duì)應(yīng)于媒體分段的大小和持續(xù)時(shí)間有一定潛在的時(shí)間延遲。在客戶端中，至少在一個(gè)分段媒體文件被完全下載之后才能夠開始播放，而通常要求下載完成兩個(gè)分段媒體文件之后才開始播放以保證不同分段音視頻之間的無(wú)縫連接。此外，在客戶端開始下載之前，必須等待服務(wù)器端的編碼器和流分割器至少生成一個(gè)TS文件，這也會(huì)帶來(lái)潛在的時(shí)延。在推薦配置下，HTTP Live Streaming系統(tǒng)的典型時(shí)延約在30s左右。
?
4. 網(wǎng)絡(luò)自適應(yīng)的流間切換和故障保護(hù)
在基于HTTP Live Streaming的流媒體系統(tǒng)中，服務(wù)器可以為同一節(jié)目源準(zhǔn)備多份以不同碼率和質(zhì)量編碼的替換流，并為每個(gè)替換流都生成一個(gè)衍生的索引文件。在主索引文件中通過(guò)包含一系列指向其他衍生索引文件的URI指針來(lái)找到相應(yīng)的替換流，如圖所示。
在移動(dòng)互聯(lián)網(wǎng)環(huán)境下，由于網(wǎng)絡(luò)覆蓋面的不同和信號(hào)強(qiáng)弱的變化，移動(dòng)終端可能隨時(shí)在不同的無(wú)線接入網(wǎng)絡(luò)(例如3G，EDGE，GPRS和WiFi等)之間進(jìn)行切換。此時(shí)客戶端軟件可根據(jù)網(wǎng)絡(luò)和帶寬的變化情況隨時(shí)切換到不同衍生索引文件所指向的替換流進(jìn)行下載，從而自適應(yīng)地為用戶提供相應(yīng)網(wǎng)絡(luò)條件下接近最優(yōu)的音視頻QoS體驗(yàn)。上述替換流和衍生索引文件機(jī)制除了可以用于基于帶寬波動(dòng)的動(dòng)態(tài)流間切換外，還可以用于服務(wù)器的故障保護(hù)。為此目的，首先在一臺(tái)服務(wù)器上按照正常流程生成一個(gè)媒體流或者多個(gè)替換流，以及對(duì)應(yīng)的索引文件，然后再在另一臺(tái)服務(wù)器上生成一套并行的備份媒體流和索引文件。接下來(lái)將指向備份流的索引加入到主索引文件之中，使得其中針對(duì)每個(gè)帶寬值都對(duì)應(yīng)有一個(gè)主媒體流和一個(gè)備份媒體流。例如，假定主服務(wù)器和備份服務(wù)器分別為ALPHA和BETA，則主索引文件中的內(nèi)容可能如下所示：
在上述例子中，當(dāng)客戶端連接主服務(wù)器ALPHA失敗時(shí)，它將試圖連接備份服務(wù)器BETA，從中獲取最高帶寬值替換流所對(duì)應(yīng)的衍生索引文件，并進(jìn)一步根據(jù)該索引文件下載相應(yīng)的替換媒體流文件。
相對(duì)于常見的流媒體直播協(xié)議，例如RTMP協(xié)議、RTSP協(xié)議、MMS協(xié)議等，HLS直播最大的不同在于，直播客戶端獲取到的，并不是一個(gè)完整的數(shù)據(jù)流。HLS協(xié)議在服務(wù)器端將直播數(shù)據(jù)流存儲(chǔ)為連續(xù)的、很短時(shí)長(zhǎng)的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件，因?yàn)榉?wù)器端總是會(huì)將最新的直播數(shù)據(jù)生成新的小文件，這樣客戶端只要不停的按順序播放從服務(wù)器獲取到的文件，就實(shí)現(xiàn)了直播。由此可見，基本上可以認(rèn)為，HLS是以點(diǎn)播的技術(shù)方式來(lái)實(shí)現(xiàn)直播。由于數(shù)據(jù)通過(guò)HTTP協(xié)議傳輸，所以完全不用考慮防火墻或者代理的問題，而且分段文件的時(shí)長(zhǎng)很短，客戶端可以很快的選擇和切換碼率，以適應(yīng)不同帶寬條件下的播放。不過(guò)HLS的這種技術(shù)特點(diǎn)，決定了它的延遲一般總是會(huì)高于普通的流媒體直播協(xié)議。
根據(jù)以上的了解要實(shí)現(xiàn)HTTP Live Streaming直播，需要研究并實(shí)現(xiàn)以下技術(shù)關(guān)鍵點(diǎn)
1.采集視頻源和音頻源的數(shù)據(jù)
2.對(duì)原始數(shù)據(jù)進(jìn)行H264編碼和AAC編碼
3.視頻和音頻數(shù)據(jù)封裝為MPEG-TS包
4.HLS分段生成策略及m3u8索引文件
5.HTTP傳輸協(xié)議
?
三、RTSP (Real Time Streaming Protocol)
上述基于漸進(jìn)下載的流媒體播放僅能支持點(diǎn)播而不能支持直播，媒體流數(shù)據(jù)到達(dá)客戶端的速率無(wú)法精確控制，客戶端仍需維持一個(gè)與服務(wù)器上媒體文件同樣大小的緩沖存儲(chǔ)空間，在開始播放之前需要等待一段較長(zhǎng)的緩沖時(shí)間從而導(dǎo)致實(shí)時(shí)性較差，播放過(guò)程中由于網(wǎng)絡(luò)帶寬的波動(dòng)或分組丟失可能會(huì)導(dǎo)致畫面停頓或斷續(xù)等待，不支持全時(shí)間范圍的搜索、快進(jìn)、快退等VCR操作。為克服這些問題，需要引入專門的流媒體服務(wù)器以及相應(yīng)的實(shí)時(shí)流媒體傳輸和控制協(xié)議來(lái)進(jìn)行支持。RTSP/RTP是目前業(yè)界最為流行和廣為采用的實(shí)時(shí)流媒體協(xié)議。它實(shí)際上由一組在IETF中標(biāo)準(zhǔn)化的協(xié)議所組成，包括RTSP(實(shí)時(shí)流媒體會(huì)話協(xié)議)， SDP(會(huì)話描述協(xié)議)，RTP(實(shí)時(shí)傳輸協(xié)議)，以及針對(duì)不同編解碼標(biāo)準(zhǔn)的RTP凈載格式等，共同協(xié)作來(lái)構(gòu)成一個(gè)流媒體協(xié)議棧，如圖所示。基于該協(xié)議棧的擴(kuò)展已被ISMA(互聯(lián)網(wǎng)流媒體聯(lián)盟)和3GPP(第三代合作伙伴計(jì)劃)等組織采納成為互聯(lián)網(wǎng)和3G移動(dòng)互聯(lián)網(wǎng)的流媒體標(biāo)準(zhǔn)。
RTSP是用來(lái)建立和控制一個(gè)或多個(gè)時(shí)間同步的連續(xù)音視頻媒體流的會(huì)話協(xié)議。通過(guò)在客戶機(jī)和服務(wù)器之間傳遞RTSP會(huì)話命令，可以完成諸如請(qǐng)求播放、開始、暫停、查找、快進(jìn)和快退等VCR控制操作。雖然RTSP會(huì)話通常承載于可靠的TCP連接之上，但也可以使用UDP等無(wú)連接協(xié)議來(lái)傳送RTSP會(huì)話命令。在RTSP協(xié)議中起關(guān)鍵作用的命令主要包括下面幾個(gè)：
1) SETUP：使服務(wù)器分配媒體流資源，并啟動(dòng)一個(gè)RTSP會(huì)話。
2) PLAY和RECORD：在SETUP所啟動(dòng)會(huì)話并分配資源的某個(gè)流上開始數(shù)據(jù)傳輸。
3) PAUSE：暫時(shí)中止一個(gè)流的數(shù)據(jù)傳輸而不釋放服務(wù)器資源。
4) TEARDOWN：釋放服務(wù)器上的流資源，結(jié)束RTSP會(huì)話。
SDP協(xié)議用來(lái)描述多媒體會(huì)話。SDP協(xié)議的主要作用在于公告一個(gè)多媒體會(huì)話中所有媒體流的相關(guān)描述信息，以使得接收者能夠感知這些描述信息并根據(jù)這些描述參與到這個(gè)會(huì)話中來(lái)。SDP會(huì)話描述信息通常是通過(guò)RTSP命令交互來(lái)進(jìn)行傳遞的，其中攜帶的媒體類信息主要包括：
1) 媒體的類型(視頻，音頻等)。
2) 傳輸協(xié)議(RTP/UDP/IP，RTP/TCP/IP等)。
3) 媒體編碼格式(H.264視頻，AVS視頻等)。
4) 流媒體服務(wù)器接收媒體流的IP地址和端口號(hào)。
RTP又稱為實(shí)時(shí)傳輸協(xié)議，用于實(shí)際承載媒體數(shù)據(jù)并為具有實(shí)時(shí)特性的媒體數(shù)據(jù)交互提供端到端的傳輸服務(wù)，例如凈載類型識(shí)別、序列號(hào)、時(shí)間戳和傳輸監(jiān)控等。應(yīng)用程序通常選擇在UDP之上來(lái)運(yùn)行RTP協(xié)議，以便利用UDP的復(fù)用和校驗(yàn)和等功能，并提高網(wǎng)絡(luò)傳輸?shù)挠行掏铝俊Ｈ欢鳵TP仍可選擇與其它網(wǎng)絡(luò)傳輸協(xié)議(例如TCP)一塊使用。一個(gè)RTP分組由RTP頭和RTP凈載(payload)兩部分組成。上層應(yīng)用程序主要通過(guò)RTP頭中的序列號(hào)字段(sequence number)和時(shí)間戳(timestamp)字段來(lái)實(shí)施其所承載媒體流數(shù)據(jù)的同步定時(shí)播放和QoS控制。RTP凈載部分實(shí)際承載客戶端所需要的音視頻媒體數(shù)據(jù)。針對(duì)不同的音視頻編碼標(biāo)準(zhǔn)可能需要定義不同的RTP凈載格式，例如H.264的RTP凈載格式標(biāo)準(zhǔn)和AVS視頻的RTP凈載格式標(biāo)準(zhǔn)。流媒體服務(wù)器和客戶端播放器依照這些凈載格式標(biāo)準(zhǔn)來(lái)進(jìn)行媒體數(shù)據(jù)流的RTP打包和分拆重組工作。RTSP/RTP流媒體協(xié)議棧的使用需要專門的流媒體服務(wù)器進(jìn)行參與。與漸進(jìn)下載中媒體數(shù)據(jù)的被動(dòng)突發(fā)遞送不同，在有流媒體服務(wù)器參與的媒體分發(fā)過(guò)程中，媒體數(shù)據(jù)是以與壓縮的音視頻媒體碼率相匹配的速率主動(dòng)和智能地發(fā)送的。在整個(gè)媒體遞送過(guò)程中，服務(wù)器與客戶端緊密聯(lián)系，并能夠?qū)?lái)自客戶端的反饋信息做出響應(yīng)。RTP是真正的實(shí)時(shí)傳輸協(xié)議，客戶端僅需要維持一個(gè)很小的解碼緩沖區(qū)用于緩存視頻解碼所需的少數(shù)參考幀數(shù)據(jù)，從而大大縮短了起始播放時(shí)延，通常可控制在1秒之內(nèi)。使用UDP來(lái)承載RTP數(shù)據(jù)包可提高媒體數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性和吞吐量。當(dāng)因?yàn)榫W(wǎng)絡(luò)擁塞而發(fā)生RTP丟包時(shí)，服務(wù)器可以根據(jù)媒體編碼特性智能地進(jìn)行選擇性重傳，故意丟棄一些不重要的數(shù)據(jù)包；客戶端也可以不必等待未按時(shí)到達(dá)的數(shù)據(jù)而繼續(xù)向前播放，從而保證媒體播放的流暢性。
RTSP（Real Time Streaming Protocol），實(shí)時(shí)流傳輸協(xié)議，是TCP/IP協(xié)議體系中的一個(gè)應(yīng)用層協(xié)議，由哥倫比亞大學(xué)、網(wǎng)景和RealNetworks公司提交的IETF RFC標(biāo)準(zhǔn)。該協(xié)議定義了一對(duì)多應(yīng)用程序如何有效地通過(guò)IP網(wǎng)絡(luò)傳送多媒體數(shù)據(jù)。類似HTTP協(xié)議的流控制協(xié)議。它們都使用純文本來(lái)發(fā)送信息，而且rtsp協(xié)議的語(yǔ)法也和HTTP類似，和HTTP協(xié)議相比RTSP協(xié)議所不同的地方是，RTSP協(xié)議是有狀態(tài)的協(xié)議，而HTTP是無(wú)狀態(tài)的協(xié)議。RTSP通過(guò)維護(hù)一個(gè)session來(lái)維護(hù)其狀態(tài)的轉(zhuǎn)換。RTSP協(xié)議的默認(rèn)端口是554，默認(rèn)的承載協(xié)議為TCP。
目前對(duì)于RTSP在IOS客戶端播放技術(shù)還是以FFMPEG+貼圖的方式為主。
?
四、架構(gòu)：
出于便于管理和擴(kuò)展，帶寬限制和多用戶并發(fā)的考慮，商用方案都會(huì)采用流媒體服務(wù)器+WEB服務(wù)器+中轉(zhuǎn)服務(wù)器+手機(jī)客戶端的方案，其中：
- 流媒體服務(wù)器(streaming server)負(fù)責(zé)采集視頻源并壓縮編碼并隨時(shí)等待來(lái)自客戶端的rtsp連接請(qǐng)求；
- WEB服務(wù)器(web server)便于發(fā)布和管理視頻信息；
- 中轉(zhuǎn)服務(wù)器(transmission server）是可選的，用于把來(lái)自client的RTSP請(qǐng)求轉(zhuǎn)發(fā)給server,并把服務(wù)器端的實(shí)時(shí)流轉(zhuǎn)給client，這樣的好處是在相同帶寬下支持更多的用戶同時(shí)觀看；
- 手機(jī)客戶端(client)可以用手機(jī)內(nèi)置的播放器（如nokia上的realplayer)或者自己開發(fā)的獨(dú)立播放器，前者的好處是降低用戶使用門檻，便于大規(guī)模應(yīng)用；后者方便擴(kuò)展和定制，滿足更多的功能。
streaming server是整個(gè)方案的核心，目前主流的流媒體服務(wù)器解決方案如下：
手機(jī)端框架流程如下：
手機(jī)客戶端與服務(wù)器端的傳輸協(xié)議目前常用有HTTP,RTSP兩種：
早期的手機(jī)電視多用的HTTP，HTTP的優(yōu)點(diǎn)有不用特殊的服務(wù)器軟件，有IIS即可，不用考慮防火墻NAT，但HTTP不支持實(shí)時(shí)流，也會(huì)浪費(fèi)帶寬；RTSP則是當(dāng)前流媒體傳輸?shù)闹髁鳂?biāo)準(zhǔn)，連微軟都拋棄了MMS而轉(zhuǎn)而支持RTSP， RTSP可以支持客戶端暫停回放停止等操作，基本不用考慮音視頻同步問題（因?yàn)橐纛l視頻分別從不同RTP PORT讀入緩沖）。值得說(shuō)明的是，RTSP成功后，就開始RTP傳輸，分為RTP OVER TCP和RTP OVER UDP，前者保證每個(gè)數(shù)據(jù)包都能收到，如果沒收到就重傳，而且不用考慮防火墻NAT；后者只保證盡最大努力的傳輸，不會(huì)重傳丟幀，實(shí)時(shí)性好，要解決防火墻NAT問題。如果對(duì)幀率要求比較高的手機(jī)電視，推薦采用UDP傳輸，因?yàn)檠舆t較大的重傳數(shù)據(jù)對(duì)用戶是沒有意義的，寧可丟棄。
網(wǎng)絡(luò)部分可采用強(qiáng)大的開源庫(kù)live555實(shí)現(xiàn)RTSP/RTP協(xié)議，其性能穩(wěn)定而且支持大多數(shù)音視頻格式的傳輸。(當(dāng)然ffmpeg也實(shí)現(xiàn)了網(wǎng)絡(luò)傳輸部分,經(jīng)過(guò)改動(dòng)后也能用）對(duì)live555經(jīng)過(guò)裁剪后移植到symbian和windows mobile，這部分工作在symbian真機(jī)調(diào)試比較費(fèi)時(shí)。
視頻解碼部分當(dāng)然還是采用ffmpeg,移植了mpeg4 sp/h.264解碼器，在沒有任何優(yōu)化的情況下可支持32K,CIF,5-10fps的效果，對(duì)于一般的流媒體應(yīng)用足夠了。以后還要經(jīng)過(guò)算法和匯編優(yōu)化。解碼后還需要經(jīng)過(guò)yuv2rgb和scale，需要注意的是ffmpeg的解碼有消隱區(qū)的說(shuō)法，即qcif的圖像其linesize不是176而是192，如果你發(fā)現(xiàn)解碼后圖像呈綠色，需用img_convert轉(zhuǎn)一下(目的格式也是PIX_FMT_YUV420P)。symbian上用DSA直接寫屏就行。windows mobile上可以用sdl.
音頻解碼主要包括AAC,AMRNB,AMRWB。AAC和AMRNB是gprs和edge帶寬支持的音頻（aac效果比amrnb好),AMRWB是3G后的音頻格式。在ffmpeg 0.5 release中已經(jīng)支持amrnb/wb的fixed point解碼，很強(qiáng)大。
?
五、分析與比較
作為最簡(jiǎn)單和原始的流媒體解決方案，HTTP漸進(jìn)下載唯一顯著的優(yōu)點(diǎn)在于它僅需要維護(hù)一個(gè)標(biāo)準(zhǔn)的Web服務(wù)器，而這樣的服務(wù)器基礎(chǔ)設(shè)施在互聯(lián)網(wǎng)中已經(jīng)普遍存在，其安裝和維護(hù)的工作量和復(fù)雜性比起專門的流媒體服務(wù)器來(lái)說(shuō)要簡(jiǎn)單和容易得多。然而其缺點(diǎn)和不足卻也很多，首先是僅適用于點(diǎn)播而不支持直播，其次是缺乏靈活的會(huì)話控制功能和智能的流量調(diào)節(jié)機(jī)制，再次是客戶端需要硬盤空間以緩存整個(gè)文件而不適合于嵌入式設(shè)備等。基于RTSP/RTP的流媒體系統(tǒng)專門針對(duì)大規(guī)模流媒體直播和點(diǎn)播等應(yīng)用而設(shè)計(jì)，需要專門的流媒體服務(wù)器支持，與HTTP漸進(jìn)下載相比主要具有如下優(yōu)勢(shì)：
此外還可利用DRM等版權(quán)保護(hù)系統(tǒng)進(jìn)行加密處理。盡管如此，基于RTSP/RTP的流媒體系統(tǒng)在實(shí)際的應(yīng)用部署特別是移動(dòng)互聯(lián)網(wǎng)應(yīng)用中仍然遇到了不少問題，主要體現(xiàn)在：
蘋果公司的HTTP Live Streaming正是為了解決這些問題應(yīng)運(yùn)而生的，其主要特點(diǎn)是：放棄專門的流媒體服務(wù)器，而返回到使用標(biāo)準(zhǔn)的Web服務(wù)器來(lái)遞送媒體數(shù)據(jù)；將容量巨大的連續(xù)媒體數(shù)據(jù)進(jìn)行分段，分割為數(shù)量眾多的小文件進(jìn)行傳遞，迎合了Web服務(wù)器的文件傳輸特性；采用了一個(gè)不斷更新的輕量級(jí)索引文件來(lái)控制分割后小媒體文件的下載和播放，可同時(shí)支持直播和點(diǎn)播，以及VCR類會(huì)話控制操作。HTTP協(xié)議的使用降低了HTTP Live Streaming系統(tǒng)的部署難度，同時(shí)也簡(jiǎn)化了客戶端(特別是嵌入式移動(dòng)終端)軟件的開發(fā)復(fù)雜度。此外，文件分割和索引文件的引入也使得帶寬自適應(yīng)的流間切換、服務(wù)器故障保護(hù)和媒體加密等變得更加方便。與RTSP/RTP相比，HTTP Live Streaming的最大缺點(diǎn)在于它并非一個(gè)真正的實(shí)時(shí)流媒體系統(tǒng)，在服務(wù)器和客戶端都存在一定的起始延遲。而且目前主要面向移動(dòng)多媒體應(yīng)用，推薦支持的最高視頻碼率僅為800 Kbps，對(duì)于更高碼率特別是高清視頻的支持程度尚需進(jìn)一步的探究和驗(yàn)證。歸納起來(lái)，上述三種流媒體協(xié)議的綜合比較見表所示。
HTTP漸進(jìn)下載、RTSP/RTP和HTTP Live Streaming等三種流媒體協(xié)議，對(duì)各自的基本方法和特點(diǎn)進(jìn)行了介紹，特別是對(duì)HTTP Live Streaming協(xié)議進(jìn)行了較為詳細(xì)的描述，并在此基礎(chǔ)上對(duì)三種流媒體協(xié)議進(jìn)行了對(duì)比分析。總體來(lái)說(shuō)，HTTP漸進(jìn)下載系統(tǒng)部署起來(lái)最為簡(jiǎn)單，但僅適用于較小規(guī)模的短視頻點(diǎn)播應(yīng)用；
基于RTSP/RTP的協(xié)議棧適合于大規(guī)模可擴(kuò)展的交互式實(shí)時(shí)流媒體應(yīng)用，但需要專門流媒體服務(wù)器的支持，安裝和維護(hù)起來(lái)都較為復(fù)雜；
HTTP Live Streaming可直接部署于目前擁有廣泛運(yùn)營(yíng)基礎(chǔ)的Web服務(wù)器網(wǎng)絡(luò)環(huán)境，不需要對(duì)網(wǎng)絡(luò)基礎(chǔ)設(shè)施進(jìn)行升級(jí)改造，特別適合于對(duì)實(shí)時(shí)性要求不是太高的消費(fèi)級(jí)移動(dòng)互聯(lián)網(wǎng)流媒體應(yīng)用。
文／MasonFu（簡(jiǎn)書作者）
《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀總結(jié)
以上是生活随笔為你收集整理的iOS流媒体直播整个框架介绍(HLS、RTSP)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HLS-Demo IOS 视屏直播样例
- 下一篇： iOS视频直播学习