八、流媒體  

  從這篇開始我們將進入流媒體的環節，流媒體在android中有nuplayer來實現的，在開始講解android流媒體前，我們先來講講流媒體傳輸協議，瞭解了基本協議，我們在看程式碼的過程中，就會有事半功倍的效果。我們將主要講解RTSP，HTTP,HTTPS, SDP四種協議。

一：RTSP協議簡介
　　實時流協議RTSP是一個應用層協議，用於控制具有實時特性的資料（例如多媒體流）的傳送。

RTSP協議一般與RTP/RTCP和RSVP等底層協議一起協同工作，提供基於Internet的整套的流服務。它可以選擇傳送通道（例如：UDP、組播UDP和TCP）和基於RTP的傳送機制。它可以應用於組播和點播。RTP, RTCP,RSVP 定義如下：

1. 實時傳輸協議RTP(Real-time Transport protocol)

　　2. 實時傳輸控制協議RTCP(Real-time Transport Control protocol)

　　3. 實時流協議RTSP(Real Time Streaming protocol)

　　4. 資源預留協議RSVP(Resource Reserve Protocol)

RTSP協議機理：

客戶機在向視訊伺服器請求視訊服務之前，首先通過HTTP協議從Web伺服器獲取所請求視訊服務的演示描述（Presentation description ）檔案，在RTSP中，每個演示（Presentation）及其所對應的媒體流都由一個RTSP URL標識。整個演示及媒體特性都在一個演示描述（Presentation description ）檔案中定義，該檔案可能包括媒體編碼方式、語言、RTSP URLs、目標地址、埠及其它引數。使用者在向伺服器請求某個連續媒體流的服務之前，必須首先從伺服器獲得該媒體流的演示描述（Presentation description ）檔案以得到必需的引數，演示描述檔案的獲取可採用HTTP、email或其他方法。利用該檔案提供的資訊定位視訊服務地址

（包括視訊伺服器地址和埠號）及視訊服務的編碼方式等資訊。然後客戶機根據上述資訊向視訊伺服器請求視訊服務。視訊服務初始化完畢，視訊伺服器為該客戶建立一個新的視訊服務流，客戶端與伺服器執行實時流控制協議RTSP，以對該流進行各種VCR控制訊號的交換，如播放（PLAY）、停止（PAUSE）、快進、快退等。當服務完畢，客戶端提出拆線（TEARDOWN）請求。伺服器使用RTP/UDP協議將媒體資料傳輸給客戶端，一旦資料抵達客戶端，客戶端應用程式即可播放輸出。在流式傳輸中，使用RTP/RTCP/UDP和RTSP/TCP兩種不同的通訊協議在客戶端和伺服器間建立聯絡。如下圖：

RTSP中的所有的操作都是通過伺服器和客戶方的訊息應答來完成的，其訊息包括請求（Request）和響應（Response）兩種，RTSP正是通過伺服器和客戶端的訊息應答來完成媒體流的建立、初始化（SETUP）、VCR控制（PLAY、PAUSE）以及拆線（TEARDOWN）等操作的。如下圖：

RSTP 一些基本方法及用途：

OPTIONS獲得有效方法

SETUP建立傳輸

ANNOUNCE 改變媒體檔案的型別

DESCRIBE 獲得媒體檔案的型別

PLAY播放

RECORD 燒錄

REDIRECT轉換客戶端到新的伺服器

PAUSE    暫停

SET PARAMETER 設定裝置，編碼等引數

TEARDOWN 移除狀態

完整的播放過程：

GET 過程：

C->W: GET /twister.sdp HTTP/1.1

Host: www.example.com

Accept: application/sdp

W->C: HTTP/1.0 200 OK

Content-Type: application/sdp

v=0

o=- 2890844526 2890842807 IN IP4 192.16.24.202

s=RTSP Session

m=audio 0 RTP/AVP 0

a=control:rtsp://audio.com/twister/audio.en

m=video 0 RTP/AVP 31

a=control:rtsp://video.com/twister/video

SETUP過程：

C->A（audio）: SETUP rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 1

Transport: RTP/AVP/UDP;unicast

;client_port=3056-3057

A->C: RTSP/1.0 200 OK

CSeq: 1

Session: 12345678

Transport: RTP/AVP/UDP;unicast

;client_port=3056-3057;

;server_port=5000-5001

C->V（video）: SETUP rtsp://video.com/twister/video RTSP/1.0

CSeq: 1

Transport: RTP/AVP/UDP;unicast

;client_port=3058-3059

V->C: RTSP/1.0 200 OK

CSeq: 1

Session: 23456789

Transport: RTP/AVP/UDP;unicast

;client_port=3058-3059

;server_port=5002-5003

PLAY 過程：

C->V: PLAY rtsp://video.com/twister/video RTSP/1.0

CSeq: 2

Session: 23456789

Range: smpte=0:10:00-

V->C: RTSP/1.0 200 OK

CSeq: 2

Session: 23456789

Range: smpte=0:10:00-0:20:00

RTP-Info: url=rtsp://video.com/twister/video

;seq=12312232;rtptime=78712811

C->A: PLAY rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 2

Session: 12345678

Range: smpte=0:10:00-

A->C: RTSP/1.0 200 OK

CSeq: 2

Session: 12345678

Range: smpte=0:10:00-0:20:00

RTP-Info: url=rtsp://audio.com/twister/audio.en

;seq=876655;rtptime=1032181close 過程：

C->A: TEARDOWN rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 3

Session: 12345678

A->C: RTSP/1.0 200 OK

CSeq: 3

C->V: TEARDOWN rtsp://video.com/twister/video RTSP/1.0

CSeq: 3

Session: 23456789

V->C: RTSP/1.0 200 OK

CSeq: 3

關於RTSP的一些時間概念：

normal play time (NPT): seconds, microseconds

MPTE timestamps (seconds, frames)

absolute time (for live events)

 二　HTTP協議簡介

　　HTTP是一個屬於應用層的面向物件的協議，由於其簡捷、快速的方式，適用於分散式超媒體資訊系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴充套件。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。

1：HTTP協議的主要特點可概括如下：

　　1.支援客戶/伺服器模式。

　　2.簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。

　　由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。

　　3.靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。

　　4.無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。

　　5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

2：HTTP協議的幾個重要概念

　　1.連線(Connection)：一個傳輸層的實際環流，它是建立在兩個相互通訊的應用程式之間。

　　2.訊息(Message)：HTTP通訊的基本單位，包括一個結構化的八元組序列並通過連線傳輸。

　　3.請求(Request)：一個從客戶端到伺服器的請求資訊包括應用於資源的方法、資源的識別符號和協議的版本號

　　4.響應(Response)：一個從伺服器返回的資訊包括HTTP協議的版本號、請求的狀態(例如“成功”或“沒找到”)和文件的MIME型別。

　　5.資源(Resource)：由URI標識的網路資料物件或服務。

　　6.實體(Entity)：資料資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應資訊中。一個實體包括實體頭資訊和實體的本身內容。

　　7.客戶機(Client)：一個為傳送請求目的而建立連線的應用程式。

　　8.使用者代理(User agent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它使用者工具。

　　9.伺服器(Server)：一個接受連線並對請求返回資訊的應用程式。

　　10.源伺服器(Origin server)：是一個給定資源可以在其上駐留或被建立的伺服器。

　　11.代理(Proxy)：一箇中間程式，它可以充當一個伺服器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的伺服器中。一個代理在傳送請求資訊之前，必須解釋並且如果可能重寫它。

　　代理經常作為通過防火牆的客戶機端的門戶，代理還可以作為一個幫助應用來通過協議處理沒有被使用者代理完成的請求。

　　12.閘道器(Gateway)：一個作為其它伺服器中間媒介的伺服器。與代理不同的是，閘道器接受請求就好象對被請求的資源來說它就是源伺服器；發出請求的客戶機並沒有意識到它在同閘道器打交道。
　　閘道器經常作為通過防火牆的伺服器端的門戶，閘道器還可以作為一個協議翻譯器以便存取那些儲存在非HTTP系統中的資源。

　　13.通道(Tunnel)：是作為兩個連線中繼的中介程式。一旦啟用，通道便被認為不屬於HTTP通訊，儘管通道可能是被一個HTTP請求初始化的。當被中繼的連線兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。

　　14.快取(Cache)：反應資訊的局域儲存。

3：建立連線的方式

HTTP支援2中建立連線的方式：非持久連線和持久連線(HTTP1.1預設的連線方式為持久連線)。

1) 非持久連線

讓我們檢視一下非持久連線情況下從伺服器到客戶傳送一個Web頁面的步驟。假設該貝面由1個基本HTML檔案和10個JPEG影象構成，而且所有這些物件都存放在同一臺伺服器主機中。再假設該基本HTML檔案的URL為：gpcuster.cnblogs.com/index.html。

下面是具體步騾:

1.HTTP客戶初始化一個與伺服器主機gpcuster.cnblogs.com中的HTTP伺服器的TCP連線。HTTP伺服器使用預設埠號80監聽來自HTTP客戶的連線建立請求。

2.HTTP客戶經由與TCP連線相關聯的本地套接字發出—個HTTP請求訊息。這個訊息中包含路徑名/somepath/index.html。

3.HTTP伺服器經由與TCP連線相關聯的本地套接字接收這個請求訊息，再從伺服器主機的記憶體或硬碟中取出物件/somepath/index.html，經由同一個套接字發出包含該物件的響應訊息。

4.HTTP伺服器告知TCP關閉這個TCP連線(不過TCP要到客戶收到剛才這個響應訊息之後才會真正終止這個連線)。

5.HTTP客戶經由同一個套接字接收這個響應訊息。TCP連線隨後終止。該訊息標明所封裝的物件是一個HTML檔案。客戶從中取出這個檔案，加以分析後發現其中有10個JPEG物件的引用。

6.給每一個引用到的JPEG物件重複步騾1-4。

上述步驟之所以稱為使用非持久連線，原因是每次伺服器發出一個物件後，相應的TCP連線就被關閉，也就是說每個連線都沒有持續到可用於傳送其他物件。每個TCP連線只用於傳輸一個請求訊息和一個響應訊息。就上述例子而言，使用者每請求一次那個web頁面，就產生11個TCP連線。

2) 持久連線

非持久連線有些缺點。首先，客戶得為每個待請求的物件建立並維護一個新的連線。對於每個這樣的連線，TCP得在客戶端和伺服器端分配TCP緩衝區，並維持TCP變數。對於有可能同時為來自數百個不同客戶的請求提供服務的web伺服器來說，這會嚴重增加其負擔。其次，如前所述，每個物件都有2個RTT的響應延長——一個RTT用於建立TCP連線，另—個RTT用於請求和接收物件。最後，每個物件都遭受TCP緩啟動，因為每個TCP連線都起始於緩啟動階段。不過並行TCP連線的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。

在持久連線情況下，伺服器在發出響應後讓TCP連線繼續開啟著。同一對客戶/伺服器之間的後續請求和響應可以通過這個連線傳送。整個Web頁面(上例中為包含一個基本HTMLL檔案和10個影象的頁面)自不用說可以通過單個持久TCP連線傳送:甚至存放在同一個伺服器中的多個web頁面也可以通過單個持久TCP連線傳送。通常，HTTP伺服器在某個連線閒置一段特定時間後關閉它，而這段時間通常是可以配置的。持久連線分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那麼客戶只在收到前一個請求的響應後才發出新的請求。這種情況下，web頁面所引用的每個物件(上例中的10個影象)都經歷1個RTT的延遲，用於請求和接收該物件。與非持久連線2個RTT的延遲相比，不帶流水線的持久連線已有所改善，不過帶流水線的持久連線還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，伺服器送出一個物件後開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間伺服器資源便閒置了。

HTTP/1.1的預設模式使用帶流水線的持久連線。這種情況下，HTTP客戶每碰到一個引用就立即發出一個請求，因而HTTP客戶可以一個接一個緊挨著發出各個引用物件的請求。伺服器收到這些請求後，也可以一個接一個緊挨著發出各個物件。如果所有的請求和響應都是緊挨著傳送的，那麼所有引用到的物件一共只經歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的物件都各有1個RTT的延遲)。另外，帶流水線的持久連線中伺服器空等請求的時間比較少。與非持久連線相比，持久連線(不論是否帶流水線)除降低了1個RTT的響應延遲外，緩啟動延遲也比較小。其原因在於既然各個物件使用同一個TCP連線，伺服器發出第一個物件後就不必再以一開始的緩慢速率傳送後續物件。相反，伺服器可以按照第一個物件傳送完畢時的速率開始傳送下一個物件。

4： 快取的機制

HTTP/1.1中快取的目的是為了在很多情況下減少傳送請求，同時在許多情況下可以不需要傳送完整響應。前者減少了網路迴路的數量；HTTP利用一個“過期（expiration）”機制來為此目的。後者減少了網路應用的頻寬；HTTP用“驗證（validation）”機制來為此目的。具體可以參考：

三 RTSP協議與HTTP協議的聯絡與區別RTSP協議負責在伺服器和客戶端之間建立並控制一個或多個時間上同步的連續流媒體，其目標是象HTTP協議為使用者提供文字和圖形服務那樣為使用者提供連續媒體服務。因此，RTSP協議的設計在語法和操作上與HTTP協議很相似，這樣，對於HTTP的大部分擴充套件也適用於RTSP。
　　但是RTSP協議和HTTP協議在很多方面有著區別：
　　1. HTTP是一個無狀態協議，而RTSP協議是有狀態的。
　　2. HTTP本質上是一個非對稱協議，客戶端提出請求而伺服器響應；而RTSP是對稱的，伺服器和客戶端都可傳送和響應請求。

四 HTTPS傳輸協議

   HTTPS（Secure Hypertext Transfer Protocol）安全超文字傳輸協議，它是一個安全通訊通道，它基於HTTP開發，用於在客戶計算機和伺服器之間交換資訊。它使用安全套接字層(SSL)進行資訊交換，簡單來說它是HTTP的安全版。
它是由Netscape開發並內置於其瀏覽器中，用於對資料進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是象HTTP那樣使用埠80來和TCP/IP進行通訊。）SSL使用40 位關鍵字作為RC4流加密演算法，這對於商業資訊的加密是合適的。HTTPS和SSL支援使用X.509數字認證，如果需要的話使用者可以確認傳送者是誰。

HTTPS和HTTP的區別：

1：http和https使用的是完全不同的連線方式,用的埠也不一樣,前者是80,後者是443。
2：https協議需要到ca申請證書，一般免費證書很少，需要交費。
3：http是超文字傳輸協議，資訊是明文傳輸，https 則是具有安全性的ssl加密傳輸協議
4：http的連線很簡單,是無狀態的，而HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比http協議安全

HTTPS解決的問題：
1 . 信任主機的問題. 採用https 的server 必須從CA 申請一個用於證明伺服器用途型別的證書. 改證書只有用於對應的server 的時候,客戶度才信任次主機. 所以目前所有的銀行系統網站,關鍵部分應用都是https 的. 客戶通過信任該證書,從而信任了該主機. 其實這樣做效率很低,但是銀行更側重安全. 這一點對我們沒有任何意義,我們的server ,採用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.
2 . 通訊過程中的資料的洩密和被竄改
1. 一般意義上的https, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點一樣.
b) 服務端和客戶端之間的所有通訊,都是加密的.
i. 具體講,是客戶端產生一個對稱的金鑰,通過server 的證書來交換金鑰. 一般意義上的握手過程.
ii. 加下來所有的資訊往來就都是加密的. 第三方即使截獲,也沒有任何意義.因為他沒有金鑰. 當然竄改也就沒有什麼意義了.
2. 少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.
a) 這裡客戶端證書,其實就類似表示個人資訊的時候,除了使用者名稱/密碼, 還有一個CA 認證過的身份. 應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.
b) 目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體.
HTTPS 一定是繁瑣的.
a) 本來簡單的http協議,一個get一個response. 由於https 要還金鑰和確認加密演算法的需要.單握手就需要6/7 個往返.
i. 任何應用中,過多的round trip 肯定影響效能.
b) 接下來才是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容做加密/解密.
i. 儘管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 晶片. 如果CPU 信能比較低的話,肯定會降低效能,從而不能serve 更多的請求.
ii. 加密後資料量的影響. 所以，才會出現那麼多的安全認證提示。

五 SDP協議

SDP會話描述協議：為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。會話目錄用於協助多媒體會議的通告，併為會話參與者傳送相關設定資訊。 SDP 即用於將這種資訊傳輸到接收端。 SDP 完全是一種會話描述格式――它不屬於傳輸協議 ――它只使用不同的適當的傳輸協議，包括會話通知協議 （SAP） 、會話初始協議（SIP）、實時流協議 （RTSP）、 MIME 擴充套件協議的電子郵件以及超文字傳輸協議 （HTTP）。SDP 的設計宗旨是通用性，它可以應用於大範圍的網路環境和應用程式，而不僅僅侷限於組播會話目錄。

SDP是會話描述協議的縮寫，是描述流媒體初始化引數的格式，由IETF作為RFC 4566頒佈。流媒體是指在傳輸過程中看到或聽到的內容，SDP包通常包括以下資訊：

（1）會話資訊· 會話名和目的

  · 會話活動時間

     由於參與會話的資源是受限制的，因此包括以下附加資訊是非常有用的

   · 會話使用的頻寬資訊

   　　   · 會話負責人的聯絡資訊

（2）媒體資訊

   · 媒體型別，例如視訊和音訊

   · 傳輸協議，例如RTP/UDP/IP和H.320。

· 多播地址和媒體傳輸埠（IP多播會話）

   · 用於聯絡地址的媒體和傳輸埠的遠端地址（IP單播會話）

SDP描述由許多文字行組成，文字行的格式為<型別>=<值>，<型別>是一個字母，<值>是結構化的文字串，其格式依<型別>而定。

SDP格式（帶*為可選）:

       Session description

          v=   (protocol version) //該行指示協議的版本

          o=   (owner/creator and session identifier)

例如：o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4   //o行中包含與會話所有者有關的引數（1：第一個引數表明會話發起者的名稱，該引數可不填寫，如填寫和SIP訊息中，from訊息頭的內容一致:2：第二個引數為主叫方的會話識別符號:3：第三個引數為主叫方會話的版本，會話資料有改變時，版本號遞增:4：第四個引數定義了網路型別，IN表示Internet網路型別，目前僅定義該網路型別:5：第五個引數為地址型別，目前支援IPV4和IPV6兩種地址型別:6：第六個引數為地址：表明會話發起者的IP地址，該地址為信令面的IP地址，信令PDP啟用時為手機分配。）

          s=   (session name) //表明本次會話的標題，或會話的名稱

          i=* (session information)

          u=* (URI of description)

          e=* (email address)

          p=* (phone number)

          c=* (connection information - not required if included in all media)

          b=* (zero or more bandwidth information lines)

          One or more time descriptions ("t=" and "r=" lines, see below)

          z=* (time zone adjustments)

          k=* (encryption key)

          a=* (zero or more session attribute lines)

          Zero or more media descriptions

       Time description

          t=   (time the session is active)

          r=* (zero or more repeat times)

       Media description, if present

          m=   (media name and transport address)

例如： m=audio 3458  RTP/AVP  0   96   97   // m行又稱媒體行，描述了傳送方所支援的媒體型別等資訊（1： 第一個引數為媒體名稱：表明支援音訊型別。2： 第二個引數為埠號，表明UE在本地埠為3458上傳送音訊流。3： 第三個引數為傳輸協議，一般為RTP/AVP協議。4：四-七引數為所支援的四種淨荷型別編號）

m=video 3400 RTP/AVP 98  99 //m行又稱媒體行，描述了傳送方所支援的媒體型別等資訊

          i=* (media title)

c=* (connection information - optional if included at

               session-level)

          b=* (zero or more bandwidth information lines)

          k=* (encryption key)

          a=* (zero or more media attribute lines)

九：流媒體框架   

android流媒體框架是從Gingerbread android2.3的時候加入的，其核心就是nuplayer。android 流媒體在4.1上資原始檔主要分為httplivesource，rtspsource,genericsource.genericsource是4.1上加入的。其中Rtsp流和httplive流是最主要的，兩者有本質的區別。

RTSP source是客戶機在向視訊伺服器請求視訊服務之前，

首先通過HTTP協議從Web伺服器獲取所請求視訊服務的演示描述（Presentation description ）檔案，在RTSP中，每個演示（Presentation）及其所對應的媒體流都由一個RTSPURL標識。整個演示及媒體特性都在一個演示描述（Presentation description ）檔案中定義，該檔案可能包括媒體編碼方式、語言、RTSP URLs、目標地址、埠及其它引數。使用者在向伺服器請求某個連續媒體流的服務之前，必須首先從伺服器獲得該媒體流的演示描述（Presentationdescription ）檔案以得到必需的引數，演示描述檔案的獲取可採用HTTP、email或其他方法。利用該檔案提供的資訊定位視訊服務地址（包括視訊伺服器地址和埠號）及視訊服務的編碼方式等資訊。

然後客戶機根據上述資訊向視訊伺服器請求視訊服務。視訊服務初始化完畢，視訊伺服器為該客戶建立一個新的視訊服務流，客戶端與伺服器執行實時流控制協議RTSP，以對該流進行各種VCR控制訊號的交換，如播放（PLAY）、停止（PAUSE）、快進、快退等。當服務完畢，客戶端提出拆線（TEARDOWN）請求。伺服器使用RTP/UDP協議將媒體資料傳輸給客戶端，一旦資料抵達客戶端，客戶端應用程式即可播放輸出。在流式傳輸中，使用RTP/RTCP/UDP和RTSP/TCP兩種不同的通訊協議在客戶端和伺服器間建立聯絡。總體框架如下圖：

HTTP LiveStreaming（縮寫是 HLS）是一個由蘋果公司提出的基於HTTP的流媒體 網路傳輸協議。是蘋果公司QuickTime X和iPhone軟體系統的一部分。它的工作原理是把整個流分成一個個小的基於HTTP的檔案來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的資料速率。在開始一個流媒體會話時，客戶端會下載一個包含元資料的extended M3U (m3u8) playlist檔案，用於尋找可用的媒體流。該視訊格式為.m3u8。Httplive在android上總體框架如下圖：