前言

　　耽誤了很久，一直想寫音視頻開發的教程，一方面，音視頻的發展正在向各個行業擴展，從教育的遠程授課，交通的人臉識別，醫療的遠程就醫等，音視頻方向已經占據一個相當重要的位置，而音視頻真正入門的文章又少之甚少，一個剛畢業小白可能很難切入理解,因為音視頻中涉及大量理論知識,而代碼的書寫需要結合這些理論,所以搞懂音視頻,編解碼等理論知識至關重要。另一方面，公司的業務也在逐漸向音視頻靠攏，我需要先將積累的知識點重新梳理后分享給其他同學。

　　整個過程可能會花費較長時間，為了防止大家理解過于空洞，我會將demo上傳到Github，供大家對照學習。 在代碼實現上，我更多會以iOS開發為著重點。

　　如果喜歡,請幫忙點贊并支持轉載,轉載請附原文鏈接.

　　教程概述

　　整個教程在我目前的規劃里面大概分為幾塊：

　　交叉編譯音頻體系iOS音頻開發視頻體系iOS視頻開發直播、短視頻及其他實際應用

　　音視頻基礎知識體系

　　在教程開始之前，我們先了解音視頻技術的基礎知識，當然我更多的是講解有那些知識體系以及如何使用，而不會去詳細講解知識體系的細節或理論基礎，例如我會講解壓縮數據原理，但是不會講解I幀，P幀，B幀具體的編碼。簡而言之，我們將站在巨人肩膀上，而不會去探究巨人是怎樣形成的。

　　1、封裝格式

　　封裝格式也稱多媒體容器，它只是為多媒體編碼提供了一個“外殼”，也就是將所有的處理好的視頻、音頻或字幕都包裝到一個文件容器內呈現給觀眾，這個包裝的過程就叫封裝。

　　

　　常見音視頻的封裝格式.png

　　Tips：封裝格式不影響視頻畫質。它只負責把內部的視頻軌和音頻軌集成在一起，只起到一個文件夾（或者壓縮包）的作用，并沒有對視頻軌和音頻軌造成影響。

　　2、視頻編碼技術

　　視頻編碼就是指通過特定的壓縮技術，將某個視頻格式的文件轉換成另 一種視頻格式文件的方式。視頻傳輸中的編碼標準 1.國際電聯的H.264 2.國際標準化組織運動圖像專家 組的MPEG系列標準 3.微軟公司的WMV 4.Apple公司的 QuickTime 5.google力推的WebM格式常見視頻編碼格式

　　常見視頻編碼格式.png

　　3、音頻編碼技術

　　音頻編碼的主要作用是將音頻采樣數據（PCM等）壓縮成為音頻碼流，從而降低音頻的數據量,偏于存儲和傳輸。

　　描述一段PCM數據一般需要以下幾個概念：

　　采樣率：記錄聲音時每秒的采樣個數，它用赫茲(Hz)來表示。量化格式（采樣精度）：指記錄聲音的動態范圍，它以位(Bit)為單位。聲道數：通道的數目比特率：每秒傳輸的數據量。公式如下：比特率=采樣率 × 采樣深度 × 通道數

　　常見音頻編碼格式有：

　　

　　常見音頻編碼格式.png

　　4、流媒體協議技術

　　流媒體協議是用于傳輸音視頻的協議，包括RTP、RTCP、RTSP、RTMP、HLS等，本文只介紹技術，其中常用的是RTMP協議。

　　RTP(Real-time Transport Protocol)實時傳輸協議 RTP是用于Internet上針對多媒體數據流的一種傳輸協議。建立在UDP協議上的。RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議常用于流媒體系統（配合RTCP協議）、視頻會議。和一鍵通（Push to Talk）系統（配合H.323或SIP），使它成為了IP電話產業的技術基礎。RTCP(Real-time Transport Control Protocol)實時傳輸控制協議 RTCP控制協議需要與RTP數據協議一起配合使用，當應用程序啟動一個RTP會話時將同時占用兩個端口，分別供RTP和RTCP使用。RTP本身并不能為按序傳輸數據包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。 通常RTCP會采用與RTP相同的分發機制，向會話中的所有成員周期性地發送控制信息，應用程序通過接收這些數據，從中獲取會話參與者的相關資料，以及網絡狀況、分組丟失概率等反饋信息，從而能夠對服務質量進行控制或者對網絡狀況進行診斷。RTSP（Real Time Streaming Protocol）實時流協議 RTSP是由Real Network和Netscape共同提出的如何有效地在IP網絡上傳輸流媒體數據的應用層協議。RTSP對流媒體提供了諸如暫停，快進等控制，但它本身并不傳輸數據，RTSP的作用相當于流媒體服務器的遠程控制。服務器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但并不特別強調時間同步，所以比較能容忍網絡延遲。 RTSP之所以特意使用與HTTP/1.1類似的語法和操作，在很大程度上是為了兼容現有的Web基礎結構，正因如此，HTTP/1.1的擴展機制大都可以直接引入到RTSP中。由RTSP控制的媒體流集合可以用表示描述（Presentation Description）來定義，所謂表示是指流媒體服務器提供給客戶機的一個或者多個媒體流的集合，而表示描述則包含了一個表示中各個媒體流的相關信 息，如數據編碼/解碼算法、網絡地址、媒體流的內容等。 雖然RTSP服務器同樣也使用標識符來區別每一流連接會話（Session），但RTSP連接并沒有被綁定到傳輸層連接（如TCP等），也就是說在整個 RTSP連接期間，RTSP用戶可打開或者關閉多個對RTSP服務器的可靠傳輸連接以發出RTSP 請求。此外，RTSP連接也可以基于面向無連接的傳輸協議（如UDP等）。RTMP(Real Time Messaging Protocol)實時消息傳輸協議 RTMP（Real Time Messaging Protocol）是Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議。它有三種變種： （1）工作在TCP之上的明文協議，使用端口1935； （2）RTMPT封裝在HTTP請求之中，可穿越防火墻； （3）RTMPS類似RTMPT，但使用的是HTTPS連接。

　　RTMP視頻播放的特點：

　　（1）RTMP協議是采用實時的流式傳輸，所以不會緩存文件到客戶端，這種特性說明用戶想下載RTMP協議下的視頻是比較難的；

　　（2）視頻流可以隨便拖動，既可以從任意時間點向服務器發送請求進行播放，并不需要視頻有關鍵幀。相比而言，HTTP協議下視頻需要有關鍵幀才可以隨意拖動。

　　（3）RTMP協議支持點播/回放（通俗點將就是支持把flv,f4v,mp4文件放在RTMP服務器，客戶端可以直接播放），直播（邊錄制視頻邊播放）。

　　HLS (HTTP Live Streaming) HTTP Live Streaming(HLS)是蘋果公司實現的基于HTTP的流媒體傳輸協議，可實現流媒體的直播和點播，主要應用于iOS系統。HLS點播是分段HTTP點播，不同在于它的分段非常小。要實現HLS點播，重點在于對媒體文件分段，目前有不少開源工具可以使用。 相對于常見的流媒體直播協議，HLS直播最大的不同在于，直播客戶端獲取到的并不是一個完整的數據流，HLS協議在服務器端將直播數據流存儲為連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載并播放這些小文件，因為服務器總是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。由此可見，基本上可以認為，HLS是以點播的技術方式實現直播。由于數據通過HTTP協議傳輸，所以完全不用考慮防火墻或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高于普通的流媒體直播協議。

　　總結

　　RTSP協議

　　（1）是流媒體協議。

　　（2）RTSP協議是共有協議，并有專門機構做維護。.

　　（3）RTSP協議一般傳輸的是 ts、mp4 格式的流。

　　（4）RTSP傳輸一般需要 2-3 個通道，命令和數據通道分離。

　　（5）常用于安防監控領域

　　RTMP協議

　　（1）是流媒體協議。

　　（2）RTMP協議是 Adobe 的私有協議，未完全公開。

　　（3）RTMP協議一般傳輸的是 flv，f4v 格式流。

　　（4）RTMP一般在 TCP 1個通道上傳輸命令和數據

　　（5）通用，瀏覽器直接可以看，可支持百萬，千萬人同時在線看

　　HLS協議

　　（1）是流媒體協議。

　　（2）蘋果公司開放標準

　　（3）可以穿過任何允許HTTP數據通過的防火墻或者代理服務器

　　（4）IOS上支持完美。Android3.0開始支持。PC/flash上現在也有各種as插件支持

　　5、音視頻原理

　　采集 通過系統API獲取物理攝像頭采集到的視頻數據與麥克風采集到的音頻數據。采集的原始數據類型音頻數據為PCM，視頻數據為YUV或RGB。處理 音頻和視頻原始數據本質都是一大段數據，系統將其包裝進自定義的結構體中，以回調函數形式提供，在我們的項目中需求做一系列特殊處理，如: 視頻的旋轉、縮放、濾鏡、美顏、裁剪等； 音頻的單聲道降噪、消除回聲、靜音等。編碼 原始數據自定義處理后就可以進行傳輸，像直播這樣的功能就是把采集好的視頻數據發送給服務器，以在網頁端供所有粉絲觀看，而傳輸由于本身就是基于網絡環境，龐大的原始數據就必須壓縮后才能帶走，可以理解為我們搬家要將物品都打包到行李箱這樣理解。傳輸 編碼后的音視頻數據通常以RTMP協議進行傳輸，這是一種專門用于傳輸音視頻的協議，因為各種各樣的視頻數據格式無法統一，所以需要有一個標準作為傳輸的規則，協議就起到這樣的作。解碼 服務端接收到編碼數據后，對其解碼成原始數據，因為編碼的數據直接送給物理硬件的設備是不能直接播放的，只有解碼為原始數據才能使用。音視頻同步 解碼后的每幀音視頻中都含有最開始錄制時候設置的時間戳，我們需要根據時間戳將它們正確的播放出來，但是在網絡傳輸中可能會丟失一些數據，或者是延時獲取，這時我們就需要一定的策略去實現音視頻的同步，大體分為幾種策略:緩存一定視頻數據，視頻追音頻等。

　　業務剖析

　　音視頻在互聯網行業的需求實際上簡單歸納為互逆過程的兩個部分：推流和拉流。

　　推流：將手機采集到的視頻數據傳給后臺播放端進行展示，播放端可以是windows、linux、web端，即手機充當采集的功能，將手機攝像頭采集到視頻和麥克風采集到的音頻合成編碼后傳給對應平臺的播放端。

　　推流.jpeg拉流：將播放端傳來的視頻數據在手機上播放，推流的逆過程，即將windows、linux、web端傳來的視頻數據進行解碼后傳給對應音視頻硬件，最終將視頻渲染在手機界面上播放。

　　更多音視頻專題資料獲取 后臺私信【架構】

　　

　　

　　更多c++ linux 免費視頻資料獲取 后臺私信【架構】詳情課程大綱

總結

以上是生活随笔為你收集整理的（零）音视频技术基础知识，现实项目的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。