Android 基於ffmpeg開發簡易播放器 - 基礎知識

時間 2019-11-06

標籤 android 基於 ffmpeg 開發簡易播放基礎知識欄目 Android 简体版

原文原文鏈接

音視頻基礎知識

視頻文件格式

對於視頻來講，常見的文件格式則有：.mov、.avi、.mpg、.vob、.mkv、.rm、.rmvb 等等。文件格式一般表現爲文件在操做系統上存儲時的後綴名，它一般會被操做系統用來與相應的打開程序關聯。之因此會有不一樣格式的視頻，是由於採用了不一樣的封裝方式來實現視頻的。算法

視頻封裝格式

視頻封裝格式至關於一種儲存視頻信息的容器，它裏面包含了封裝視頻文件所須要的視頻信息、音頻信息和相關的配置信息(好比：視頻和音頻的關聯信息、如何解碼等等)。一種視頻封裝格式的直接反映就是對應着相應的視頻文件格式。shell

一些文件封裝格式：瀏覽器

AVI 格式，對應的文件格式爲 .avi。這種視頻格式的優勢是圖像質量好，無損 AVI 能夠保存 alpha 通道。缺點是體積過於龐大，而且壓縮標準不統一，存在較多的高低版本兼容問題。
DV-AVI 格式，對應的文件格式爲 .avi。常見的數碼攝像機就是使用這種格式記錄視頻數據的。它能夠經過電腦的 IEEE 1394 端口傳輸視頻數據到電腦，也能夠將電腦中編輯好的的視頻數據回錄到數碼攝像機中。
WMV 格式，對應的文件格式是 .wmv、.asf，是微軟推出的一種採用獨立編碼方式而且能夠直接在網上實時觀看視頻節目的文件壓縮格式。在同等視頻質量下，WMV 格式的文件能夠邊下載邊播放，所以很適合在網上播放和傳輸。
MPEG 格式，對應的文件格式有 .mpg、.mpeg、.mpe、.dat、.vob、.asf、.3gp、.mp4 等等。MPEG 格式目前有三個壓縮標準，分別是 MPEG-一、MPEG-二、和 MPEG-4。MPEG-4 是如今用的比較多的視頻封裝格式，它爲了播放流式媒體的高質量視頻而專門設計的，以求使用最少的數據得到最佳的圖像質量。
Matroska 格式，對應的文件格式是 .mkv，Matroska 是一種新的視頻封裝格式，它可將多種不一樣編碼的視頻及 16 條以上不一樣格式的音頻和不一樣語言的字幕流封裝到一個 Matroska Media 文件當中。
Real Video 格式，對應的文件格式是 .rm、.rmvb。用戶可使用 RealPlayer 根據不一樣的網絡傳輸速率制定出不一樣的壓縮比率，從而實如今低速率的網絡上進行影像數據實時傳送和播放。
QuickTime File Format 格式，對應的文件格式是 .mov。這種封裝格式具備較高的壓縮比率和較完美的視頻清晰度等特色，並能夠保存 alpha 通道。
Flash Video 格式，對應的文件格式是 .flv，是由 Adobe Flash 延伸出來的一種網絡視頻封裝格式。這種格式被不少視頻網站所採用。

在程序設計中，咱們須要將視頻文件以指定的格式獨取出來。bash

視頻編解碼方式

視頻編解碼的過程是指對數字視頻進行壓縮或解壓縮的一個過程。服務器

在作視頻編解碼時，須要考慮如下這些因素的平衡：視頻的質量、用來表示視頻所須要的數據量（一般稱之爲碼率）、編碼算法和解碼算法的複雜度、針對數據丟失和錯誤的魯棒性（Robustness）、編輯的方便性、隨機訪問、編碼算法設計的完美性、端到端的延時以及其它一些因素。網絡

常見的視頻編碼方式有：數據結構

H.26X 系列，由國際電傳視訊聯盟遠程通訊標準化組織(ITU-T)主導，包括 H.26一、H.26二、H.26三、H.26四、H.265。ide
- 1.H.261，主要用於老的視頻會議和視頻電話系統。是第一個使用的數字視頻壓縮標準。實質上說，以後的全部的標準視頻編解碼器都是基於它設計的。
- H.262，等同於 MPEG-2 第二部分，使用在 DVD、SVCD 和大多數數字視頻廣播系統和有線分佈系統中。
- H.263，主要用於視頻會議、視頻電話和網絡視頻相關產品。在對逐行掃描的視頻源進行壓縮的方面，H.263 比它以前的視頻編碼標準在性能上有了較大的提高。尤爲是在低碼率端，它能夠在保證必定質量的前提下大大的節約碼率。
- H.264，等同於 MPEG-4 第十部分，也被稱爲高級視頻編碼(Advanced Video Coding，簡稱 AVC)，是一種視頻壓縮標準，一種被普遍使用的高精度視頻的錄製、壓縮和發佈格式。該標準引入了一系列新的可以大大提升壓縮性能的技術，並可以同時在高碼率端和低碼率端大大超越之前的諸標準。
- H.265，被稱爲高效率視頻編碼(High Efficiency Video Coding，簡稱 HEVC)是一種視頻壓縮標準，是 H.264 的繼任者。HEVC 被認爲不只提高圖像質量，同時也能達到 H.264 兩倍的壓縮率（等同於一樣畫面質量下比特率減小了 50%），可支持 4K 分辨率甚至到超高畫質電視，最高分辨率可達到 8192×4320（8K 分辨率），這是目前發展的趨勢。
MPEG 系列，由國際標準組織機構(ISO)下屬的運動圖象專家組(MPEG)開發。性能
- MPEG-1 第二部分，主要使用在 VCD 上，有些在線視頻也使用這種格式。該編解碼器的質量大體上和原有的 VHS 錄像帶至關。
- MPEG-2 第二部分，等同於 H.262，使用在 DVD、SVCD 和大多數數字視頻廣播系統和有線分佈系統中。
- MPEG-4 第二部分，可使用在網絡傳輸、廣播和媒體存儲上。比起 MPEG-2 第二部分和初版的 H.263，它的壓縮性能有所提升。
- MPEG-4 第十部分，等同於 H.264，是這兩個編碼組織合做誕生的標準。
其餘，AMV、AVS、Bink、CineForm 等等，這裏就不作多的介紹了。網站

能夠把「視頻封裝格式」看作是一個裝着視頻、音頻、「視頻編解碼方式」等信息的容器。一種「視頻封裝格式」能夠支持多種「視頻編解碼方式」，好比：QuickTime File Format(.MOV) 支持幾乎全部的「視頻編解碼方式」，MPEG(.MP4) 也支持至關廣的「視頻編解碼方式」。當咱們看到一個視頻文件名爲 test.mov 時，咱們能夠知道它的「視頻文件格式」是 .mov，也能夠知道它的視頻封裝格式是 QuickTime File Format，可是沒法知道它的「視頻編解碼方式」。那比較專業的說法多是以 A/B 這種方式，A 是「視頻編解碼方式」，B 是「視頻封裝格式」。好比：一個 H.264/MOV 的視頻文件，它的封裝方式就是 QuickTime File Format，編碼方式是 H.264。

視頻解碼後須要轉換成顯卡支持的格式纔可以顯示。像素格式的轉換。

音頻編解碼方式

在視頻中常用的音頻編碼方式有：

AAC。
MP3，是當曾經很是流行的一種數字音頻編碼和有損壓縮格式，它被設計來大幅下降音頻數據量。
WMA，包括有損和無損壓縮格式。

音頻須要轉換成聲卡支持的格式纔可以播放。重採樣。

封裝格式和編碼格式

像素格式

像素格式就是圖像的具體像素用什麼表示，主要有兩種，RGB和YUV。攝像頭採集的像素格式和顯示器顯示的像素格式都爲RGB格式，可是不少的壓縮和解碼算法都是基於YUV格式的，因此須要進行RGB和YUV格式的轉換。能夠直接使用顯卡的Shader語言來轉換。

PCM音頻參數

採樣率：44100 （CD，1s內採集了44100次，越大越接近真實狀況）通道：左右聲道樣本大小：AV_SAMPLE_FMT_S16，AV_SAMPLE_FMT_FLTP（浮點格式，效率更高）。 AV_SAMPLE_FMT_FLTP沒法直接播放，須要進行重採樣轉換成AV_SAMPLE_FMT_S16格式以後才能播放。

樣本類型planar

MP4格式分析

blog.csdn.net/shelldon/article/details/54144409

關於 H.264

H.264 是如今普遍採用的一種編碼方式。

解釋幾個概念：

圖像。H.264 中，「圖像」是個集合的概念，幀、頂場、底場均可以稱爲圖像。一幀一般就是一幅完整的圖像。當採集視頻信號時，若是採用逐行掃描，則每次掃描獲得的信號就是一副圖像，也就是一幀。當採集視頻信號時，若是採用隔行掃描（奇、偶數行），則掃描下來的一幀圖像就被分爲了兩個部分，這每一部分就稱爲「場」，根據次序分爲：「頂場」和「底場」。「幀」和「場」的概念又帶來了不一樣的編碼方式：幀編碼、場編碼。逐行掃描適合於運動圖像，因此對於運動圖像採用幀編碼更好；隔行掃描適合於非運動圖像，因此對於非運動圖像採用場編碼更好。

片(Slice)，每一幀圖像能夠分爲多個片。
網絡提取層單元(NALU, Network Abstraction Layer Unit)，NALU 是用來將編碼的數據進行打包的，一個分片(Slice)能夠編碼到一個 NALU 單元。不過一個 NALU 單元中除了容納分片(Slice)編碼的碼流外，還能夠容納其餘數據，好比序列參數集 SPS。對於客戶端其主要任務則是接收數據包，從數據包中解析出 NALU 單元，而後進行解碼播放。
宏塊(Macroblock)，分片是由宏塊組成。

顏色模型

最經典的顏色模型應該就是 RGB 模型了。

在 RGB 模型中每種顏色須要 3 個數字，分別表示 R、G、B，好比 (255, 0, 0) 表示紅色，一般一個數字佔用 1 字節，那麼表示一種顏色須要 24 bits。那麼有沒有更高效的顏色模型可以用更少的 bit 來表示顏色呢？

如今咱們假設咱們定義一個「亮度(Luminance)」的概念來表示顏色的亮度，那它就能夠用含 R、G、B 的表達式表示爲：

Y = kr*R + kg*G + kb*B
複製代碼

Y 即「亮度」，kr、kg、kb 即 R、G、B 的權重值。

這時，咱們能夠定義一個「色度(Chrominance)」的概念來表示顏色的差別：

Cr = R – Y
Cg = G – Y
Cb = B – Y
複製代碼

Cr、Cg、Cb 分別表示在 R、G、B 上的色度份量。上述模型就是 YCbCr 顏色模型基本原理。

YCbCr 是屬於 YUV 家族的一員，是在計算機系統中應用最爲普遍的顏色模型。在 YUV 中 Y 表示的是「亮度」，也就是灰階值，U 和 V 則是表示「色度」。YUV 的關鍵是在於它的亮度信號 Y 和色度信號 U、V 是分離的。那就是說即便只有 Y 信號份量而沒有 U、V 份量，咱們仍然能夠表示出圖像，只不過圖像是黑白灰度圖像。在YCbCr 中 Y 是指亮度份量，Cb 指藍色色度份量，而 Cr 指紅色色度份量。

YCbCr 與 RGB 相互轉換的公式：

Y = 0.299R + 0.587G + 0.114B
Cb = 0.564(B - Y)
Cr = 0.713(R - Y)
R = Y + 1.402Cr
G = Y - 0.344Cb - 0.714Cr
B = Y + 1.772Cb
複製代碼

可是咱們會發現，這裏 YCbCr 也仍然用了 3 個數字來表示顏色啊，有節省 bit 嗎？爲了回答這個問題，咱們來結合視頻中的圖像和圖像中的像素表示來講明。

圖片是由相似下面的像素組成：

一副圖片就是一個像素陣列：

上圖中，每一個像素的 3 個份量的信息是完整的，YCbCr 4:4:4。

上圖中，對於每一個像素點都保留「亮度」值，可是省略每行中偶素位像素點的「色度」值，從而節省了 bit。

上圖中，作了更多的省略，可是對圖片質量的影響卻不會太大。

碼流格式

對於一個解碼器來講，它的工做對象就是從一個特定結構的數據流中去獲取有效的 bit 流，而這個數據流則是結構化後分爲數據包傳輸的，其大體結構以下：

咱們能夠看到，在 NAL 包之間存在着一些間隔標記。

NAL 包的第一個字節是定義包類型的頭文件，NAL 包有這樣一些類型：

NAL 的類型說明了當前這個 NAL 包的數據結構和數據含義，它多是片(Slice)，參數集或者填充數據等等。

如上圖所示，NAL 包將其負載數據存儲在 RBSP(Raw Byte Sequence Payload) 中，RBSP 是一系列的 SODB(String Of Data Bits)。

H.264 的碼流結構：

一張圖片能夠包含一個或多個分片(Slice)，而每個分片(Slice)又會被分爲了若干宏塊(Macroblock)。對於分片(Slice)來講，有以下這些類型：

如咱們所見，每一個分片也包含着頭和數據兩部分，分片頭中包含着分片類型、分片中的宏塊類型、分片幀的數量以及對應的幀的設置和參數等信息，而分片數據中則是宏塊，這裏就是咱們要找的存儲像素數據的地方。

宏塊是視頻信息的主要承載者，由於它包含着每個像素的亮度和色度信息。視頻解碼最主要的工做則是提供高效的方式從碼流中得到宏塊中的像素陣列。

從上圖中，能夠看到，宏塊中包含了宏塊類型、預測類型、Coded Block Pattern、Quantization Parameter、像素的亮度和色度數據集等等信息。

GOP

一組能夠獨立解碼並播放的數據：

分爲I幀，B幀，P幀。

I幀：關鍵幀。能夠獨立解碼並播放。
B幀：相對前一幀的變化，須要參考前一幀進行解碼。
P幀：相對前一幀和後一幀的變化，須要參考前一幀和後一幀進行解碼。

因此解碼順序與顯示順序不一致。須要緩衝必定的幀數纔可以正確顯示。

PTS & DTS

視頻的播放過程能夠簡單理解爲一幀一幀的畫面按照時間順序呈現出來的過程。可是在實際應用中，並非每一幀都是完整的畫面，由於若是每一幀畫面都是完整的圖片，那麼一個視頻的體積就會很大，這樣對於網絡傳輸或者視頻數據存儲來講成本過高，因此一般會對視頻流中的一部分畫面進行壓縮（編碼）處理。因爲壓縮處理的方式不一樣，視頻中的畫面幀就分爲了避免同的類別，其中包括：I 幀、P 幀、B 幀。

I、P、B 幀

I 幀、P 幀、B 幀的區別在於：

I 幀（Intra coded frames）：I 幀圖像採用幀內編碼方式，即只利用了單幀圖像內的空間相關性，而沒有利用時間相關性。I 幀使用幀內壓縮，不使用運動補償，因爲 I 幀不依賴其它幀，因此是隨機存取的入點，同時是解碼的基準幀。I 幀主要用於接收機的初始化和信道的獲取，以及節目的切換和插入，I 幀圖像的壓縮倍數相對較低。I 幀圖像是週期性出如今圖像序列中的，出現頻率可由編碼器選擇。
P 幀（Predicted frames）：P 幀和 B 幀圖像採用幀間編碼方式，即同時利用了空間和時間上的相關性。P 幀圖像只採用前向時間預測，能夠提升壓縮效率和圖像質量。P 幀圖像中能夠包含幀內編碼的部分，即 P 幀中的每個宏塊能夠是前向預測，也能夠是幀內編碼。
B 幀（Bi-directional predicted frames）：B 幀圖像採用雙向時間預測，能夠大大提升壓縮倍數。值得注意的是，因爲 B 幀圖像採用了將來幀做爲參考，所以 MPEG-2 編碼碼流中圖像幀的傳輸順序和顯示順序是不一樣的。

也就是說，一個 I 幀能夠不依賴其餘幀就解碼出一幅完整的圖像，而 P 幀、B 幀不行。P 幀須要依賴視頻流中排在它前面的幀才能解碼出圖像。B 幀則須要依賴視頻流中排在它前面或後面的幀才能解碼出圖像。

這就帶來一個問題：在視頻流中，先到來的 B 幀沒法當即解碼，須要等待它依賴的後面的 I、P 幀先解碼完成，這樣一來播放時間與解碼時間不一致了，順序打亂了，那這些幀該如何播放呢？這時就須要瞭解另外兩個概念：DTS 和 PTS。

DTS、PTS 的概念

DTS（Decoding Time Stamp）：即解碼時間戳，這個時間戳的意義在於告訴播放器該在何時解碼這一幀的數據。
PTS（Presentation Time Stamp）：即顯示時間戳，這個時間戳用來告訴播放器該在何時顯示這一幀的數據。

須要注意的是：雖然 DTS、PTS 是用於指導播放端的行爲，但它們是在編碼的時候由編碼器生成的。

當視頻流中沒有 B 幀時，一般 DTS 和 PTS 的順序是一致的。但若是有 B 幀時，就回到了咱們前面說的問題：解碼順序和播放順序不一致了。

好比一個視頻中，幀的顯示順序是：I B B P，如今咱們須要在解碼 B 幀時知道 P 幀中信息，所以這幾幀在視頻流中的順序多是：I P B B，這時候就體現出每幀都有 DTS 和 PTS 的做用了。DTS 告訴咱們該按什麼順序解碼這幾幀圖像，PTS 告訴咱們該按什麼順序顯示這幾幀圖像。順序大概以下：

PTS: 1 4 2 3
   DTS: 1 2 3 4
Stream: I P B B
複製代碼

音頻的播放，也有 DTS、PTS 的概念，可是音頻沒有相似視頻中 B 幀，不須要雙向預測，因此音頻幀的 DTS、PTS 順序是一致的。

音頻視頻混合在一塊兒播放，就呈現了咱們經常看到的廣義的視頻。在音視頻一塊兒播放的時候，咱們一般須要面臨一個問題：怎麼去同步它們，以避免出現畫不對聲的狀況。

要實現音視頻同步，一般須要選擇一個參考時鐘，參考時鐘上的時間是線性遞增的，編碼音視頻流時依據參考時鐘上的時間給每幀數據打上時間戳。在播放時，讀取數據幀上的時間戳，同時參考當前參考時鐘上的時間來安排播放。這裏的說的時間戳就是咱們前面說的 PTS。實踐中，咱們能夠選擇：同步視頻到音頻、同步音頻到視頻、同步音頻和視頻到外部時鐘。

幀內預測和幀間預測

宏塊的數據結構中包含了「預測類型」這個字段，這裏就接着說說「幀內預測」和「幀間預測」這兩種在視頻編碼中經常使用到的壓縮方法，也能夠稱爲「幀內壓縮」和「幀間壓縮」。

幀內壓縮相似於圖片壓縮，跟這一幀的前面（或後面）一幀（或幾幀）無關，由當前幀中，已編碼的部分來推測當前待編碼的這一部分數據是什麼。幀間壓縮是由這一幀的前（或後）一幀（或幾幀）來推測當前待壓縮的這一部分數據是什麼。

上節中，咱們說過圖片能夠劃分爲宏塊。通常來講，運動多細節多的部分，劃分紅小塊來編碼，無變化的大片的部分，劃分紅大塊來編碼。其大體效果以下：

幀內預測

對於幀內壓縮，咱們能夠看下圖示例：

咱們能夠經過第一、二、三、四、5 塊的編碼來推測和計算第 6 塊的編碼，所以就不須要對第 6 塊進行編碼了，從而壓縮了第 6 塊，節省了空間。

幀內預測在 H.264 編碼標準裏有如下幾種預測方法：

幀間預測

對於幀間壓縮，能夠看下面連續的兩幀：

能夠看到先後兩幀的差別實際上是很小的，這時候用幀間壓縮就頗有意義。

作幀間壓縮經常使用的方式就是塊匹配(Block Matching)，就是找找看前面已經編碼的幾幀裏面，和我當前這個塊最相似的一個塊，這樣我就不用編碼當前塊的內容了，只須要編碼當前塊和我找到的那個塊的差別（稱爲殘差）便可。找最像的塊的過程叫運動搜索（Motion Search），又叫運動估計（Motion Estimation）。用殘差和原來的塊就能推算出當前塊的過程叫運動補償（Motion Compensation）。

視頻業務

視頻相關的業務方式一般有：本地視頻文件播放、網絡視頻點播、網絡視頻直播等等幾種。對於網絡視頻點播、網絡視頻直播，整個過程大體以下圖所示：

而本地視頻文件播放就更簡單了，是在上面的過程當中省略掉解協議的過程。

流媒體協議

隨着互聯網基礎設施愈來愈完善，網絡視頻點播和直播業務也愈來愈多，這其中少不了流媒體協議的支持。常見的流媒體協議有：

RTP，實時傳輸協議，Real-time Transport Protocol，是一種網絡傳輸協議，運行在 UDP 協議之上，RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議經常使用於流媒體系統（配合 RTSP 協議）。
RTCP，實時傳輸控制協議，Real-time Transport Control Protocol，是實時傳輸協議（RTP）的一個姐妹協議。RTCP爲RTP媒體流提供信道外（out-of-band）控制。RTCP 自己並不傳輸數據，但和 RTP 一塊兒協做將多媒體數據打包和發送。RTCP 按期在流多媒體會話參加者之間傳輸控制數據。RTCP 的主要功能是爲 RTP 所提供的服務質量（Quality of Service）提供反饋。
RTSP，實時流傳輸協議，Real Time Streaming Protocol，該協議定義了一對多應用程序如何有效地經過 IP 網絡傳送多媒體數據。RTSP 在體系結構上位於 RTP 和 RTCP 之上，它使用 TCP 或 UDP 完成數據傳輸。使用 RTSP 時，客戶機和服務器均可以發出請求，即 RTSP 能夠是雙向的。
RTMP，實時消息傳輸協議，Real Time Messaging Protocol，是 Adobe Systems 公司爲 Flash 播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議。協議基於 TCP，是一個協議族，包括 RTMP 基本協議及 RTMPT/RTMPS/RTMPE 等多種變種。RTMP 是一種設計用來進行實時數據通訊的網絡協議，主要用來在 Flash/AIR 平臺和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通訊。
RTMFP，是 Adobe 公司開發的一套新的通訊協議，全稱 Real Time Media Flow Protocol，協議基於 UDP，支持 C/S 模式和 P2P 模式，即該協議可讓使用 Adobe Flash Player 的終端用戶之間進行直接通訊。
HTTP，超文本傳輸協議，HyperText Transfer Protocol，運行在 TCP 之上，這個協議是你們很是熟悉的，它也能夠用到視頻業務中來。
HLS，是蘋果公司實現的基於 HTTP 的流媒體傳輸協議，全稱 HTTP Live Streaming，可支持流媒體的直播和點播，主要應用在 iOS 系統，爲 iOS 設備（如 iPhone、iPad）提供音視頻直播和點播方案。對於 HLS 點播，基本上就是常見的分段 HTTP 點播，不一樣在於，它的分段很是小。要實現HLS點播，重點在於對媒體文件分段。對於 HLS 直播，相對於常見的流媒體直播協議，例如 RTMP 協議、RTSP 協議等，HLS 最大的不一樣在於直播客戶端獲取到的並非一個完整的數據流，而是連續的、短時長的媒體文件（MPEG-TS 格式），客戶端不斷的下載並播放這些小文件。因爲數據經過 HTTP 協議傳輸，因此徹底不用考慮防火牆或者代理的問題，並且分段文件的時長很短，客戶端能夠很快的選擇和切換碼率，以適應不一樣帶寬條件下的播放。不過 HLS 的這種技術特色，決定了它的延遲通常老是會高於普通的流媒體直播協議。