近期對流媒體技術的思考

點擊上方“LiveVideoStack”關注我們


作者 | 劉歧

很久沒有更新公衆號內容了,主要是想分享一些具體技術之外的內容,但是想到這是個流媒體技術號,分享其他東西也不太合適,直到 Joe Li 兄臺提醒我很久沒有分享內容了,我突然意識到自己應該是怠惰了,應該勤奮一些,爲大夥多分享一些技術內容,不過今天我還是沒忍住,破例在技術號灌個水吧。

從年初到現在跟各領域的朋友們交流後對幾個大夥頻繁聊起的方向做了一些思考,主要分享的信息內容如下:

  1. 音視頻流媒體技術對計算機技術新人不友好?

  2. 開源技術商業化前景如何?

  3. 音視頻流媒體技術的開源商業化前景如何?


在開始分享之前,我先多說幾句。

近幾年觀察國內的音視頻流媒體技術羣體,其實依然還是小衆羣體。跟成立,連響,包老闆,趙委員,杜老師我們常在一起分析音視頻技術與其他技術的差別。其實如果仔細想想,技術羣體比較發達的主要是這麼幾個方向,我看到的比較火熱的部分:

  1. 雲計算、K8S、雲存儲等,以前還有OpenStack,CloudStack等,也許還有區塊鏈技術

  2. 大數據ELK(可能我已經Out,但是大體上可以理解是大數據那個羣體)

  3. 數據庫,關係型數據庫,非關係型數據庫,GraphSQL等


以上是聽到的比較火熱比較多的熱詞,但是瞭解並不是特別多,也並不是我重點關注的方向,所以理解難免會有片面,那就片面的歸納一下特點。

這些羣體有幾個共同的特點:

  1. 有最終受惠用戶(比如我們作爲網銀用戶、看劇用戶)

  2. 有一定專業操作但是不會用代碼修改內部實現的維護者(可能叫運維、也可能叫DBA)

  3. 有一定代碼能力並且能夠修改、優化、設計內部實現的開發者(不論是原創還是參與代碼級別貢獻)


這樣的羣體用漏斗型來形容可能也算是比較貼切,人員數量從最終受惠用戶到開發者收口,最後代碼級別維護者就是漏斗最下面那部分的人羣,這樣的狀態看上去比較健康,有開發者,有非開發的維護者,有最終受惠用戶,而且羣體比較大,所以天花板看上去會高一些。 開發者也可以根據自己的想法做各種調整然後優化,所以可玩性比較多。

1.音視頻流媒體技術對計算機技術新人不友好?
    
音視頻流媒體技術對新人並不是不友好,其實是門檻可見,只不過這個門檻對於很多新人來說不喜歡,甚至避之而不及,並不是說這麼做是錯的,只是這是一個篩選音視頻開發技術人員的最好的自然門檻,如果大膽嘗試跨這個門檻的話,他就相當於毫無門檻,但是如果真的迴避了或者繞行了,那就真的是個門檻了,而且門檻還很高。舉個最簡單的例子,Nginx大家都用,大家很多人或多或少的看過Nginx的代碼,但是又有幾個人照着Nginx的代碼重頭到尾實現過一遍呢?哪怕是早期的Nginx版本,這就沒那麼多人了,所以從頭到尾實現過一遍的那些人,在實現的過程中遇到了問題,去學習解決問題,去思考爲什麼這麼做等問題,自然就學習到了很多東西。音視頻也是一樣,只不過大多數情況下是對照着參考標準去實現,爲什麼呢?因爲音視頻這個領域有很多參考標準,而這些參考標準如果你不去對照着參考標準去解析的話,將不會成功的把音視頻數據從封裝中讀取出去,這個封裝可以理解就像是Linux系統下面的打包工具tar一樣,tar我們打包的時候只要這麼操作就可以了:

   
   
   
打包 tar cf package.tar dir 解包 tar xf package.tar

注意,這是打包和解包,並不壓縮。只不過音視頻領域的打包姿勢各有不同,有微軟的姿勢,有real公司的姿勢,有Apple的姿勢,有ITU的姿勢,有RFC的姿勢,有Adobe的姿勢,還有……怎麼樣?是不是突然覺得姿勢挺多的?沒錯,就是姿勢多。新人不需要全做一遍,但是至少自己生活的土壤中還是要將常用的打包和解包的姿勢學會,否則很難有入門的感覺,遇到問題也無法解決。

而壓縮呢?還是用tar來舉例:

   
   
   
打包並壓縮 tar cjf package.tar.bz2 dir 解包並解壓縮 tar xjf package.tar.bz2

用過tar的人都知道,這麼做可以壓縮成bzip2的包,如果這麼解包與解壓縮的話肯定是會報錯的:

   
   
   
tar xzf package.tar.bz2

因爲這個是解壓縮gunzip的壓縮包,用來解壓縮bzip2的話算法是對不上的。沒錯,壓縮與解壓縮的姿勢也需要對得上,音視頻也一樣,只不過這個壓縮與解壓縮的姿勢比較多而已,而且也涉及到新舊交替的週期比較長。例如H.264壓縮到H.265(HEVC),現在還有H.266(VVC),除了H.2xx的姿勢,還有VP6、VP8、VP9、AV1、AV2等姿勢。如果打包與解包的姿勢對了,還想繼續深入一些的話,這些姿勢能自己實現一遍也需要對着參考標準實現一遍,才能夠理解得比較透徹,否則真的比較難跨過編解碼的門檻了。

除了封裝與解封裝、編碼與解碼之外,還有傳輸協議的理解,如果不親自對着參考標準實現一遍的話,理解起來也會有一定的偏差,例如HTTP、例如RTSP/RTP/RTCP、例如RTMP、例如QUIC、例如SRT等等。這些都理解得差不多的時候,恭喜你,已經很完美的騎在這個門檻上了,至於另一條腿是否能夠進入到這個門檻裏面,真的就需要多在工作中實踐,踩坑了。

所以請注意:

/如果你身邊有一個從事音視頻技術開發的朋友、同事,請珍惜和他的友誼,因爲他對音視頻技術確實是真愛,而且是深愛的那種,經歷過這種門檻的程序員並不多,因爲這種門檻如果只是爲了掙錢並非愛好的話,他真的在看不到未來的時候就放棄了。/

2.開源技術商業化前景如何?
    
我不是個商人,只是個開源技術愛好者,也並不是一個成功將技術商業化的創業者。本經陰符七術養志法中也有說過“欲多則心散,心散則志衰,志衰則思不達也”,諸葛武侯的誡子書也說過“非淡泊無以明志,非寧靜無以致遠”。如果作爲開源技術開發者,主要精力其實更應該集中於如果將開源社區運營好,因爲要應對伸手黨、白嫖黨、Review貢獻者的代碼、跟開發者們交流功能的可行性、性能優化的姿勢等,還要推廣自己的開源程序,這就相當於做市場,任何一個開源軟件其實都需要做市場宣傳,酒香也怕巷子深,因爲人家不一定去巷子口,人家去的是豪華大酒店。Linux開源軟件也在不斷地宣傳和推廣,FFmpeg也在推廣(例如NTTW這種,主要是面向圖書館,博物館的數字化羣體),開源軟件很多時候不一定必須面向程序員,不一定非要面向計算機技術從業者,跨界也是需要的,思路還是要打開的。

但是做了這麼多,主要還是在花錢,既然要商業化主要目標還是應該是在掙錢方面,可是開源社區做的事大多數情況下確實是在利他,想法其實也沒有那麼多的。如果非要加入到收入方面的考慮,市場佔有率方面的考慮的話,是不是社區就會被金錢所污染?會不會就不那麼純粹了呢?目前從事開源的大多數是因爲愛好,如果加入了金錢的元素後,如何判斷是爲了賺錢多一些還是爲了利他多一些呢?如果資金鍊斷了或者沒有金錢繼續注入的話,這個開源社區是否還能夠繼續進行下去嗎?我理解的是沒有標準答案,因爲不同的個人站在的位置不同,給的結論應該也不一樣,但是確實這對我來說是一個疑問。因爲現在從事計算機這個行當的好多人我確實已經無法確認他們到底是爲了掙錢還是真的是愛好了,只是流媒體開發者這個羣體中真正的愛好者目前看還是能篩選出來的,因爲投入產出不成正比,學習投入成本比較高,收益又不一定有多少,不像是前端開發那樣大多數情況下可以速成,所以大多數還是真愛。

3.音視頻流媒體技術的開源商業化前景如何?

正如前面提到的背景中,音視頻這個行當的門檻若有若無,導致了從業者的羣體並不是特別多,所以各大公司招聘人才的時候會明顯的發現音視頻流媒體專業的人就那麼點,而且主要是開發者,也就是漏斗下面那一部分。音視頻領域沒有DBA這樣的角色,沒有IT運維工程師這樣的角色,最終受惠用戶遇到問題的時候,問題第一個落腳點就是開發者身上,很顯然缺少了DBA,運維工程師這樣的羣體。加之本來羣體也不大,所以這部分還需要繼續深度發展一段時間,主要是需要有一個像數據庫,雲計算,大數據等這樣的健康一點的生態,門檻稍微降低一些,讓更多的人蔘與進來才更適合談商業化前景。

寫在最後

總結,當前音視頻流媒體技術建設方面,由於前面講述的各種斷層、羣體差異性、若隱若現的門檻的存在。團隊的穩定性是重中之重,大多數決策層並不是很在意這樣的穩定性,因爲在潛意識中存在的理念是沒有人是無法替代的,但是容易忽略一個事實,那就是音視頻技術在不同的應用場景會存在位置不同的坑,沒有誰是絕對正確的,也沒有誰是絕對錯誤的,只不過踩過的坑的位置存在不同,前人踩過的坑,新來一個人有很大的可能性也會再踩一次,經驗特別充足的人又不一定會親自去踩某些坑,這樣就需要爲不穩定的團隊結構而買單了。比如某擁抱變化的公司,時不時調整一下,這樣其實不太利於音視頻技術的沉澱的,所以某些時候服務並不像某司那麼穩定,再比如某司的視頻雲團隊就比較穩定,並且還不斷有經驗充足的人加入進行能力補充,服務也是眼看着越做越穩定,差別還是可見的。

本文來源:




掃描圖中 二維碼 或點擊 閱讀原文
瞭解大會更多信息



喜歡我們的內容就點個“在看”吧!

本文分享自微信公衆號 - LiveVideoStack(livevideostack)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章