當前位置:首頁 » 安卓系統 » android音頻分析

android音頻分析

發布時間: 2022-09-27 10:47:34

⑴ android頻譜分析怎麼做

Android 音樂頻譜分析,把時域上連續的信號(波形)強度轉換成離散的頻域信號(頻譜)。
目前該 軟體,沒有安卓版,主要是太復雜了,大型軟體很少有安卓版的。實時頻譜分析儀/音頻可視化功能: - 128個高品質的頻段20Hz到22kHz的] - 對數頻率刻度,以符合人類感知 - 低延遲高響應性 - 的幀率看到平滑的頻率和幅度的動作 - 高性能的本機代碼中使用OpenGL ES 2.0的參考 - FFT窗口大小[email protected]/58(用於ARMv7+)幀

⑵ Android音頻播放

最近需要在Android的客戶端中使用PCM聲音播放和錄制,簡單學習了一下。有不正確的地方還請指出。

首先有幾個概念需要了解一下:采樣頻率、聲道數、采樣位數。

采樣頻率一般是sample rate, 代表的是數字化音頻時每秒采樣的次數。常見的有44.1KHz(CD品質)、48KHz等。

這個很好理解,單聲道Mono就是聲音從一個方向傳出來;雙聲道Stereo也叫立體聲,聲音是從兩個方向傳來。通常的流行音樂中,仔細聽能發現每個聲道可能側重不同的樂曲聲部,比如左聲道吉他,右聲道鋼琴,人聲似乎兩個聲道都有,聽起來就像站在中間一樣。(這里沒有考證,隨便舉例)

每一個采樣都是一個數據點,采樣位數是指這個數據點使用了幾位來記錄。AudioTrack類只支持8位和16位的PCM音頻。8位就是2的8次方,即256個值;而16位則是2的16次方,有65536個值。

這個在音頻的編解碼中還是比較常用的。在PCM格式中,1秒鍾音頻的數據大小是SampleRate×Channel×Bit/8,單位是byte位元組。由於PCM本身沒有音頻幀的概念,所以通過這個公式就能計算出任意時長音頻的大小,或者得到任意大小音頻的時長。如果規定1個音頻幀是「每個聲道256個采樣」,雙聲道下就是512個采樣,那麼1幀的數據量就是256×Channel×Bit/8,同理可以推斷出1秒鍾有多少音頻幀等等。音頻幀的概念在各種編解碼中各有不同,但計算公式大同小異,這里不展開。

Android中音頻的播放使用的是AudioTrack類,具體用法非常簡單。
首先設置buffer大小。AudioTrack播放時需要先寫入buffer,如果這個buffer沒有寫滿,那麼這部分是不會播放的。所以buffer不能設置太小,這樣會導致播放不連貫;而buffer也不能設置太小,這樣不間斷寫入會消耗許多CPU資源。AudioTrack自帶了getMinBufferSize方法可以給出一個最小buffer,一般用這個值就可以。getMinBufferSize方法三個參數分別是sample rate、channel和bit。

設置完buffer size就可以實例化一個AudioTrack。其中第一個參數streamType是指不同的音頻流類型,包括STREAM_MUSIC、STREAM_ALARM、STREAM_VOICE_CALL、STREAM_RING等,是Android對不同音頻的分類。中間三個參數很好理解,第四個是buffer size,剛剛計算出來了。最後一個參數mode有兩種:MODE_STREAM和MODE_STATIC。前者是以流形式播放,後者則是一次性全部寫入然後播放。

調用實例的play()方法就可以開始播放了。不過播放得要有數據吧?要填寫數據就要用到write()方法。write方法中第一個參數是一個byte[]類型,是要寫入的數據源,可以是從文件流中讀取出來的;第二個參數offset是初始位移,即從source的哪個位置開始;第三個參數則是輸入長度。

當write方法寫滿一個AudioTrack的buffer時,就會有聲音播放出來了。
當播放完成後記得要把AudioTrack停止並釋放。

⑶ android中怎麼對音頻數據pcm進行解碼

工程代碼結構較為簡單:

簡單說下思路,先把PCM音頻數據從指定的路徑文件讀到內存,然後給AudioPlayer設置數據源,音頻參數等,最後執行播放,暫停,停止等操作
貼上部分類代碼片段:
public class AudioParam {

int mFrequency; // 采樣率

int mChannel; // 聲道

int mSampBit; // 采樣精度

}

public interface PlayState {

public static final int MPS_UNINIT = 0; // 未就緒

public static final int MPS_PREPARE = 1; // 准備就緒(停止)

public static final int MPS_PLAYING = 2; // 播放中

public static final int MPS_PAUSE = 3; // 暫停
}

⑷ Android OpenGLES3繪圖 - 音頻可視化(模仿MIUI系統效果)

小米手機播放音樂時鎖屏頁面可以設置音頻可視化效果,這是用OpenGL繪制出來的,我們來實現一下。

首先簡單分析一下原理:
圖形的每一行代表一個聲音片段,它就是一個一維數組,按照數值大小繪制不同的高度,就形成了一條「山脈」;獲取到下一個聲音片段後,將它繪制到下面一行,然後畫面整體向上滾動就可以了。整體類似於繪制一張游戲里常見的3D地形圖。

創建一個MediaPlayer,它可以直接讀取res/raw裡面的音頻文件,start()開始播放

Visualizer是Android SDK裡面提供的音頻分析工具,它可以直接獲取播放的音頻的波形和頻譜。onWaveFormDataCapture回調方法里返回的是原始的PCM波形數組,onFftDataCapture回調方法里返回的是經過快速傅里葉方法轉換後的聲音頻譜數組,數組的第一位是直流分量,後面是不同頻率的數值。

每次獲取到的是一組聲音數據,將它傳給Render繪制。

首先確定圖形的長寬,寬度w其實是由每組音頻的數組長度決定,可以由Visualizer.getCaptureSizeRange()[0]獲取,這里獲取的是最小的數組,也可以用Visualizer.getCaptureSizeRange()[1]獲取最大的數組;長度h可以自己設置想展示多長。

繪制地形圖也就是繪制w * h * 2個三角形,創建vao、vbo和ebo,由於頂點的位置都是固定的,可以在頂點著色器中用gl_VertexID獲取,所以vbo裡面不用傳頂點數據,直接傳聲音數組。

由於圖形是不斷刷新最後一行並向上滾動的,那麼需要使用一個隊列,為了每一幀數據改變最小,不至於進行大量的數組復制和移動。我們 用ByteBuffer vertexBuffer模擬一個循環隊列,使用一個行號int lineNum來標記隊列的頭部。每添加一行數據後,lineNum會加上w,這樣ByteBuffer分成了兩部分:lineNum * w之後的是新舊數據,之前的是舊數據

現在我們需要將數據從主內存(vertexBuffer)復制到GPU顯存(vbo)。vertexBuffer里是一個循環隊列,而vbo裡面只能順序保存(因為ebo序號是順序的,vbo不是順序圖形就會錯亂),更新vbo數據緩存的glBufferSubData方法支持設置偏移位置部分更新。那麼我們 先將vertexBuffer定位到lineNum * w,將它後面的舊數據復制到vbo的前面;然後將vertexBuffer定位到0,將剩下的新數據復制到vbo的後面 。這樣就保證了繪制時從上到下,從舊到新。

為了讓顏色更豐富,這里用了地形圖中常用的熱度漸變色數組。
理論上音頻數值是unsigned byte格式的,但是著色器不支持byte格式,我直接用int vPosition接收數據,然而數值范圍不再是0~255了,這有點奇怪,我沒有深入研究。簡單測試了一下,發現取int的前8位,再進行一點比例縮放,用它去漸變色數組里取顏色,會取得較好的顯示效果。

頂點著色器
shader_audio_v.glsl

將顏色傳給片段著色器顯示
shader_audio_f.glsl

最終效果如下圖,錄屏設置的碼率比較低,實際上是很清晰的。

完整項目在 SurfacePaint 項目下的 opengles3 模塊里的audio。

⑸ android里如何解析音頻文件獲取標題、專輯、文件名、藝術家

如果有的話,用WMP播放就可以看見了

安卓系統為什麼音質不好

Android 基於Linux,我們先來了解一下Linux的特點。Linux使用ALSA作為其音頻架構,其全稱Advanced Linux Sound Architecture,即高級Linux聲音架構的意思,在2.6核心之後,ALSA成為了Linux系統默認的音頻子架構。取代了之前的OSS[Open Sound System,開放式聲音系統]。

ALSA並不太好理解,它首先是一個驅動庫,包含了大量的音效卡設備的開源驅動,並提供了核心層API與ALSA庫通信,而ALSA庫則是應用程序訪問和操控音頻硬體的中間層,這個中間層有標准介面,開發者可以無須考慮硬體差異性進行開發,它對提升開發效率是大有幫助的。ALSA可以向下兼容OSS,因為OSS已經被淘汰,其兼容的工作模式不再討論。

這個體系被繼承到了Android當中。在Android2.2[含2,2]之前,系統文件夾中能找到一個LibAudioALSA.so的文件,這就是ALSA庫文件,其他應用程序調用它,與音效卡設備進行指令和數據通信。Android音頻架構與Linux的並無本質區別。

在桌面版本的Linux當中,為了兼容各類音效卡,Linux也設置了一個SRC[Sample Rate Converter,采樣頻率轉換]的環節,當當前采樣率低於48kHz時強制SRC到48kHz輸出。這個SRC環節位於ALSA的插件模塊中的混音器部分。Android針對這個進行了改進。
什麼是SRC?SRC即Sample Rate Converter,中文意思為采樣頻率轉換。它被音效卡愛好者所關注,大部分發燒友視SRC為音質殺手。

Android增加了一個AudioFinger,這個可以簡單的理解為Android的ALSA音頻子系統的標准化的插件模塊,它包含了AudioMixer[混音器]、AudioResampler[重采樣]等子模塊,AudioResampler即我們理解的SRC,Android換了一個新名稱而已。針對SRC,Android做了改進,但改進並不是以去除SRC為目的,而是修改了默認的輸出頻率,Android的SRC目標采樣率為44.1kHz,非該值的采樣率都將SRC處理。例如播放48kHz采樣率的信號,輸出的最終是44.1kHz,這對音質將產生負面影響。

ALSA是一個針對Linux 桌面版本設計的音頻架構,它實際上是不適合智能終端設備的,起碼裡面大量的開源驅動代碼是可以去除的,對與Android來說,這些都是廢代碼。從Android2.3起,啟用了一個新的音頻架構。它放棄了一直使用的ALSA架構,因此系統文件夾中,也不再有LibAudioALSA.so這個文件。

Android2.3起,架構已經做了修改,在針對內部代碼進行了優化,去除了冗餘代碼,理論上讓系統能變得更加高效,可以將新架構理解為一個精簡的或者為智能終端設備定製的ALSA架構。遺憾的是,它同樣存在SRC嚴重劣化的問題,通過測試可以證明。
Android 3.0專門為平板電腦設計,影音體驗變得更加重要了,是不是新系統在音質方面會有新的的進步呢,測試結果依然是令人失望的。

Android系統將采樣率同一為44.1kHz輸出,這造成了諸多限制,它將無法實現96kHz、192kHz高清音頻節目的良好回放,大量視頻節目源自DVD或者藍光碟,其採用率多為48kHz,Android設備在回放這些視頻節目時,音質也將大打折扣。

理論上軟體SRC可以通過更換演算法來實現音質提升,但卻不太現實,智能終端所採用的CPU多為ARM,ARM晶元的浮點運算力有限,而SRC需要大量的浮點運算的資源,即便有了高質量的SRC演算法,其運算也是以犧牲設備性能和耗電量為代價的,實用性差。

從Android的音頻架構及流程分析,可以認為,播放44.1kHz采樣率的音樂節目時,不會引發SRC,音質因此可以獲得保證,理論上確實如此。但它同樣存在問題,不管是之前的ALSA架構還是Android2.3之後改良的架構,其驅動庫都位於核心層,也就意味著音頻設備廠商、用戶無法象PC平台那樣安裝驅動來改善音質。實際測試也表明,Android設備音質普遍偏差,Soomal有大量測試可以證明。

我們再把目光投向iOS,iOS非常封閉,我們甚至無法獲知其架構的具體構成,但iOS設備不存在硬體設備多樣性的問題,因此要實現更好音質也會更加簡單。iOS可以實現針對性的開發和改良,以實現更好的音質。實際情況也是如此,目前為止,還沒有一款Android設備的音質可以媲美任意一款iOS設備,這種差距,我們認為不是來自硬體,而是操作系統。

Android音頻架構的局限性也使得其難以成為優質的影音平台,如果你希望設計一款基於Android的高清影音播放器,那麼首先需要做的不是設計硬體,而是去修改現有架構的不足,或者乾脆設計一個專用的架構來取代Android的通用架構。從源代碼分析,Android和原生的Linux底層能支持各種采樣率,開源也使得其具有改造基礎,因此,在技術實力強勁的公司手裡,Android也可以烏雞變鳳凰。

⑺ Android音視頻三:AudioFlinger和HAL

先看看和Audio有關的hal文件 具體路徑/hardware/interfaces/audio/文件夾下(這里看的是6.0的)

在分析AudioFlinger的時候留下的和HAL有關的三個地方

DevicesFactoryHalInterface.cpp

FactoryHalHidl.cpp

DevicesFactoryHalHybrid.cpp

DevicesFactoryHalHidl.cpp

經過上面的步驟已經可以調用到IDeviceFactory的方法了,所以執行方法也就是走流程的事情

DevicesFactoryHalHybrid.cpp

DevicesFactoryHalHidl.cpp

DeviceFacotry.cpp

調用流程:AudioFlinger -> AudioHwDevice -> AudioStreamOut -> DeviceHalHidl -> Device.cpp -> audio.h 得到結果:拿到輸出流後,包裝成IStreamOut,在向上一層層包裝

AudioFlinger.cpp

AudioHwDevice.cpp

AudioStreamOut.cpp

DeviceHalHidl.cpp

⑻ android里如何解析音頻文件獲取標題、專輯、文件名、藝術家

把文件放在res/raw下,程序運行時把它釋放到指定目錄,代碼如下:(供樓主參考)

private final String DATABASE_PATH = android.os.Environment.getExternalStorageDirectory().getAbsolutePath() + "/db_exam";
private final String DATABASE_FILENAME = "tel.db";

public void extractDBFileFromRes(){
try {
String dbFileName = DATABASE_PATH + "/" + DATABASE_FILENAME;
File dir = new File(DATABASE_PATH);
if (!dir.exists()){
dir.mkdir();
Log.i("SQLite", "dir made:" + DATABASE_PATH);
} else {
Log.i("SQLite", "dir exist:" + DATABASE_PATH);
}

try {
//如果資料庫已經在SD卡的目錄下存在,那麼不需要重新創建,否則創建文件,並拷貝/res/raw下面的資料庫文件
if (!(new File(dbFileName).exists())){
Log.i("SQLite", dbFileName + ":file not exist");
//res/raw資料庫作為輸出流
InputStream inputStream = this.getResources().openRawResource(R.raw.tel);
//測試
int size = inputStream.available();
Log.i("SQLite", "DATABASE_SIZE:" + 1);
Log.i("SQLite", "count:" + 0);
//用於存放資料庫信息的數據流
FileOutputStream fileOutputStream = new FileOutputStream(dbFileName);
byte[] buffer = new byte[8192];
int count = 0;
Log.i("SQLite", "count:" + count);

//把數據寫入SD卡目錄下
while ((count = inputStream.read(buffer)) > 0 ) {
fileOutputStream.write(buffer, 0, count);
}
fileOutputStream.flush();
fileOutputStream.close();
inputStream.close();
}

} catch (FileNotFoundException e) {
Log.e("Database", "File not found");
e.printStackTrace();
}
} catch (IOException e) {
Log.e("Database", "IO exception");
e.printStackTrace();
}

}

⑼ 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中可以提取視頻文件中的音頻嗎

怎麼樣才可以將視頻中的一些音頻提取出來呢?把視頻中有趣的音頻提取出來有難度嗎?其實操作非常的簡單哦!不管是視頻音頻或者是音樂音頻都是可以提取的,那麼接下來就好好和你們說說如何提取音頻的吧!具體操作步驟如下:
第一步提取視頻音頻之前,需要安裝一款迅捷音頻轉換器
第二步打開後你們就會看到它的整體界面,在界面中會有一些功能,這些功能在我們的日常工作中都會遇到,今天我們需要點擊的就是音頻提取,接著添加文件或者添加文件夾。
第三步文件添加進去之後,提取音頻的步驟來了,大家會看到添加片段指南,怎麼添加呢?拉動上方的進度條就可以添加了,這個時候你們所看到的當前時間點顯示的就是你添加音頻的時間,然後點擊確定。
第四步在我們點擊確定之後,我們就要來到界面的地步,看到文件輸出目錄點擊文件夾就可以選擇保存的位置了,當我們的保存位置設置好之後,最後點擊開始提取。
第五步等待一會之後,界面你提取的音樂片段都會顯示個小對號,這個時候你們的提取已經完成了,然後在你們的保存的文件中就可以打開了。

熱點內容
監控腳本實用 發布:2022-11-30 14:14:28 瀏覽:377
九陰真經顯血腳本 發布:2022-11-30 14:14:22 瀏覽:197
浪潮伺服器mgn口地址 發布:2022-11-30 14:13:41 瀏覽:821
linux鎖屏設置 發布:2022-11-30 14:08:20 瀏覽:896
演算法轉讓 發布:2022-11-30 14:07:24 瀏覽:24
我的世界為什麼從伺服器斷開連接 發布:2022-11-30 14:07:04 瀏覽:432
怎麼擠出母乳存儲袋中的空氣 發布:2022-11-30 14:05:32 瀏覽:33
linuxbin文件 發布:2022-11-30 14:01:19 瀏覽:481
購物網站源碼php 發布:2022-11-30 13:58:15 瀏覽:475
python執行java 發布:2022-11-30 13:56:23 瀏覽:942