Android音視頻開發——MediaCodec播放H264視頻

所以67實際就是sps

創新互聯公司堅持“要么做到，要么別承諾”的工作理念，服務領域包括：網站制作、網站建設、企業官網、英文網站、手機端網站、網站推廣等服務，滿足客戶于互聯網時代的大城網站設計、移動媒體設計的需求，幫助企業找到有效的互聯網解決方案。努力成為您成熟可靠的網絡建設合作伙伴！

為什么視頻編碼采用YUV而不是rgb

MediaCodec概念

大家可能不太容易明白，我畫了一個圖

如果第二個參數設置了surface，那么在釋放的時候releaseOutputBuffer的第二個參數需要設置為true

如果第二個參數設置為null.那么在釋放的時候releaseOutputBuffer的第二個參數需要設置為false

因此我們可以設置編碼器的初始化

2、找到可用的byeBuffer，并將bytebuffer塞數據，塞完數據，需要通知dsp去解碼

android音視頻開發怎么做？

android音視頻開發要想不費什么功夫的話，可以選擇接入第三方的SDK，比如ZEGO即構科技，開發者可以調用ZEGO的API，4行代碼30分鐘就可以在應用內搭建出音視頻場景，應用在視頻會議、語音交友、秀場直播都可以

Android -- 音視頻基礎知識

幀，是視頻的一個基本概念，表示一張畫面，如上面的翻頁動畫書中的一頁，就是一幀。一個視頻就是由許許多多幀組成的。

幀率，即單位時間內幀的數量，單位為：幀/秒 或fps（frames per second）。一秒內包含多少張圖片，圖片越多，畫面越順滑，過渡越自然。 幀率的一般以下幾個典型值：

24/25 fps：1秒 24/25 幀，一般的電影幀率。

30/60 fps：1秒 30/60 幀，游戲的幀率，30幀可以接受，60幀會感覺更加流暢逼真。

85 fps以上人眼基本無法察覺出來了，所以更高的幀率在視頻里沒有太大意義。

這里我們只講常用到的兩種色彩空間。

RGB的顏色模式應該是我們最熟悉的一種，在現在的電子設備中應用廣泛。通過R G B三種基礎色，可以混合出所有的顏色。

這里著重講一下YUV，這種色彩空間并不是我們熟悉的。這是一種亮度與色度分離的色彩格式。

早期的電視都是黑白的，即只有亮度值，即Y。有了彩色電視以后，加入了UV兩種色度，形成現在的YUV，也叫YCbCr。

Y：亮度，就是灰度值。除了表示亮度信號外，還含有較多的綠色通道量。

U：藍色通道與亮度的差值。

V：紅色通道與亮度的差值。

音頻數據的承載方式最常用的是 脈沖編碼調制 ，即 PCM 。

在自然界中，聲音是連續不斷的，是一種模擬信號，那怎樣才能把聲音保存下來呢？那就是把聲音數字化，即轉換為數字信號。

我們知道聲音是一種波，有自己的振幅和頻率，那么要保存聲音，就要保存聲音在各個時間點上的振幅。

而數字信號并不能連續保存所有時間點的振幅，事實上，并不需要保存連續的信號，就可以還原到人耳可接受的聲音。

根據奈奎斯特采樣定理：為了不失真地恢復模擬信號，采樣頻率應該不小于模擬信號頻譜中最高頻率的2倍。

根據以上分析，PCM的采集步驟分為以下步驟：

采樣率，即采樣的頻率。

上面提到，采樣率要大于原聲波頻率的2倍，人耳能聽到的最高頻率為20kHz，所以為了滿足人耳的聽覺要求，采樣率至少為40kHz，通常為44.1kHz，更高的通常為48kHz。

采樣位數，涉及到上面提到的振幅量化。波形振幅在模擬信號上也是連續的樣本值，而在數字信號中，信號一般是不連續的，所以模擬信號量化以后，只能取一個近似的整數值，為了記錄這些振幅值，采樣器會采用一個固定的位數來記錄這些振幅值，通常有8位、16位、32位。

位數越多，記錄的值越準確，還原度越高。

最后就是編碼了。由于數字信號是由0，1組成的，因此，需要將幅度值轉換為一系列0和1進行存儲，也就是編碼，最后得到的數據就是數字信號：一串0和1組成的數據。

整個過程如下：

聲道數，是指支持能不同發聲（注意是不同聲音）的音響的個數。 單聲道：1個聲道

雙聲道：2個聲道

立體聲道：默認為2個聲道

立體聲道（4聲道）：4個聲道

碼率，是指一個數據流中每秒鐘能通過的信息量，單位bps（bit per second）

碼率 = 采樣率 * 采樣位數 * 聲道數

這里的編碼和上面音頻中提到的編碼不是同個概念，而是指壓縮編碼。

我們知道，在計算機的世界中，一切都是0和1組成的，音頻和視頻數據也不例外。由于音視頻的數據量龐大，如果按照裸流數據存儲的話，那將需要耗費非常大的存儲空間，也不利于傳送。而音視頻中，其實包含了大量0和1的重復數據，因此可以通過一定的算法來壓縮這些0和1的數據。

特別在視頻中，由于畫面是逐漸過渡的，因此整個視頻中，包含了大量畫面/像素的重復，這正好提供了非常大的壓縮空間。

因此，編碼可以大大減小音視頻數據的大小，讓音視頻更容易存儲和傳送。

視頻編碼格式有很多，比如H26x系列和MPEG系列的編碼，這些編碼格式都是為了適應時代發展而出現的。

其中，H26x（1/2/3/4/5）系列由ITU（International Telecommunication Union）國際電傳視訊聯盟主導

MPEG（1/2/3/4）系列由MPEG（Moving Picture Experts Group, ISO旗下的組織）主導。

當然，他們也有聯合制定的編碼標準，那就是現在主流的編碼格式H264，當然還有下一代更先進的壓縮編碼標準H265。

H264是目前最主流的視頻編碼標準，所以我們后續的文章中主要以該編碼格式為基準。

H264由ITU和MPEG共同定制，屬于MPEG-4第十部分內容。

我們已經知道，視頻是由一幀一幀畫面構成的，但是在視頻的數據中，并不是真正按照一幀一幀原始數據保存下來的（如果這樣，壓縮編碼就沒有意義了）。

H264會根據一段時間內，畫面的變化情況，選取一幀畫面作為完整編碼，下一幀只記錄與上一幀完整數據的差別，是一個動態壓縮的過程。

在H264中，三種類型的幀數據分別為

I幀：幀內編碼幀。就是一個完整幀。

P幀：前向預測編碼幀。是一個非完整幀，通過參考前面的I幀或P幀生成。

B幀：雙向預測內插編碼幀。參考前后圖像幀編碼生成。B幀依賴其前最近的一個I幀或P幀及其后最近的一個P幀。

全稱：Group of picture。指一組變化不大的視頻幀。

GOP的第一幀成為關鍵幀：IDR

IDR都是I幀，可以防止一幀解碼出錯，導致后面所有幀解碼出錯的問題。當解碼器在解碼到IDR的時候，會將之前的參考幀清空，重新開始一個新的序列，這樣，即便前面一幀解碼出現重大錯誤，也不會蔓延到后面的數據中。

DTS全稱：Decoding Time Stamp。標示讀入內存中數據流在什么時候開始送入解碼器中進行解碼。也就是解碼順序的時間戳。

PTS全稱：Presentation Time Stamp。用于標示解碼后的視頻幀什么時候被顯示出來。

前面我們介紹了RGB和YUV兩種圖像色彩空間。H264采用的是YUV。

YUV存儲方式分為兩大類：planar 和 packed。

planar如下：

packed如下：

上面說過，由于人眼對色度敏感度低，所以可以通過省略一些色度信息，即亮度共用一些色度信息，進而節省存儲空間。因此，planar又區分了以下幾種格式：YUV444、 YUV422、YUV420。

YUV 4:4:4采樣，每一個Y對應一組UV分量。

YUV 4:2:2采樣，每兩個Y共用一組UV分量。

YUV 4:2:0采樣，每四個Y共用一組UV分量。

其中，最常用的就是YUV420。

YUV420屬于planar存儲方式，但是又分兩種類型：

YUV420P：三平面存儲。數據組成為YYYYYYYYUUVV（如I420）或YYYYYYYYVVUU（如YV12）。

YUV420SP：兩平面存儲。分為兩種類型YYYYYYYYUVUV（如NV12）或YYYYYYYYVUVU（如NV21）

原始的PCM音頻數據也是非常大的數據量，因此也需要對其進行壓縮編碼。

和視頻編碼一樣，音頻也有許多的編碼格式，如：WAV、MP3、WMA、APE、FLAC等等，音樂發燒友應該對這些格式非常熟悉，特別是后兩種無損壓縮格式。

但是，我們今天的主角不是他們，而是另外一個叫AAC的壓縮格式。

AAC是新一代的音頻有損壓縮技術，一種高壓縮比的音頻壓縮算法。在MP4視頻中的音頻數據，大多數時候都是采用AAC壓縮格式。

AAC格式主要分為兩種：ADIF、ADTS。

ADIF：Audio Data Interchange Format。音頻數據交換格式。這種格式的特征是可以確定的找到這個音頻數據的開始，不需進行在音頻數據流中間開始的解碼，即它的解碼必須在明確定義的開始處進行。這種格式常用在磁盤文件中。

ADTS：Audio Data Transport Stream。音頻數據傳輸流。這種格式的特征是它是一個有同步字的比特流，解碼可以在這個流中任何位置開始。它的特征類似于mp3數據流格式。

ADIF數據格式：

ADTS 一幀 數據格式（中間部分，左右省略號為前后數據幀）：

AAC內部結構也不再贅述，可以參考AAC 文件解析及解碼流程

細心的讀者可能已經發現，前面我們介紹的各種音視頻的編碼格式，沒有一種是我們平時使用到的視頻格式，比如：mp4、rmvb、avi、mkv、mov...

沒錯，這些我們熟悉的視頻格式，其實是包裹了音視頻編碼數據的容器，用來把以特定編碼標準編碼的視頻流和音頻流混在一起，成為一個文件。

例如：mp4支持H264、H265等視頻編碼和AAC、MP3等音頻編碼。

我們在一些播放器中會看到，有硬解碼和軟解碼兩種播放形式給我們選擇，但是我們大部分時候并不能感覺出他們的區別，對于普通用戶來說，只要能播放就行了。

那么他們內部究竟有什么區別呢？

在手機或者PC上，都會有CPU、GPU或者解碼器等硬件。通常，我們的計算都是在CPU上進行的，也就是我們軟件的執行芯片，而GPU主要負責畫面的顯示（是一種硬件加速）。

所謂軟解碼，就是指利用CPU的計算能力來解碼，通常如果CPU的能力不是很強的時候，一則解碼速度會比較慢，二則手機可能出現發熱現象。但是，由于使用統一的算法，兼容性會很好。

硬解碼，指的是利用手機上專門的解碼芯片來加速解碼。通常硬解碼的解碼速度會快很多，但是由于硬解碼由各個廠家實現，質量參差不齊，非常容易出現兼容性問題。

MediaCodec 是Android 4.1(api 16)版本引入的編解碼接口，是所有想在Android上開發音視頻的開發人員繞不開的坑。

由于Android碎片化嚴重，雖然經過多年的發展，Android硬解已經有了很大改觀，但實際上各個廠家實現不同， 還是會有一些意想不到的坑。

相對于FFmpeg，Android原生硬解碼還是相對容易入門一些，所以接下來，我將會從MediaCodec入手，講解如何實現視頻的編解碼，以及引入OpenGL實現對視頻的編輯，最后才引入FFmpeg來實現軟解，算是一個比較常規的音視頻開發入門流程吧。

Android音視頻開發——H264的基本概念

ffmpeg常用命令

封裝格式 。

編碼的本質就是壓縮數據

音頻編碼的作用： 將音頻采樣數據（ PCM 等）壓縮成音頻碼流，從而降低音頻的數據量。 常用的音頻編碼方式有以下幾種：

H264壓縮技術主要采用了以下幾種方法對視頻數據進行壓縮。包括：

經過壓縮后的幀分為：I幀，P幀和B幀:

除了I/P/B幀外，還有圖像序列GOP。

組成碼流的結構中，包含了以下幾個部分，從大到小依次是：

H264視頻序列，圖像，片組，片，NALU，宏塊，像素

H264功能分為兩層：

1.H264視頻序列包括一系列的NAL單元，每個NAL單元包含一個RBSP。

2.一個原始的H.264由 N個NALU單元組成

3.NALU單元由[StartCode][NALU Header][NALU Payload]三部分組成

5.NAL Header

由三部分組成forbidden_bit(1bit)(禁止位)，nal_reference_bit(2bits)（優先級,，值越大，該NAL越重要），nal_unit_type(5bits)（類型）

nal_unit_type

6.NAL的解碼單元的流程如下

android音視頻開發一安卓常用API

Android SDK 提供了兩套音頻采集的API，分別是：MediaRecorder 和 AudioRecord，前者是一個更加上層一點的API，它可以直接把手機麥克風錄入的音頻數據進行編碼壓縮（如AMR、MP3等）并存成文件，而后者則更接近底層，能夠更加自由靈活地控制，可以得到原始的一幀幀PCM音頻數據。如果想簡單地做一個錄音機，錄制成音頻文件，則推薦使用 MediaRecorder，而如果需要對音頻做進一步的算法處理、或者采用第三方的編碼庫進行壓縮、以及網絡傳輸等應用，則建議使用 AudioRecord，其實 MediaRecorder 底層也是調用了 AudioRecord 與 Android Framework 層的 AudioFlinger 進行交互的。直播中實時采集音頻自然是要用AudioRecord了。

2.1 播放聲音可以用MediaPlayer和AudioTrack，兩者都提供了Java?API供應用開發者使用。雖然都可以播放聲音，但兩者還是有很大的區別的。

2.2 其中最大的區別是MediaPlayer可以播放多種格式的聲音文件，例如MP3，AAC，WAV，OGG，MIDI等。MediaPlayer會在framework層創建對應的音頻解碼器。而AudioTrack只能播放已經解碼的PCM流，如果對比支持的文件格式的話則是AudioTrack只支持wav格式的音頻文件，因為wav格式的音頻文件大部分都是PCM流。AudioTrack不創建解碼器，所以只能播放不需要解碼的wav文件。

2.3 MediaPlayer在framework層還是會創建AudioTrack，把解碼后的PCM數流傳遞給AudioTrack，AudioTrack再傳遞給AudioFlinger進行混音，然后才傳遞給硬件播放,所以是MediaPlayer包含了AudioTrack。

2.4?在接觸Android音頻播放API的時候，發現SoundPool也可以用于播放音頻。下面是三者的使用場景：MediaPlayer 更加適合在后臺長時間播放本地音樂文件或者在線的流式資源; SoundPool 則適合播放比較短的音頻片段，比如游戲聲音、按鍵聲、鈴聲片段等等，它可以同時播放多個音頻; 而 AudioTrack 則更接近底層，提供了非常強大的控制能力，支持低延遲播放，適合流媒體和VoIP語音電話等場景。

使用 Camera API 采集視頻數據并保存到文件，分別使用 SurfaceView、TextureView 來預覽 Camera 數據，取到 NV21 的數據回調。

4.1 一個音視頻文件是由音頻和視頻組成的，我們可以通過MediaExtractor、MediaMuxer把音頻或視頻給單獨抽取出來，抽取出來的音頻和視頻能單獨播放；?

4.2?MediaMuxer的作用是生成音頻或視頻文件；還可以把音頻與視頻混合成一個音視頻文件。

文獻資料?

Android音視頻開發-入門(三):使用 Camera API 采集NV21數據

做過Android開發的人一般都知道，有兩種方法能夠做到這一點：SufaceView、TextureView。

Android 中Google支持的Camera Preview CallBack的YUV常用格式有兩種：一種是NV21，一種是YV12,Android一般默認使用的是YCbCR_420_sp(NV21)

新聞標題：android視頻開發,安卓開發視頻播放
文章出自：http://www.js-pz168.com/article30/dsisepo.html

成都網站建設公司_創新互聯，為您提供品牌網站建設、App開發、網站策劃、動態網站、營銷型網站建設、ChatGPT

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯