音頻的基礎知識
1採樣和採樣頻率：
現在是數字時代，在音頻處理時要先把音頻的模擬信號變成數字信號，這叫A/D轉換。要把音頻的模擬信號變成數字信號，就需要採樣。一秒鐘內採樣的次數稱爲採樣頻率
2採樣位數/位寬：
數字信號是用0和1來表示的。採樣位數就是採樣值用多少位0和1來表示，也叫採樣精度，用的位數越多就越接近真實聲音。如用8位表示，採樣值取值範圍就是-128 ~ 127，如用16位表示，採樣值取值範圍就是-32768 ~ 32767。
3聲道（channel）：
通常語音只用一個聲道。而對於音樂來說，既可以是單聲道（mono），也可以是雙聲道（即左聲道右聲道，叫立體聲stereo），還可以是多聲道，叫環繞立體聲
4編解碼：
通常把音頻採樣過程也叫做脈衝編碼調製編碼，即PCM（Pulse Code Modulation）編碼，採樣值也叫PCM值。 如果把採樣值直接保存或者發送，會佔用很大的存儲空間。以16kHz採樣率16位採樣位數單聲道爲例，一秒鐘就有16/8*16000 = 32000字節。爲了節省保存空間或者發送流量，會對PCM值壓縮。
目前主要有三大技術標準組織制定壓縮標準：
1.ITU，主要制定有線語音的壓縮標準（g系列），有g711/g722/g726/g729等。
2.3GPP,主要制定無線語音的壓縮標準（amr系列等）,有amr-nb/amr-wb。後來ITU吸納了amr-wb，形成了g722.2。
3.MPEG,主要制定音樂的壓縮標準，有11172-3，13818-3/7，14496-3等。
一些大公司或者組織也制定壓縮標準，比如iLBC，OPUS。
編碼過程：模擬信號->抽樣->量化->編碼->數字信號
5壓縮:
對於自然界中的音頻信號，如果轉換成數字信號，進行音頻編碼，那麼只能無限接近，不可能百分百還原。所以說實際上任何信號轉換成數字信號都會“有損”。但是在計算機應用中，能夠達到最高保真水平的就是PCM編碼。因此，PCM約定俗成了無損編碼。我們而習慣性的把MP3列入有損音頻編碼範疇，是相對PCM編碼的。強調編碼的相對性的有損和無損
6碼率:
碼率 = 採樣頻率 * 採樣位數 * 聲道個數； 例：採樣頻率44.1KHz，量化位數16bit，立體聲(雙聲道)，未壓縮時的碼率 = 44.1KHz * 16 * 2 = 1411.2Kbps = 176.4KBps，即每秒要錄製的資源大小,理論上碼率和質量成正比
800 bps – 能夠分辨的語音所需最低碼率（需使用專用的FS-1015語音編解碼器）
8 kbps —電話質量（使用語音編碼）
8-500 kbps --Ogg Vorbis和MPEG1 Player1/2/3中使用的有損音頻模式
500 kbps–1.4 Mbps —44.1KHz的無損音頻，解碼器爲FLAC Audio,WavPack或Monkey's Audio
1411.2 - 2822.4 Kbps —脈衝編碼調製(PCM)聲音格式CD光碟的數字音頻
5644.8 kbps —SACD使用的Direct Stream Digital格式
7常用音頻格式
WAV 格式：音質高 無損格式 體積較大
AAC（Advanced Audio Coding） 格式：相對於 mp3，AAC 格式的音質更佳，文件更小，有損壓縮，一般蘋果或者Android SDK4.1.2（API 16）及以上版本支持播放,性價比高
AMR 格式：壓縮比比較大，但相對其他的壓縮格式質量比較差，多用於人聲，通話錄音
mp3 格式：特點 使用廣泛， 有損壓縮，犧牲了12KHz到16KHz高音頻的音質
8音頻開發的主要應用
音頻播放器
錄音機
語音電話
音視頻監控應用
音視頻直播應用
音頻編輯/處理軟件(ktv音效、變聲, 鈴聲轉換)
藍牙耳機/音箱
9音頻開發的具體內容
音頻採集/播放
音頻算法處理（去噪、靜音檢測、回聲消除、音效處理、功放/增強、混音/分離，等等）
音頻的編解碼和格式轉換
音頻傳輸協議的開發（SIP，A2DP、AVRCP，等等）
視頻基礎知識
視頻是一種有結構的數據
內容元素 ( Content )
圖像 ( Image )
音頻 ( Audio )
元信息 ( Metadata )
編碼格式 ( Codec )
Video : H.264，H.265, …
Audio : AAC， HE-AAC, …
容器封裝 (Container)
MP4，MOV，FLV，RM，RMVB，AVI，…
任何一個視頻 Video 文件，從結構上講，都是這樣一種組成方式：
由圖像和音頻構成最基本的內容元素；
圖像經過視頻編碼壓縮格式處理（通常是 H.264）；
音頻經過音頻編碼壓縮格式處理（例如 AAC）；
註明相應的元信息（Metadata）；
最後經過一遍容器（Container）封裝打包（例如 MP4），構成一個完整的視頻文件。
視頻播放流程
視頻的播放流程
色彩空間
RBG:採用R、G、B相加混色的原理，通過發射出三種不同強度的電子束，使屏幕內側覆蓋的紅、綠、藍磷光材料發光而產生色彩。這種色彩的表示方法稱爲RGB色彩空間表示.
編解碼介紹
視頻編碼的主要作用是將視頻像素數據（RGB等）壓縮成爲視頻碼流，從而降低視頻的數據量。如果視頻不經過壓縮編碼的話，體積通常是非常大的，一部電影可能就要上百G的空間。視頻編碼是視音頻技術中最重要的技術之一。視頻碼流的數據量佔了視音頻總數據量的絕大部分。高效率的視頻編碼在同等的碼率下，可以獲得更高的視頻質量。
舉個直播上的栗子：我們知道從 CCD 採集到的圖像格式一般的 RGB 格式的（BMP），這種格式的存儲空間非常大，它是用三個字節描述一個像素的顏色值，如果是 1080P 分辨率的圖像空間：1920 x 1080 x 3 = 6MB，就算轉換成 JPG 也有近 200KB，如果是每秒 12 幀用 JPG 也需要近 2.4MB/S 的帶寬，這帶寬在公網上傳輸是無法接受的。
視頻編碼器就是爲了解決這個問題的，它會根據前後圖像的變化做運動檢測，通過各種壓縮把變化的發送到對方，1080P 進行過 H.264 編碼後帶寬也就在 200KB/S ~ 300KB/S 左右。
我們平時所看到的視頻，理論上就是一幀幀的圖片連續的播放，形成動畫效果。那麼完整的保存所有圖片，所佔用的空間是非常巨大的。視頻編碼就是爲了壓縮這些圖片，以節省空間。我先講一下簡單的理論，比如一秒鐘的視頻通常有24幀，這24張圖畫大部分區域可能都比較相近，那麼我們是不是可以找到一種方法，只保存一張完整圖片（我們稱爲關鍵幀），不保存其他圖片，只保存和這個完整圖片的不同（通過某種數學建模表達），這樣就會節省很多空間，在播放的時候，通過和關鍵幀與每一幀的不同逆向恢復成一張完整的圖片，這樣就得到了24張完整的圖片。（這裏只是舉例，實際應用中並不一定是每24幀圖像被設定一個關鍵幀）。OK，那麼所謂編碼格式就指的一種壓縮視頻圖像的算法。
H.264編碼介紹
H.264是新一代的編碼標準，以高壓縮高質量和支持多種網絡的流媒體傳輸著稱，在編碼方面，它的理論依據是：一段時間內圖像的統計結果表明，在相鄰幾幅圖像畫面中，一般有差別的像素只有10%以內的點，亮度差值變化不超過2%，而色度差值的變化只有1%以內。所以對於一段變化不大的圖像畫面，我們可以先編碼出一個完整的圖像幀A，隨後的B幀不編碼全部圖像，只寫入與A幀的差別，這樣B幀的大小就只有完整幀的1/10或更小！B幀之後的C幀如果變化不大，我們可以繼續以參考B的方式編碼C幀，這樣循環下去。這段圖像我們稱爲一個序列，當某個圖像與之前的圖像變化很大，無法參考前面的幀來生成，那我們就結束上一個序列，開始下一段序列。
I 幀是內部編碼幀（也稱爲關鍵幀），P 幀是前向預測幀（前向參考幀），B 幀是雙向內插幀（雙向參考幀）。簡單地講，I 幀是一個完整的畫面，而 P 幀和 B 幀記錄的是相對於 I 幀的變化。
視頻的實時傳輸(直播)
視頻直播技術，就是將視頻內容的最小顆粒 ( I / P / B 幀，…)，基於時間序列，以高速進行傳送的一種技術。
簡而言之，直播就是將每一幀數據 ( Video / Audio / Data Frame )，打上時序標籤 ( Timestamp ) 後進行流式傳輸的過程。發送端源源不斷的採集音視頻數據，經過編碼、封包、推流，再經過中繼分發網絡進行擴散傳播，播放端再源源不斷地下載數據並按時序進行解碼播放。如此就實現了 “邊生產、邊傳輸、邊消費” 的直播過程。
流媒體協議
RTSP協議
該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。RTSP提供了一個可擴展框架，使實時數據，如音頻與視頻的受控、點播成爲可能。數據源包括現場數據與存儲在剪輯中的數據。該協議目的在於控制多個數據發送連接，爲選擇發送通道，如UDP、多播UDP與TCP提供途徑，併爲選擇基於RTP上發送機制提供方法。
RTMP協議
RTMP是Adobe Systems公司爲Flash播放器和服務器之間音頻、視頻和數據實時傳輸開發的開放協議，因爲是開放協議所以都可以使用。
RTMP協議用於對象、視頻、音頻的傳輸，這個協議建立在TCP協議或者輪詢HTTP協議之上。
RTMP協議就像一個用來裝數據包的容器，這些數據可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網絡流，這些通道中的包都是按照固定大小的包傳輸的。
HLS協議
HTTP Live Streaming（HLS）是蘋果公司(Apple Inc.)實現基於HTTP的流媒體傳輸協議，傳輸內容包括兩部分，一是M3U8描述文件，二是TS媒體文件。可實現流媒體的直播和點播，主要應用在iOS系統，爲iOS設備（如iPhone、iPad）提供音視頻直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不同在於，它的分段非常小。
相對於常見的流媒體直播協議，例如RTMP協議、RTSP協議、MMS協議等，HLS直播最大的不同在於，直播客戶端獲取到的，並不是一個完整的數據流。HLS協議在服務器端將直播數據流存儲爲連續的、很短時長的媒體文件（MPEG-TS格式），而客戶端則不斷的下載並播放這些小文件，因爲服務器端總是會將最新的直播數據生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現了直播。由此可見，基本上可以認爲，HLS是以點播的技術方式來實現直播。由於數據通過HTTP協議傳輸，所以完全不用考慮防火牆或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高於普通的流媒體直播協議。
協議間的比較:
協議比較part1
協議比較part2
FFmpeg
FFmpeg的名稱來自MPEG視頻編碼標準，前面的“FF”代表“Fast Forward”，FFmpeg是一套可以用來記錄、轉換數字音頻、視頻，並能將其轉化爲流的開源計算機程序。可以輕易地實現多種視頻格式之間的相互轉換。
FFmpeg函數庫介紹
libavutil：簡化編程的工具函數庫，包括隨機數生成器，數據結構，數學函數，多媒體核心工具函數等等。
libavcodec：包含音視頻編解碼的庫。
libavformat：包含複用，解複用(封裝格式處理)多媒體容器的庫。
libavdevice：包含輸入/輸出設備的庫，它能從一些通用的軟件框架中抓取數據，也能將多媒體數據送到一些通用軟件框架中去渲染。這些通用軟件框架包括：Video4Linux，Video4Linux2,VfW以及ALSA等。
libavfilter：濾鏡特效處理。
libswscale：用於執行高性能的圖像縮放，顏色空間或像素格式轉換的庫。
libswresample：用於執行高性能音頻重採樣，重矩陣化（rematrixing，不確定翻譯是否準確），採樣格式轉換以及混音（主要是聲道轉換（如5.1聲道轉到立體聲等））等功能的庫。
實現直播整體流程
推流端（採集、美顏處理、編碼、推流）、服務端處理（轉碼、錄製、截圖、鑑黃）、播放器（拉流、解碼、渲染）、互動系統（聊天室、禮物系統、贊）
實現直播的整體架構
關於直播的優化
1. 秒開優化
改寫播放器邏輯讓播放器拿到第一個關鍵幀後就給予顯示。GOP 的第一幀通常都是關鍵幀，由於加載的數據較少，可以達到 “首幀秒開”。如果直播服務器支持 GOP 緩存，意味着播放器在和服務器建立連接後可立即拿到數據，從而省卻跨地域和跨運營商的回源傳輸時間。
GOP 體現了關鍵幀的週期，也就是兩個關鍵幀之間的距離，即一個幀組的最大幀數。假設一個視頻的恆定幀率是 24fps（即1秒24幀圖像），關鍵幀週期爲 2s，那麼一個 GOP 就是 48 張圖像。一般而言，每一秒視頻至少需要使用一個關鍵幀。
增加關鍵幀個數可改善畫質（GOP 通常爲 FPS 的倍數），但是同時增加了帶寬和網絡負載。這意味着，客戶端播放器下載一個 GOP，畢竟該 GOP 存在一定的數據體積，如果播放端網絡不佳，有可能不是能夠快速在秒級以內下載完該 GOP，進而影響觀感體驗。
2. 馬賽克、卡頓
如果 GOP 分組中的P幀丟失會造成解碼端的圖像發生錯誤,其實這個錯誤表現出來的就是馬賽克。因爲中間連續的運動信息丟失了，H.264 在解碼的時候會根據前面的參考幀來補齊，但是補齊的並不是真正的運動變化後的數據，這樣就會出現顏色色差的問題，這就是所謂的馬賽克現象
視頻出現碼賽克
這種現象不是我們想看到的。爲了避免這類問題的發生，一般如果發現 P 幀或者 I 幀丟失，就不顯示本 GOP 內的所有幀，直到下一個 I 幀來後重新刷新圖像。但是 I 幀是按照幀週期來的，需要一個比較長的時間週期，如果在下一個 I 幀來之前不顯示後來的圖像，那麼視頻就靜止不動了，這就是出現了所謂的卡頓現象。如果連續丟失的視頻幀太多造成解碼器無幀可解，也會造成嚴重的卡頓現象。視頻解碼端的卡頓現象和馬賽克現象都是因爲丟幀引起的，最好的辦法就是讓幀儘量不丟。
3. 傳輸協議優化
在服務端節點和節點之間儘量使用 RTMP 而非基於 HTTP 的 HLS 協議進行傳輸，這樣可以降低整體的傳輸延遲。這個主要針對終端用戶使用 HLS 進行播放的情況。
如果終端用戶使用 RTMP 來播放，儘量在靠近推流端的收流節點進行轉碼，這樣傳輸的視頻流比原始視頻流更小。
如果有必要，可以使用定製的 UDP 協議來替換 TCP 協議，省去弱網環節下的丟包重傳可以降低延遲。它的主要缺點在於，基於 UDP 協議進行定製的協議的視頻流的傳輸和分發不夠通用，CDN 廠商支持的是標準的傳輸協議。另一個缺點在於可能出現丟包導致的花屏或者模糊（缺少關鍵幀的解碼參考），這就要求協議定製方在 UDP 基礎之上做好丟包控制。
4. 傳輸網絡優化
在服務端節點中緩存當前 GOP，配合播放器端優化視頻首開時間。
服務端實時記錄每個視頻流流向每個環節時的秒級幀率和碼率，實時監控碼率和幀率的波動。
客戶端（推流和播放）通過查詢服務端準實時獲取當前最優節點（5 秒一次），準實時下線當前故障節點和線路。
5. 推流、播放優化
考察發送端系統自帶的網絡 buffer 大小，系統可能在發送數據之前緩存數據，這個參數的調優也需要找到一個平衡點。
播放端緩存控制對於視頻的首開延遲也有較大影響，如果僅優化首開延遲，可以在 0 緩存情況下在數據到達的時候立即解碼。但如果在弱網環境下爲了消除網絡抖動造成的影響，設置一定的緩存也有必要，因此需要在直播的穩定性和首開延遲優化上找到平衡，調整優化緩衝區大小這個值。
播放端動態 buffer 策略，這是上面播放端緩存控制的改進版本。如果只是做 0 緩存和固定大小的緩存之間進行選擇找到平衡，最終還是會選擇一個固定大小的緩存，這對億級的移動互聯網終端用戶來說並不公平，他們不同的網絡狀況決定了這個固定大小的緩存並不完全合適。因此，我們可以考慮一種「動態 buffer 策略」，在播放器開啓的時候採用非常小甚至 0 緩存的策略，通過對下載首片視頻的耗時來決定下一個時間片的緩存大小，同時在播放過程中實時監測當前網絡，實時調整播放過程中緩存的大小。這樣即可做到極低的首開時間，又可能夠儘量消除網絡抖動造成的影響。
動態碼率播放策略。除了動態調整 buffer 大小的策略之外，也可以利用實時監測的網絡信息來動態調整播放過程中的碼率，在網絡帶寬不足的情況下降低碼率進行播放，減少延遲。
喜歡音視頻的朋友可以關注+評論
