問題背景:git
這個公衆號已經發了十幾篇文章,閱讀量和訂閱數也在穩定增加。爲了後面你們交流更順暢,大概知道每篇文章在音視頻技術體系的位置。
利用週末畫了個腦圖,梳理了下音視頻核心技術體系,固然這張圖不會包含全部流媒體的技術,若是有遺漏,你能夠私信我。我會在後面
補充和豐富起來,讓進門的小白能找到本身的位置,贈人玫瑰,手留餘香。github
下面用兩張圖來構建音視頻技術人交流的行話,讓你快速找到在整個流媒體技術體系所處的位置。
音視頻核心技術體系:
架構
音視頻數據必定是從採集的原始數據,通過前處理,再通過編碼造成壓縮後的數據。壓縮後的數據爲了發送出去,因此須要把壓縮後的音視頻裸數據打包在一個容器,這就是封裝要作的事情。封裝後的數據經過必定的傳輸協議發送到客戶端,不一樣的傳輸協議有不一樣的業務場景和適合本身的音視頻封裝格式。播放客戶端要作的事情恰好是逆過程,先判斷封裝格式 ,再從容器中將音視頻數據分離提取出來,最後進行解碼和渲染到屏幕上。學習
研究音視頻整個系統是一件有門檻的事情,剛進門時須要找準本身的位置,把本身這塊的輸入和輸出搞清楚,再逐漸橫向擴展。WebRTC初學者就發現裏面的內容不是 一時半會能研究透徹的,這是由於WebRTC就是一個流媒體系統的解決方案,而不是爲了解決音視頻一個特定問題。這個公衆號就是先學習WebRTC下面的邊邊角角,最後再上升到WebRTC代碼內部進行系統性學習,但願你們耐住性子慢慢來,一點點的理解RFC文檔,這樣我相信能走得更遠點,讓你們知其然還知其因此然。編碼
音視頻系統架構圖:
[](https://github.com/ty6815/WeC...spa
重要事情說三遍,解決問題時,必定要明白本身問題在這個圖的位置。這樣抓住輸入和輸出,就能達到事半功倍的效果。視頻
我的轉載內容至朋友圈和羣聊天,無需特別申請版權許可。
引用轉載該訂閱號文章,註明文章來源便可。
https://github.com/ty6815/WeC...文檔
往期文章回顧:
音視頻封裝:FLV格式詳解和打包H26四、AAC方案(下)get
音視頻封裝:FLV格式詳解和打包H26四、AAC方案(上)it
我的轉載內容至朋友圈和羣聊天,無需特別申請版權許可。記得右下角點「在看」,還能夠關注該訂閱號,防止遺漏推送哦!公衆號:智媒黑板報