標籤:

視頻技術總覽

在2016年終總結的時候,定了一個目標是「開始寫技術博客,不在多,但要寫,並且保證質量」。那就開始吧。本文是一個總綱,後續會有細節技術的分享。

從讀研開始接觸H.264,到現在,做音視頻相關的技術,已有六年多的時間了。不得不承認,音視頻底層的編解碼技術是晦澀難懂的,入門不易。工作上來說,也是一個比較小眾的方向,要不是最近直播火爆的帶動,也就只有一些專業的大公司,才會高薪找音視頻編解碼方面的人才。

我個人認為,整個音視頻技術的知識架構可以分為四個層次,編解碼,文件層,協議層,和客戶端(Android、iOS、PC)。很多實際應用可能不一定包含全部,但是就整個知識體系的完整度來說,差不多就這四個層次。

以離線(Off-line)轉碼為例,包含編解碼層和文件層。

編解碼器(Video Encoder和Video Decoder)

音頻的編解碼(Audio Encoder和Audio Decoder)不在討論範圍。

其實在公司里,對編解碼器比較蔑視,或者說對你在它上面投入的海量時間存在懷疑,覺得沒什麼難度,其實這是個誤區,因為別人已經把演算法研究成果,碼流框架都定義好了,你僅僅是實現而已。其實,編解碼器的研究很難,並且可以做的很深,而且是跨學科的,需要深厚的數學功底。全世界很多知名的科研院所,頂尖的人才,不斷的在優化現有的演算法,發表在頂尖的學術期刊上以及提交成MPEG標準。

國內大部分需要用到編解碼器的公司,(國外不清楚,知乎有很多國外的大神,自動略過),要麼直接用開源的,比如H.264用x264或者OpenH264,要麼在開源的基礎上優化開發,所以對學校里研究視頻編解碼內部演算法的同學,其實是不太有利的,因為公司從成本的考慮,不會也沒必要重複造輪子,這就一下子減少很多的崗位需求。

而且,對於移動端來說,Android和iOS都有硬編解碼,一般情況下會優先選用。還有一些公司是需要專門的編解碼晶元實現的,比如HIKVISION等視頻監控公司。

對此感興趣的同學,學習方法是對照視頻編碼標準和對應代碼一步一步學習即可,網上也有很多技術博客幫助你分析代碼的。

以下網址是最基礎的存在,無論如何,如果你想深入研究視頻編解碼,請務必不要忽視它們。

H.264標準:Advanced video coding for generic audiovisual services

H.264官方校驗平台:iphome.hhi.de/suehring/

著名的x264:x264, the best H.264/AVC encoder

Cisco的OpenH264:OpenH264

H.265標準:High efficiency video coding

H.265官方校驗平台:hevc.hhi.fraunhofer.de/

Android MediaCodec:

developer.android.com/r

iOS VideoToolbox:VideoToolbox | Apple Developer Documentation

文件層

封裝(Muxer)、解封裝(Demuxer),是在編碼、解碼環節的上一層。對於封裝和解封裝,採用ffmpeg,是幾乎所有創業公司的選擇。當然,有一些技術積累比較厚的公司,是根據封裝標準,自己研發的,比如我所知道的ArcSoft。

對於大部分公司來說,特別是創業公司,基本就是使用MP4、FLV和TS這幾種常用的封裝格式,ffmpeg是足夠滿足自己需求的,而且使用也特別方便,幾個API函數,例子也都寫好了,只要依葫蘆畫瓢就可以了。

這裡面比較多的問題是,有些應用場景會有大量千奇百怪的輸入文件,要兼容出錯的文件(大部分應用情形都不會碰到),比如廣電系統的轉碼輸入文件就有大量的各種來源途徑,以及音視頻同步問題等。

協議層

涉及到網路傳輸,因為網路的不可靠性,音視頻這一塊的問題還是比較多的,而且大部分問題也都是集中在這一塊,比如丟包處理,碼率自適應等。這方面的東西,寫幾本書都不一定寫的完。

常見情形,視頻會議、視頻監控一般都會選擇RTP/RTCP,

視頻直播一般會選擇RTMP:Real-Time Messaging Protocol (RTMP) specification

蘋果的HLS也是繞不開的:HTTP Live Streaming

客戶端

Android端,採集,編碼,解碼,系統的幾個API搞清楚,已經可以實現功能了,也有很多輪子可以借鑒,當然MediaCodec裡面有很多坑需要填。iOS端問題會少很多。圖像處理(美顏等)使用OpenGL ES,這個現成有輪子可以用,比如GPUImage。

個人感覺很大部分創業公司的招聘需求其實也就集中在這一塊的知識點上。


推薦閱讀:

TAG:音視頻 |