Ⅰ 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音視頻】視頻開發優化
本文主要記錄一些在視頻開發中會遇到的一些優化及自己的實現思路。
在刷抖音等短視頻的時候，會發現視頻基本是秒開的，那麼怎麼實現呢？
我的實現思路：視頻採用m3u8格式的，利用其特性，我們可以預先緩存其中的第一個ts文件和m3u8文件，然後視頻播放時通過訪問本地伺服器讀取緩存下來的m3u8和第一個ts文件，縮短了起播時網路載入這一步的時間，通過測試發現，使用Android自帶的播放器對視頻播放的話，視頻起播穩定在1s左右，視頻Ijkplayer播放器的話起播時間穩定在0.2s左右，基本實現了視頻秒開的功能，當然還可以通過實際項目的需要，進一步在視頻生成時控制視頻的解析度、幀率、碼率等，規定第一個ts的時間等。
實現Demo： Android短視頻秒開實現
在列表視頻的開發中，會存在滑動過程中卡頓的現象，這是由於release這個方法是阻塞的，因此我們可以將其非同步處理。
本文持續更新，若你在開發中遇到優化問題，可留言討論。
Ⅲ android下視頻文件從解碼到播放需要哪幾步，請簡述
Android通過軟解碼播放視頻
1， 一般情況下Android的平台都是硬解碼視頻的，尤其是在Arm平台這種成熟的硬體平台上面（硬解碼代碼由晶元廠商提供）。但是Android移植到
2， MIPS平台時間還不長，還不成熟，還需要自己實現硬體解碼的工作。為了早日讓Android在MIPS平台運行起來，我選擇了先用軟解碼播放視頻。
3，Android代碼是從Android on MIPS社區獲得的代碼。發現軟解碼視頻播放過程中會發生崩潰。經過分析好像是內存分配的問題。
4， 經過研究OpenCore庫（Android框架是通過OpenCore來播放視頻的，網上有很多關於OpenCore的介紹，這里就不多說了），並參考Android平台——Surfaceflinger機制。發現問題出在源文件：
frameworks/base/libs/surfaceflinger/LayerBuffer.cpp的LayerBuffer::BufferSource::postBuffer方法中：
............
buffer = new LayerBuffer::Buffer(buffers, offset);
............類LayerBuffer::Buffer的構造函數代碼如下：
LayerBuffer::Buffer::Buffer(const ISurface::BufferHeap& buffers, ssize_t offset)
: mBufferHeap(buffers)
{
NativeBuffer& src(mNativeBuffer);
g.handle = 0;
gralloc_mole_t const * mole = LayerBuffer::getGrallocMole();
if (mole && mole->perform) {
int err = mole->perform(mole,
GRALLOC_MODULE_PERFORM_CREATE_HANDLE_FROM_BUFFER,
buffers.heap->heapID(), buffers.heap->getSize(),
offset, buffers.heap->base(),
& g.handle);
if (err == NO_ERROR) {
op.l = 0;
op.t = 0;
op.r = buffers.w;
op.b = buffers.h;
g.w = buffers.hor_stride ?: buffers.w;
g.h = r_stride ?: buffers.h;
rmat = rmat;
se = (void*)(intptr_t(buffers.heap->base()) + offset);
}
}
}LayerBuffer::getGrallocMole方法的調用到的Gralloc為：
hardware/libhardware/moles/gralloc/gralloc.cpp因為的沒有實現在自己的硬體只能用通用的Gralloc，經過分析發現通用的Gralloc沒有實現
5， mole->perform函數指針，mole->perform為NULL，所以不會對Buffer進行必要的初始化（我覺得應該是一個疏忽，只是不知道是谷歌的疏忽，還是MIPS移植人員的疏忽，最起碼應該能夠讓通用硬體能跑起來）。參考其他的硬體實現一個perform函數指針到通用Gralloc中。
在源文件：
hardware/libhardware/moles/gralloc/mapper.cpp增加如下的函數定義：
int gralloc_perform(struct gralloc_mole_t const* mole,
int operation, ... )
{
int res = -EINVAL;
va_list args;
va_start(args, operation);
switch (operation) {
case GRALLOC_MODULE_PERFORM_CREATE_HANDLE_FROM_BUFFER: {
int fd = va_arg(args, int);
size_t size = va_arg(args, size_t);
size_t offset = va_arg(args, size_t);
void* base = va_arg(args, void*);
native_handle_t** handle = va_arg(args, native_handle_t**);
private_handle_t* hnd = (private_handle_t*)native_handle_create(
private_handle_t::sNumFds, private_handle_t::sNumInts);
hnd->magic = private_handle_t::sMagic;
hnd->fd = fd;
hnd->flags = private_handle_t::PRIV_FLAGS_USES_PMEM;
hnd->size = size;
hnd->offset = offset;
hnd->base = intptr_t(base) + offset;
hnd->lockState = private_handle_t::LOCK_STATE_MAPPED;
*handle = (native_handle_t *)hnd;
res = 0;
break;
}
}
va_end(args);
return res;
}然後在gralloc.cpp中增加，gralloc_perform的聲明：
extern int gralloc_perform(struct gralloc_mole_t const* mole,
int operation, ... );並修改HAL_MODULE_INFO_SYM的定義，增加perform欄位的定義：
struct private_mole_t HAL_MODULE_INFO_SYM = {
base: {
.......
perform: gralloc_perform,
},
......
}; 重新編譯gralloc模塊，再次用Gallary應用程序通過軟解碼播放視頻，就可以流暢的播放了，軟解碼的效率挺高的，沒有卡的感覺！
Ⅳ android 開發 怎麼通過地址鏈接訪問獲取視頻流,並解析播放
你可以直接把這個鏈接發送給系統播放器播放，或者用videoview播放， 你的地址鏈接是個參數，set一下就可以播放了