九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

打開(kāi)APP
userphoto
未登錄

開(kāi)通VIP,暢享免費(fèi)電子書(shū)等14項(xiàng)超值服

開(kāi)通VIP
ios流媒體直播整個(gè)框架介紹(HLS、RTSP)

一、HTTP(WebService)

基于HTTP的漸進(jìn)下載Progressive Download流媒體播放僅是在完全下載后再播放模式基礎(chǔ)上做了一些小的改進(jìn)。與下載播放模式中必須等待整個(gè)文件下載完畢后才能開(kāi)始播放不同,漸進(jìn)下載客戶端在開(kāi)始播放之前僅需等待一段較短的時(shí)間用于下載和緩沖該媒體文件最前面的一部分?jǐn)?shù)據(jù),之后便可以一邊下載一邊播放。在正式開(kāi)始播放之前的這一小段緩沖應(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)了擁塞,于是重新開(kāi)始以一個(gè)較低速率來(lái)發(fā)送數(shù)據(jù),然后逐漸提高,這個(gè)過(guò)程不斷地重復(fù)下去。TCP通過(guò)重傳丟失的分組來(lái)達(dá)到可靠傳輸?shù)哪康?。然而,?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)致播放器畫(huà)面停頓和斷斷續(xù)續(xù)的現(xiàn)象發(fā)生。在漸進(jìn)下載播放模式中,客戶端需要在硬盤(pá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é)議本身沒(méi)有流控的原因,那這樣會(huì)帶來(lái)什么后果呢?

如果服務(wù)器的推流速度和客戶端同步, 那么基本不會(huì)出現(xiàn)什么大問(wè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)求帶了媒體的偏移位置。由此可見(jiàn),每一次的快進(jìn)和快退,都等于是重新開(kāi)始播放,只是每次開(kāi)始播放的位置不一樣。
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)問(wèn)題。
雖然HTTP沒(méi)有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)是蘋(píng)果公司(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)播,基本上就是常見(jiàn)的分段HTTP點(diǎn)播,不同在于,它的分段非常小。要實(shí)現(xiàn)HLS點(diǎn)播,重點(diǎn)在于對(duì)媒體文件分段,目前有不少開(kāi)源工具可以使用,這里我就不再討論,只談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)的音視頻基本流(目前蘋(píng)果的系統(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è)文件的開(kāi)頭應(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文件組成。

#EXTM3U#EXT-X-MEDIA-SEQUENCE:0#EXT-X-TARGETDURATION:10#EXTINF:10,http://media.example.com/segment1.ts#EXTINF:10,http://media.example.com/segment2.ts#EXTINF:10,http://media.example.com/segment3.ts#EXT-X-ENDLIST

對(duì) 于 視 頻 點(diǎn) 播 ( V O D ) , 文 件 分 割 器 ( F i l e Segmenter)首先將預(yù)編碼存儲(chǔ)的媒體文件轉(zhuǎn)碼為MPEG-2 TS格式文件(已經(jīng)封裝為T(mén)S格式的文件則忽略這一步),然后再將該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ò)訪問(wèn)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è)分段媒體文件被完全下載之后才能夠開(kāi)始播放,而
通常要求下載完成兩個(gè)分段媒體文件之后才開(kāi)始播放以保證不同分段音視頻之間的無(wú)縫連接。此外,在客戶端開(kāi)始下載之前,必須等待服務(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)容可能如下所示:

#EXTM3U#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000http://ALPHA.example.com/lo/prog_index.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000http://BETA.example.com/lo/prog_index.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000http://ALPHA.example.com/md/prog_index.m3u8#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=500000http://BETA.example.com/md/prog_index.m3u8

在上述例子中,當(dāng)客戶端連接主服務(wù)器ALPHA失敗時(shí),它將試圖連接備份服務(wù)器BETA,從中獲取最高帶寬值替換流所對(duì)應(yīng)的衍生索引文件,并進(jìn)一步根據(jù)該索引文件下載相應(yīng)的替換媒體流文件。

  相對(duì)于常見(jiàn)的流媒體直播協(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)了直播。由此可見(jiàn),基本上可以認(rèn)為,HLS是以點(diǎn)播的技術(shù)方式來(lái)實(shí)現(xiàn)直播。由于數(shù)據(jù)通過(guò)HTTP協(xié)議傳輸,所以完全不用考慮防火墻或者代理的問(wèn)題,而且分段文件的時(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ǔ)空間,在開(kāi)始播放之前需要等待一段較長(zhǎng)的緩沖時(shí)間從而導(dǎo)致實(shí)時(shí)性較差,播放過(guò)程中由于網(wǎng)絡(luò)帶寬的波動(dòng)或分組丟失可能會(huì)導(dǎo)致畫(huà)面停頓或斷續(xù)等待,不支持全時(shí)間范圍的搜索、快進(jìn)、快退等VCR操作。為克服這些問(wèn)題,需要引入專門(mén)的流媒體服務(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é)議棧,如圖所示?;谠搮f(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)求播放、開(kāi)始、暫停、查找、快進(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è)流上開(kāi)始數(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ù)挠行掏铝?。然而RTP仍可選擇與其它網(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é)議棧的使用需要專門(mén)的流媒體服務(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í)延,通??煽刂圃?秒之內(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é)議為T(mén)CP。

目前對(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)或者自己開(kāi)發(fā)的獨(dú)立播放器,前者的好處是降低用戶使用門(mén)檻,便于大規(guī)模應(yīng)用;后者方便擴(kuò)展和定制,滿足更多的功能。

streaming server是整個(gè)方案的核心,目前主流的流媒體服務(wù)器解決方案如下:

  1. helix server :借助Real公司的強(qiáng)大實(shí)力,這是目前最流行的方案, 可以支持所有音視頻格式,性能穩(wěn)定,是唯一可以橫跨 Windows Mac 及 Linux, Solaris ,HP/UX 使用者流媒體服務(wù)的平臺(tái),支持在手機(jī)自帶播放器播放。helix server免費(fèi)的版本只支持1M流量,企業(yè)版很貴。當(dāng)然你要就是另外一回事了
  2. darwin server: 這是apple公司推出的開(kāi)源的流媒體解決方案,支持格式?jīng)]helix那么多,但由于是開(kāi)源的免費(fèi)的,對(duì)于開(kāi)發(fā)者有很大的開(kāi)發(fā)空間。
  3. live555 media server:性能穩(wěn)定,但支持格式比較少(只有mp3,amr,aac,mpeg4 es等幾種流),很少獨(dú)立使用而一般作為系統(tǒng)的一部分。
  4. Windows Media Server:僅限微軟平臺(tái),就不考慮了。

手機(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可以支持客戶端暫?;胤磐V沟炔僮?,基本不用考慮音視頻同步問(wèn)題(因?yàn)橐纛l視頻分別從不同RTP PORT讀入緩沖)。值得說(shuō)明的是,RTSP成功后,就開(kāi)始RTP傳輸,分為RTP OVER TCP和RTP OVER UDP,前者保證每個(gè)數(shù)據(jù)包都能收到,如果沒(méi)收到就重傳,而且不用考慮防火墻NAT;后者只保證盡最大努力的傳輸,不會(huì)重傳丟幀,實(shí)時(shí)性好,要解決防火墻NAT問(wèn)題。如果對(duì)幀率要求比較高的手機(jī)電視,推薦采用UDP傳輸,因?yàn)檠舆t較大的重傳數(shù)據(jù)對(duì)用戶是沒(méi)有意義的,寧可丟棄。

網(wǎng)絡(luò)部分可采用強(qiáng)大的開(kāi)源庫(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解碼器,在沒(méi)有任何優(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直接寫(xiě)屏就行。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ù)雜性比起專門(mén)的流媒體服務(wù)器來(lái)說(shuō)要簡(jiǎn)單和容易得多。然而其缺點(diǎn)和不足卻也很多,首先是僅適用于點(diǎn)播而不支持直播,其次是缺乏靈活的會(huì)話控制功能和智能的流量調(diào)節(jié)機(jī)制,再次是客戶端需要硬盤(pán)空間以緩存整個(gè)文件而不適合于嵌入式設(shè)備等。基于RTSP/RTP的流媒體系統(tǒng)專門(mén)針對(duì)大規(guī)模流媒體直播和點(diǎn)播等應(yīng)用而設(shè)計(jì),需要專門(mén)的流媒體服務(wù)器支持,與HTTP漸進(jìn)下載相比主要具有如下優(yōu)勢(shì):

  1. 流媒體播放的實(shí)時(shí)性。與漸進(jìn)下載客戶端需要先緩沖一定數(shù)量媒體數(shù)據(jù)才能開(kāi)始播放不同,基于RTSP/RTP的流媒體客戶端幾乎在接收到第一幀媒體數(shù)據(jù)的同時(shí)就可以啟動(dòng)播放。

  2. 支持進(jìn)度條搜索、快進(jìn)、快退等高級(jí)VCR控制功能。

  3. 平滑、流暢的音視頻播放體驗(yàn)。在基于RTSP的流媒體會(huì)話期間,客戶端與服務(wù)器之間始終保持會(huì)話聯(lián)系,服務(wù)器能夠?qū)?lái)自客戶端的反饋信息動(dòng)態(tài)做出響應(yīng)。當(dāng)因網(wǎng)絡(luò)擁塞等原因?qū)е驴捎脦挷蛔銜r(shí),服務(wù)器可通過(guò)適當(dāng)降低幀率等方式來(lái)智能調(diào)整發(fā)送速率。此外,UDP傳輸協(xié)議的使用使得客戶端在檢測(cè)到有丟包發(fā)生時(shí),可選擇讓服務(wù)器僅選擇性地重傳部分重要的數(shù)據(jù)(如關(guān)鍵幀),而忽略其他優(yōu)先級(jí)較低的數(shù)據(jù),從而保證在網(wǎng)絡(luò)不好的情況下客戶端也仍能連續(xù)、流暢地進(jìn)行播放。

  4. 支持大規(guī)模用戶擴(kuò)展。普通的Web服務(wù)器主要針對(duì)大量小的HTML文件下載而進(jìn)行優(yōu)化,在傳輸大容量媒體文件方面缺少性能優(yōu)勢(shì)。而專業(yè)的流媒體服務(wù)器在大容量媒體文件硬盤(pán)讀取、內(nèi)存緩沖和網(wǎng)絡(luò)發(fā)送等方面進(jìn)行了優(yōu)化,可支持大規(guī)模用戶接入。

  5. 支持網(wǎng)絡(luò)層多播。網(wǎng)絡(luò)層多播允許單一媒體流共享網(wǎng)絡(luò)路徑,同時(shí)發(fā)送到多個(gè)客戶端,可大大縮減網(wǎng)絡(luò)帶寬需求。只有借助專門(mén)的流媒體服務(wù)器才能實(shí)現(xiàn)這一功能。
  6. 內(nèi)容版權(quán)保護(hù)。在漸進(jìn)下載模式中,下載后的文件緩存在客戶端硬盤(pán)的臨時(shí)目錄中,用戶可將其拷貝至其他位置供以后再次播放。而在基于RTSP/RTP的流媒體系統(tǒng)中,客戶端只在內(nèi)存中維持一個(gè)較小的解碼緩沖區(qū),播放后的媒體數(shù)據(jù)隨時(shí)清除,用戶不容易截取和拷貝。

此外還可利用DRM等版權(quán)保護(hù)系統(tǒng)進(jìn)行加密處理。盡管如此,基于RTSP/RTP的流媒體系統(tǒng)在實(shí)際的應(yīng)用部署特別是移動(dòng)互聯(lián)網(wǎng)應(yīng)用中仍然遇到了不少問(wèn)題,主要體現(xiàn)在:

  1. 與Web服務(wù)器相比,流媒體服務(wù)器的安裝、配置和維護(hù)都較為復(fù)雜,特別是對(duì)于已經(jīng)建有CDN(內(nèi)容分發(fā)網(wǎng)絡(luò))等基礎(chǔ)設(shè)施的運(yùn)營(yíng)商來(lái)說(shuō),重新安裝配置支持RTSP/RTP的流媒體服務(wù)器工作量很大。

  2. RTSP/RTP協(xié)議棧的邏輯實(shí)現(xiàn)較為復(fù)雜,與HTTP相比支持RTSP/RTP的客戶端軟硬件實(shí)現(xiàn)難度較大,特別是對(duì)于嵌入式終端來(lái)說(shuō)。

  3. RTSP協(xié)議使用的網(wǎng)絡(luò)端口號(hào)(554)可能被部分用戶網(wǎng)絡(luò)中的防火墻和NAT等封堵,導(dǎo)致無(wú)法使用。雖然有些流媒體服務(wù)器可通過(guò)隧道方式將RTSP配置在HTTP的80端口上承載,但實(shí)際部署起來(lái)并不是特別方便。

蘋(píng)果公司的HTTP Live Streaming正是為了解決這些問(wèn)題應(yīng)運(yùn)而生的,其主要特點(diǎn)是:放棄專門(mé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)終端)軟件的開(kāi)發(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é)議的綜合比較見(jiàn)表所示。


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ì)比分析??傮w來(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)用,但需要專門(mén)流媒體服務(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)用。



文/RiderOnTheWheel(簡(jiǎn)書(shū)作者)
原文鏈接:http://www.jianshu.com/p/5b0fa403b3ce
著作權(quán)歸作者所有,轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),并標(biāo)注“簡(jiǎn)書(shū)作者”。
本站僅提供存儲(chǔ)服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請(qǐng)點(diǎn)擊舉報(bào)
打開(kāi)APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
基于RTSP協(xié)議流媒體服務(wù)器的實(shí)現(xiàn)_維金商務(wù)資訊:中國(guó)時(shí)代財(cái)富
流媒體的真面目
rtsp rtmp http 比較
rtsp流媒體服務(wù)器的搭建
網(wǎng)絡(luò)流媒體協(xié)議之——RTSP協(xié)議
實(shí)時(shí)流煤體協(xié)議概述
更多類似文章 >>
生活服務(wù)
熱點(diǎn)新聞
分享 收藏 導(dǎo)長(zhǎng)圖 關(guān)注 下載文章
綁定賬號(hào)成功
后續(xù)可登錄賬號(hào)暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點(diǎn)擊這里聯(lián)系客服!

聯(lián)系客服