生活随笔
收集整理的這篇文章主要介紹了
流媒体知识点
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
視頻幀：
在MPEG編碼的過程中，部分視頻幀序列壓縮成為I幀，部分壓縮成P幀，還有部分壓縮成B幀。I幀法是幀內壓縮法，也稱為“關鍵幀”壓縮法。 兩個I幀之間的長度就是一個GOP的長度。 I幀：又稱Intra-Picture。幀內編碼幀是一種自帶全部信息的獨立幀，無需參考其它圖像便可獨立進行解碼，視頻序列中的第一個幀始終都是I幀。I幀通常是每個GOP的第一個幀，經過適度的壓縮，可以當成圖像。I幀實際上就是完整的圖像經過壓縮后的數據幀。 P幀：又稱Predictive-Picture。稱幀間預測編碼幀，需要參考前面的I幀才能進行編碼。 通過充分的降低圖象序列中前面已編碼幀的時間冗余信息 來壓縮傳輸數據量的編碼圖像，也叫前向預測幀。這個幀不能單獨作為圖像進行觀看，其不能成為完整的一張圖，需要參考前面一張I幀或B幀來形成完整圖。 B幀： 又稱Bi-directional interpolated prediction frame。 既考慮與源圖像序列前面已編碼幀，也顧及源圖像序列后面已編碼幀之間的時間冗余信息 來壓縮傳輸數據量的編碼圖像，也叫雙向預測幀，也同樣不能成為完整的一張圖，需要參考前面的I或P幀以及后面的一個P幀來形成一張完整的圖。
常見點播文件格式
FLV、mp4、TS。
FLV（FLASH VIDEO）：
FLV是流媒體格式的一種，FLV是一個二進制文件，FLV封裝格式是由一個文件頭(flie header)和 文件體(file Body)組成。。 Flv body是由很多tag組成，tag又分成三種類型：audio,video,script，分別代表音頻流，視頻流，腳本流（關鍵字或者文件信息之類）。 FLV文件=FLV頭文件+ tag1+tag內容1 + tag2+tag內容2 + …+… + tagN+tag內容N FLV包括文件頭（File Header）和文件體（File Body）兩部分： FLV tags結構：| TagType(8) | DataSize(24) | Timestamp(24) |TimestampExtended(8) | StreamID(24) | Data(DataSize) |。 當前幀時戳，單位是毫秒。相對于FLV文件的第一個TAG時戳。第一個tag的時戳總是0。——不是時戳增量，rtmp中是時戳增量。 Metadata Tag：該類型Tag又通常被稱為Script Tag Data。會放一些關于FLV視頻和音頻的參數信息，如duration、width、height等。通常該類型Tag會跟在File Header后面作為第一個Tag出現，而且只有一個。該Tag Data結構包含兩個AMF包。AMF（Action Message Format）是Adobe設計的一種通用數據封裝格式，在Adobe的很多產品中應用，簡單來說，AMF將不同類型的數據用統一的格式來描述。第一個AMF包封裝字符串類型數據，用來裝入一個“onMetaData”標志，這個標志與Adobe的一些API調用有，在此不細述。第二個AMF包封裝一個數組類型，這個數組中包含了音視頻信息項的名稱和值。 如回包的content-length不加，則持續回包即直播
MP4：
mp4或稱[MPEG-4]第14部分（MPEG-4 Part 14）是一種多媒體容器格式。
TS：
MPEG-2中規定TS傳輸包的長度是固定的，長度為188字節。 所有的TS包都分為包頭和凈荷部分。 包頭：提供關于傳輸方面的信息：同步、有無差錯、有無加擾、PCR（節目參考時鐘）等標志。 凈荷：所傳輸的信息包括兩種類型：視頻、音頻的PES包以及輔助數據；節目專用信息PSI。分為三層：ts層（Transport Stream）、pes層（Packet Elemental Stream）、es層（Elementary Stream）。 es層：就是音視頻數據 pes層：是在音視頻數據上加了時間戳等對數據幀的說明信息 ts層：是在pes層上加入了數據流識別和傳輸的必要信息。
TS形成過程：
將原始音視頻數據壓縮之后，壓縮結果組成一個基本碼流（ES） 對ES（基本碼流）進行打包形成PES 在PES包中加入時間戳信息(PTS/DTS)。 DTS（Decoding Time Stamp）解碼時間和PTS（Presentation Time Stamp）顯示時間。 將PES包內容分配到一系列固定長度的傳輸包（TS Packet）中 在傳輸包中加入定時信息(PCR)。在傳輸包中加入節目專用信息(PSI)。 其中PSI表有4種類型：節目關聯表（PAT）、節目映射表（PMT）、網絡信息表（NIT）和條件訪問表（CAT） 連續輸出傳輸包形成具有恒定比特率的MPEG-TS流
常用直播協議總結
RTMP：
RealTime Messaging Protocol，實時消息傳送協議。工作在TCP之上的明文協議，使用端口1935。傳送的協議，負載的是flv格式的文件。 RTMPT封裝在HTTP請求之中，可穿越防火墻。RTMPS類似RTMPT，但使用的是HTTPS連接。 消息是rtmp的基本數據單元，塊是用于將消息重新封裝在網絡上傳輸。
消息：
是rtmp的基本數據單元，服務端和客戶端通過在網絡上發送RTMP消息進行通訊。消息可能包含音頻，視頻，數據，或其他的消息。RTMP消息，分為消息頭和載荷兩部分。 消息頭：message type、payload length、timestamp、stream id。 載荷：載荷中消息中包含的真實數據。例如，它可以是音頻樣本或壓縮的視頻數據。
chunk：
chunk（消息組成）：消息是rtmp協議的基本數據單元，在網絡傳輸時，消息會被重新封裝成塊進行傳輸，每個塊都有固定的大小，如果消息大小大于塊的大小，消息就會被拆分成幾個塊發送。塊由塊頭和載荷組成。 載荷：塊的載荷就是消息的載荷內容。
rtmp的消息類型：
rtmp的消息類型可分為三大類：協議控制消息、用戶控制消息、RTMP命令消息 協議控制消息：設置塊大小消息（Message Type=1）、終止消息（Message Type=2）、確認消息（Message Type=3）、確認窗口大小消息（Message Type=5）、設置對端帶寬消息（Message Type=6） 用戶控制消息：用戶控制消息（Message Type=4） RTMP命令消息：數據消息（Message Type=18或15）、共享對象消息 (Message Type=19或16)、音頻消息 (Message Type=8)、視頻消息 (Message Type=9)、聚合消息（Message Type=22）、命令消息（Message Type=20或17）
HDL：
HTTP+FLV將RTMP封裝在HTTP協議之上的，可以更好的穿透防火墻等。 FLV是最簡單的流媒體封裝，HTTP是最廣泛的協議，這兩個組合在一起維護性更高，比RTMP簡單多了。 HTTP協議中有個約定：content-length字段，http的body部分的長度。服務器回復http請求的時候如果有這個字段，客戶端就接收這個長度的數據然后就認為數據傳輸完成了。如果服務器回復http請求中沒有這個字段，客戶端就一直接收數據，直到服務器跟客戶端的socket連接斷開。 http-flv直播就是利用第二個原理，服務器回復客戶端請求的時候不加content-length字段，在回復了http內容之后，緊接著發送flv數據，客戶端就一直接收數據了。
HLS：
HTTP Live Streaming，是一個由蘋果公司提出的基于HTTP的流媒體網絡傳輸協議。 它的工作原理是把整個流分成一個個小的基于HTTP的文件來下載，每次只下載一些。當媒體流正在播放時，客戶端可以選擇從許多不同的備用源中以不同的速率下載同樣的資源，允許流媒體會話適應不同的數據速率。 在開始一個流媒體會話時，客戶端會下載一個包含元數據的extended M3U (m3u8)playlist文件，用于尋找可用的媒體流。視頻的封裝格式是TS。 在stream segmenter模塊將視頻切片，切片的結果就是index file（m3u8）和ts文件了。 hls最大的優點HTML5可以直接打開播放；這個意味著可以把一個直播鏈接通過微信等轉發裝任何獨立的APP，有瀏覽器即可。
優勢：
主要是為了解決RTMP協議存在的一些問題。比如RTMP協議不使用標準的HTTP接口傳輸數據，所以在一些特殊的網絡環境下可能被防火墻屏蔽掉。但是HLS由于使用的HTTP協議傳輸數據，不會遇到被防火墻屏蔽的情況（該不會有防火墻連80接口都不放過吧）。 另外于負載，RTMP是一種有狀態協議，很難對視頻服務器進行平滑擴展，因為需要為每一個播放視頻流的客戶端維護狀態。而HLS基于無狀態協議（HTTP），客戶端只是按照順序使用下載存儲在服務器的普通TS文件，做負責均衡如同普通的HTTP文件服務器的負載均衡一樣簡單。 另外HLS協議本身實現了碼率自適應，不同帶寬的設備可以自動切換到最適合自己碼率的視頻播放。
播放模式：
點播VOD的特點就是當前時間點可以獲取到所有index文件和ts文件，二級index文件中記錄了所有ts文件的地址。這種模式允許客戶端訪問全部內容。上面的例子中就是一個點播模式下的m3u8的結構。 Live 模式就是實時生成M3u8和ts文件。它的索引文件一直處于動態變化的，播放的時候需要不斷下載二級index文件，以獲得最新生成的ts文件播放視頻。如果一個二級index文件的末尾沒有#EXT-X-ENDLIST標志，說明它是一個Live視頻流。 客戶端在播放VOD模式的視頻時其實只需要下載一次一級index文件和二級index文件就可以得到所有ts文件的下載地址，除非客戶端進行比特率切換，否則無需再下載任何index文件，只需順序下載ts文件并播放就可以了。但是Live模式下略有不同，因為播放的同時，新ts文件也在被生成中，所以客戶端實際上是下載一次二級index文件，然后下載ts文件，再下載二級index文件（這個時候這個二級index文件已經被重寫，記錄了新生成的ts文件的下載地址）,再下載新ts文件，如此反復進行播放。
HDS：
Http Dynamic Streaming，是一個由Adobe公司模仿HLS協議提出的另一個基于Http的流媒體傳輸協議。 其模式跟HLS類似，但是又要比HLS協議復雜一些，也是索引文件和媒體切片文件結合的下載方式。 多碼率適應場景
DASH：
Dynamic Adaptive Streaming over HTTP。 DASH協議原理跟HLS協議差不多，都是將文件分成一片片小段進行分發，也是分為MPD索引文件和媒體分片文件。 多碼率適應場景
QUCI：
Quick UDP Internet Connection。 是谷歌制定的一種基于UDP的低時延的互聯網傳輸層協議。 QUIC很好地解決了當今傳輸層和應用層面臨的各種需求，包括處理更多的連接，安全性，和低延遲。 QUIC融合了包括TCP，TLS，HTTP/2等協議的特性，但基于UDP傳輸。 QUIC的一個主要目標就是減少連接延遲，當客戶端第一次連接服務器時，QUIC只需要1RTT（Round-Trip Time）的延遲就可以建立可靠安全的連接，相對于TCP+TLS的1-3次RTT要更加快捷。 針對金山云涉及nginx改造，通過lvs-caddy-nginx，通過caddy代理支持
RTSP：
RealTime Streaming Protocol，實時流傳輸協議。RTSP定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。 適合IPTV應用場景。 RTSP與RTP協議最大卻別，RTSP是一種雙向實時數據傳輸協議，它允許客戶端向服務器端發送請求，如回放、快進、倒退等操作。
RTP：
Real-timeTransport Protocol，實時傳輸協議。RTP是針對多媒體數據流的一種傳輸層協議，詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。 RTP協議常用于流媒體系統（配合RTCP協議），視頻會議和一鍵通系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。 RTP是建立在UDP協議上的，常與RTCP一起使用，其本身并沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴于低層服務去實現這一過程。
RTCP：
Real-timeTransport Control Protocol，實時傳輸控制協議。RTCP是RTP的配套協議，為RTP媒體流提供信道外的控制。
總結
以上是生活随笔 為你收集整理的流媒体知识点 的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔 網站內容還不錯，歡迎將生活随笔 推薦給好友。
