實時音視頻技術(WebRTC/voip)


用MediaCodec實現多段視音頻的截取與拼接- http://blog.csdn.net/qq_29028177/article/details/69371906
Android提供的MediaCodec及其相關類為我們提供了所需的方法,這些類主要包括:MediaCodec、MediaExtractor、MediaMuxer、MediaFormat。
 MediaCodec用於創建視音頻編解碼器,通過它可以對視音頻數據進行編解碼操作,它是編解碼功能的核心類。
 MediaExtractor相當於一個reader,它用於讀取媒體文件,並提取出其中的視音頻數據。
 MediaMuxer相當於一個writer,它用於將內存中的視音頻數據寫到文件中。
 MediaFormat即媒體格式類,它用於描述媒體的格式參數,如視頻幀率、音頻采樣率等。

 多媒體技術團隊在音視頻編解碼、前后處理、傳輸等技術;WebRTC 包含了一套完整的實時音視頻應用的開源解決方案
 高清低碼視頻;回聲消除技術:開源的項目有WebRTC和Speex

 如果是僅僅優化首開延遲,可以在視頻幀間插入較多的關鍵幀,這樣客戶端收到視頻流之后可以盡快解碼。但如果需要優化傳輸過程中的累計延遲,盡可能少使用關鍵幀也就是 I 幀(GOP 變大),在保證同等視頻質量的情況下,I 幀越多,碼率越大,傳輸所需的網絡帶寬越多,也就意味着累計延遲可能越大。這個優化效果可能在秒級延遲的系統中不是很明顯,但是在 100 ms 甚至更低延遲的系統中就會非常明顯。同時,盡量使用 ACC-LC Codec 來編碼音頻,HE-ACC 或者 HE-ACC 2 雖然編碼效率高,但是編碼所需時間更長,而產生更大體積的音頻造成的傳輸延遲對於視頻流的傳輸來說影響更小。

 移動端實時音視頻直播技術詳解(六):延遲優化- http://www.52im.net/thread-972-1-1.html
視頻處理如模糊效果、水印等
 Android 也有 GPUImage 這個庫的移植,叫做 android-gpuimage。同時,Google 官方開源了一個偉大的庫,覆蓋了 Android 上面很多多媒體和圖形圖像相關的處理。

目前比較好的開源播放器是基於 ffplay 的 ijkplayer

移動端實時音視頻直播技術詳解- http://www.52im.net/thread-955-1-1.html
  視頻的采集涉及兩方面數據的采集:音頻采集和圖像采集,它們分別對應兩種完全不同的輸入源和數據格式。 
  音頻數據既能與圖像結合組合成視頻數據,也能以純音頻的方式采集播放,后者在很多成熟的應用場景如在線電台和語音電台等起着非常重要的作用。音頻的采集過程主要通過設備將環境中的模擬信號采集成 PCM 編碼的原始數據,然后編碼壓縮成 MP3 等格式的數據分發出去。
  音頻跟視頻很不一樣,視頻每一幀就是一張圖像,而從上面的正玄波可以看出,音頻數據是流式的,本身沒有明確的一幀幀的概念,在實際的應用中,為了音頻算法處理/傳輸的方便,一般約定俗成取 2.5ms~60ms 為單位的數據量為一幀音頻。這個時間被稱之為“采樣時間”,其長度沒有特別的標准,它是根據編解碼器和具體應用的需求來決定的;
  圖像的采集過程主要由攝像頭等設備拍攝成 YUV 編碼的原始數據,然后經過編碼壓縮成 H.264 等格式的數據分發出去。

 視頻采集,對於專業攝像機或者攝像頭,此SDK提供了兼容適合嵌入式系統的 C 語言采集模塊的實現,僅供參考:https://github.com/pili-engineering/ipcam_sdk
  屏幕錄制采集的方式在游戲直播場景中非常常見,目前我們在 Android SDK 中實現了屏幕錄制的功能。而 iOS 則由於系統本身沒有開放屏幕錄制的權限而沒法直接操作,但對於 iOS 9 以上的版本,是有個取巧的辦法,可以通過模擬一個 AirPlay 鏡像連接到(當前 App)自身,這樣就可以在軟件上捕獲到屏幕上的任何操作,達到錄制屏幕的效果。

 滿足市場上主播的各種需求如美顏、水印、連麥互動等,如美顏、視頻水印、濾鏡、連麥等。如打上時間戳或者公司 Logo 的水印,祛斑美顏和聲音混淆等處理。

 視頻采集針對音頻采集和圖像采集以及它們分別對應兩種完全不同的輸入源和數據格式。 

 七牛的直播Demo:
iOS SDK 地址:https://github.com/pili-engineering/PLMediaStreamingKit
Android SDK 地址:https://github.com/pili-engineering/PLDroidMediaStreaming

 美顏的主要原理是通過「磨皮+美白」來達到整體美顏的效果。磨皮的技術術語是「去噪」,也即對圖像中的噪點進行去除或者模糊化處理,常見的去噪算法有均值模糊、高斯模糊和中值濾波等。當然, 由於臉部的每個部位不盡相同,臉上的雀斑可能呈現出眼睛黑點的樣子,對整張圖像進行「去噪」處理的時候不需要將眼睛也去掉,因此這個環節中也涉及到人臉和皮膚檢測技術。

 水印是圖片和視頻內容中常見的功能之一,它可用於簡單是版權保護,或者進行廣告設置。處於監管的需求,國家相關部門也規定視頻直播過程中必須打上水印,同時直播的視頻必須錄制存儲下來保存一定的時間,並在錄制的視頻上打上水印。

 視頻水印包括播放器水印和視頻內嵌水印兩種方式可供選擇,對於播放器水印來說,如果沒有有效的防盜措施,對於沒有播放鑒權的推流,客戶端拿到直播流之后可以在任何一個不帶水印的播放器里面播放,因此也就失去了視頻保護的能力。綜合考慮雲端錄制對於水印的需求,一般來說會選擇「視頻內嵌水印」的方式打水印。

 常見的濾鏡效果GPUImage 地址:https://github.com/BradLarson/GPUImage。
除了 iOS 端之外,Android 也有 GPUImage 這個庫的移植:https://github.com/CyberAgent/android-gpuimage。
同時,Google 官方也開源了一個偉大的庫,覆蓋了 Android 上面很多多媒體和圖形圖像相關的處理:https://github.com/google/grafika。

連麥是互動直播中常見的需求。
互動直播的主要技術難點在於:
  低延遲互動:保證主播和互動觀眾之間能夠實時互動,兩者之間就像電話溝通,因此必須保證兩者能在秒級以內聽到對方的聲音,看到對方的視頻;
  音畫同步:互動直播中對音畫同步的需求和單向直播中類似,只不過互動直播中的延遲要求更高,必須保證在音視頻秒級傳輸情況下的秒級同步;
  音視頻實時合成:其他觀眾需要實時觀看到對話結果,因此需要在客戶端或者服務端將畫面和聲音實時合成,然后以低成本高品質的方式傳輸觀眾端。

 對於互動人數比較少的互動直播,目前市場上比較成熟的方案是使用基於 WebRTC 的實時通訊方案。基於該方案可以輕松實現多人(14 人以下)的多方實時通信

 視頻編碼是本系列一個重要的部分,如果把整個流媒體比喻成一個物流系統,那么編解碼就是其中配貨和裝貨的過程,這個過程非常重要,它的速度和壓縮比對物流系統的意義非常大,影響物流系統的整體速度和成本。同樣,對流媒體傳輸來說,編碼也非常重要,它的編碼性能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的用戶體驗和傳輸成本。

 視頻本質上講是一系列圖片連續快速的播放,最簡單的壓縮方式就是對每一幀圖片進行壓縮,例如比較古老的 MJPEG 編碼就是這種編碼方式,這種編碼方式只有幀內編碼,利用空間上的取樣預測來編碼。形象的比喻就是把每幀都作為一張圖片,采用 JPEG 的編碼格式對圖片進行壓縮,這種編碼只考慮了一張圖片內的冗余信息壓縮

H.264 的開源實現:OpenH264、x264:
  OpenH264 是思科實現的開源 H.264 編碼,雖然 H.264 需要交納不菲的專利費用,但是專利費有一個年度上限,思科把 OpenH264 實現的年度專利費交滿后,OpenH264 事實上就可以免費自由的使用了。
  x264 是一個采用 GPL 授權的視頻編碼自由軟件。x264 的主要功能在於進行 H.264/MPEG-4 AVC 的視頻編碼,而不是作為解碼器(decoder)之用。

除去費用問題比較來看:
OpenH264 CPU 的占用相對 x264低很多;
OpenH264 只支持 baseline profile,x264 支持更多 profile。

H.265 的開源實現:libde265、x265:
  libde265 HEVC 由 struktur 公司以開源許可證 GNU LesserGeneral Public License (LGPL) 提供,觀眾可以較慢的網速下欣賞到最高品質的影像。跟以前基於H.264標准的解碼器相比,libde265 HEVC 解碼器可以將您的全高清內容帶給多達兩倍的受眾,或者,減少 50%流媒體播放所需要的帶寬。高清或者 4K/8K 超高清流媒體播放,低延遲/低帶寬視頻會議,以及完整的移動設備覆蓋。具有「擁塞感知」視頻編碼的穩定性,十分適合應用在 3/4G 和 LTE 網絡。
  x265 是由 MulticoreWare 開發,並開源。采用 GPL 協議,但是資助這個項目的幾個公司組成了聯盟可以在非 GPL 協議下使用這個軟件。

編碼器的選擇之VP8:
  VP8 是一個開放的視頻壓縮格式,最早由 On2 Technologies 開發,隨后由 Google 發布。同時 Google 也發布了 VP8 編碼的實做庫:libvpx,以 BSD 授權條款的方式發行,隨后也附加了專利使用權。而在經過一些爭論之后,最終 VP8 的授權確認為一個開放源代碼授權。
  目前支持 VP8 的網頁瀏覽器有 Opera、Firefox 和 Chrome。

VP8 的開源實現:libvpx:
  libvpx 是 VP8 的唯一開源實現,由 On2 Technologies 開發,Google 收購后將其開放源碼,License 非常寬松可以自由使用。

VP9 的開源實現:ibvpx:
  libvpx 是 VP9 的唯一開源實現,由 Google 開發維護,里面有部分代碼是 VP8 和 VP9 公用的,其余分別是 VP8 和 VP9 的編解碼實現。

  FFmpeg 是一個自由軟件,可以運行音頻和視頻多種格式的錄影、轉換、流功能,包含了 libavcodec -這是一個用於多個項目中音頻和視頻的解碼器庫,以及 libavformat -一個音頻與視頻格式轉換庫。
FFmpeg 這個單詞中的 FF 指的是 Fast Forward。這個項目最初是由 Fabrice Bellard 發起的,而現在是由 Michael Niedermayer 在進行維護。許多 FFmpeg 的開發者同時也是 MPlayer 項目的成員,FFmpeg 在 MPlayer 項目中是被設計為服務器版本進行開發。

  所謂容器,就是把編碼器生成的多媒體內容(視頻,音頻,字幕,章節信息等)混合封裝在一起的標准。容器使得不同多媒體內容同步播放變得很簡單,而容器的另一個作用就是為多媒體內容提供索引,也就是說如果沒有容器存在的話一部影片你只能從一開始看到最后,不能拖動進度條(當然這種情況下有的播放器會話比較長的時間臨時創建索引),而且如果你不自己去手動另外載入音頻就沒有聲音。

我們在流媒體傳輸,尤其是直播中主要采用的就是 FLV 和 MPEG2-TS 格式,分別用於 RTMP/HTTP-FLV 和 HLS 協議。

  實時音視頻通訊 = 音視頻處理 + 網絡傳輸。包括采集、編碼、網絡傳輸、解碼、播放等環節。音視頻處理中最為關鍵的視頻編解碼是個頭等重要的問題,對於開發者來說,以目前所能找到的技術資源以及應用的普及程度,因為背靠巨頭,H.264(最新版是H.265,微軟和蘋果一直都在背后力推)和VP8(最新版是VP9,由Google力推)是最為主流的兩種編碼。
  Google已在幾年前已經決定Chrome瀏覽里放棄H.264標准的支持,轉而只支持自家的VP8(最新版是VP9)編碼格式。而且,2011年被Google收購的著名實時音視頻方案GIPS——已被Google開源多年並取名為WebRTC,WebRTC中的實時音視頻編碼默認使用的就是VP8標准。

  H.264(下一代是H.265)和VP8(下一代是VP9)編碼兩種:
采用 H.264 視頻編碼和 AAC 音頻編碼的 MP4 文件(H.264/AAC/MP4 組合)
采用 VP8 視頻編碼和 Vorbis 音頻編碼的 WebM 文件(VP8/Vorbis/WebM 組合)

  通常「H.264」指代 H.264/AAC/MP4 這個組合,而「WebM」指代 VP8/Vorbis/WebM 這個組合。
  2010 年中的時候 Google 宣布將 VP8 永久免費。Google 又基於開源容器格式 Matroska 開發了 WebM 容器格式,用以封裝 VP8 編碼的視頻和 Vorbis 編碼的音頻。隨后 Google 連同 Mozilla 和 Opera,准備將 VP8/Vorbis/WebM (統稱為 WebM)推廣為網絡視頻的通用格式。Google Chrome 瀏覽器在 WebM 發布后迅速更新為同時支持 Theora、H.264、WebM 三種格式。Mozilla 和 Opera 也宣布將在其瀏覽器的后續版本(主要是 Firefox 4)中原生支持 WebM。

MPEG LA 將 H.264 專利許可分為兩種:H.264 編碼器和解碼器(不論軟硬件)廠商需要購買一種 H.264 的專利許可協議,H.264 編碼的視頻的分發商(如電視台等)需要購買另外一種 H.264 的專利許可協議。

實時音視頻直播,從剛開始的游戲直播和秀場娛樂開始。

> 快手直播是如何設計全鏈路質量監控方案、如何搭建大數據處理Pipeline 、如何解決開播跳幀、首屏卡頓優化等問題的?
 首屏啟動、流暢播放、網絡擁塞、延時追趕的?實時視音頻傳輸優化?
語音視頻技術團隊,視頻圖像相關的技術研發
  一般大家使用的是MediaPlayer來播放音頻,它的創建和銷毀都是非常消耗資源的,如果我們的需求是播放一些短促而且頻繁播放的音頻的話MediaPlayer就有些不合適了,我們來講講SoundPool來播放短促的音頻

  即時通訊應用中的實時音視頻技術,幾乎是IM開發中的最后一道高牆。原因在於:實時音視頻技術 = 音視頻處理技術 + 網絡傳輸技術 的橫向技術應用集合體,而公共互聯網不是為了實時通信設計的。
  H.264是在MPEG-4技術的基礎之上建立起來的,其編解碼流程主要包括5個部分:幀間和幀內預測、變換和反變換、量化和反量化、環路濾波、熵編碼。

  H.264標准的關鍵技術:1幀內預測編碼;2幀間預測編碼;3整數變換;4量化;5熵編碼
不同於MPEG-4中采用的精細分級編碼FGS(Fine Granular Scalability)的方法(效率比較低),H.264采用流切換的SP幀來代替分級編碼。H.264已被廣泛應用於實時視頻應用中,相比以往的方案使得在同等速率下,H.264能夠比H.263減小50%的碼率。也就是說,用戶即使是只利用 384kbit/s的帶寬,就可以享受H.263下高達 768kbit/s的高質量視頻服務。H.264 不但有助於節省龐大開支,還可以提高資源的使用效率,同時令達到商業質量的實時視頻服務擁有更多的潛在客戶。

  在語音社交、視頻社交、游戲語音和互動直播等領域,關於在語音視頻實時傳輸中實現低延遲這個議題,已經有不少的文章提出各種方案。絕大部分方案的思路都是“優化”,比如說,優化編碼、推流、傳輸和播放等各個環節。要在實時語音視頻傳輸中獲得超低延遲,是不能單靠挖空心思去“優化”的,而是要依靠實時的傳輸機制。

--------------------

> 開源實時音視頻技術WebRTC
VoiceEngine是WebRTC極具價值的技術之一,是Google收購GIPS公司后開源的。在VoIP上,技術業界領先。
  RTP/RTCP協議是流媒體通信的基石。RTP協議定義流媒體數據在互聯網上傳輸的數據包格式,而RTCP協議則負責可靠傳輸、流量控制和擁塞控制等服務質量保證。在WebRTC項目中,RTP/RTCP模塊作為傳輸模塊的一部分,負責對發送端采集到的媒體數據進行進行封包,然后交給上層網絡模塊發送;在接收端RTP/RTCP模塊收到上層模塊的數據包后,進行解包操作,最后把負載發送到解碼模塊。因此,RTP/RTCP 模塊在WebRTC通信中發揮非常重要的作用。
  要了解回音消除技術的來龍去脈,不得不提及作為現代通訊技術的理論基礎——數字信號處理理論。首先,數字信號處理理論里面有一門重要的分支,叫做自適應信號處理。

回音消除技術
丟包補償技術
  丟包補償技術可以分為兩類:基於發送端補償和基於接受端補償。基於發送端補償包括前向差錯糾正、交織和重傳技術;基於接受端補償包括了多種錯誤隱蔽算法。
  基於發送端補償可以分為兩類:主動重傳(本文不討論)和被動通道編碼。被動通道編碼包含傳統的前向差錯糾正技術(FEC)和基於交織的技術。按照和媒體內容的關系,前向差錯糾正包括與媒體無關的方法和利用音頻屬性的媒體相關方法。

  1.非交互式應用
  對於非交互式的語音應用,比如多點廣播,對延時的要求沒有音質高。交織是強烈推薦的丟包補償技術,對於交織后的語音,還要采用合適的錯誤隱蔽算法。與媒體無關的前向誤差糾正技術也適合這種應用。
  2.交互式應用
  交互式的應用比如IP電話、即時通訊應用中的實時語音聊天等,對延時很敏感,因此,交織和與媒體無關的前向誤差糾正技術都不適合這種應用。媒體相關的前向誤差糾正技術只引入很小的延時和較小的帶寬增加,是較好的選擇,可以利用低比特率的次要編碼器獲得丟包補償效果。另外,還可以采用帶有衰減的包重復法等效果較好計算簡單的錯誤隱蔽算法進一步提高音質。
 
  在整個直播或點播過程中,最好有實時統計數據,包括網絡類型,機器信息,實時網絡狀況,幀率,碼率,分別率等。這樣可以分析遇到的各種問題,特別是對於直播場景,當網絡波動,出現卡頓時,可以為動態調整qos提供依據。
  對於實時音視頻直播場景,采用qos策略,動態調整編碼參數。包括幀率,碼率,分辨率,緩沖區。當直播出現卡頓,采用快降慢升的策略,當網絡波動比較厲害,這樣可以避免編碼參數頻繁的來回調整,造成惡性循環。

基於RTMP數據傳輸協議的實時流媒體技術研究(論文全文)- http://www.52im.net/thread-273-1-1.html

  在2017年,有幾類應用是比較火的。第一類在大學校園最火的游戲應該是王者榮耀和狼人殺,王者榮耀10人組隊實時廝殺、還有語音,狼人殺提供實時視頻。第二類就是互動直播,主播端把通信直播流發到觀眾端,同時也可以把觀眾端拉上麥,實現主播和觀眾的互動。

-------------------------------------------

> webrtc android;webrtc直播 SIP-over-WebSocket(SIPoWS)
WebRTC最重要的一個特征是它允許native和web app之間的互操作(跨平台)的。很少有人利用這一個特征優勢。

WebRTC-Android-Learn- https://github.com/RWebRTC/WebRTC-Android-Learn

WebRTC 的 Android 2 Android 實現- https://blog.csdn.net/youmingyu/article/details/53192714
WebRTC 實現Android點到點互連(含Demo)- https://www.jianshu.com/p/2a760b56e3a9?from=groupmessage
信令服務器代碼:https://github.com/matthewYang92/WebRtcServer(代碼改自ProjectRTC)

客戶端代碼:https://github.com/matthewYang92/WebRtcAndroidClient(代碼參考AndroidRTC項目)

 實時音視頻技術是源於早期的VoIP通信.WebRTC.
 H.264也提供VBR、ABR、CBR、CQ等多種編碼模式,各個移動平台兼容性好。
 在實時音視頻系統中需要在Web上進行實時通信,各個瀏覽器都已支持WebRTC,所以WebRTC是Web上實時音視頻通信的首選。但WebRTC是基於瀏覽器的客戶端點對點系統,並沒有定義多路通信標准和服務中轉標准,不管是1V1模式還是1對多模式,需要引入WebRTC網關來接入自定義的實時系統。網關負責將WebRTC的SDP、ICE、STUN/TURN、RTP/RTCP翻譯成自定義系統中的對應協議消息,實現無縫對接WebRTC。WebRTC很多類似的開源網關,例如:licode、janus等。
  善於構建高性能服務系統和系統性能調優,喜好解決系統的疑難雜症和debug技術。早年痴迷於P2P通信網絡、TCP/IP通信協議棧和鑒權加密技術,曾基於P2P super node技術實現了視頻實時傳輸系統。2015年加入學霸君,負責構建學霸君的智能路由實時音視頻傳輸系統和網絡,解決音視頻通信的實時性的問題。 近幾年專注於存儲系統和並發編程,對paxos和raft分布式協議饒有興趣。尤其喜歡數據庫內核和存儲引擎,堅持不懈對MySQL/innoDB和WiredTiger的實現和事務處理模型進行探究。熱衷於開源,曾為開源社區提過些patch。
語音視頻傳輸通道和 IM 的通道是相互獨立的。

> voip
 VOIP語音編解碼技術和網絡傳輸技術;即時語音通話(VoIP);VOIP通話中媒體流是走的UDP,一旦網絡質量不好,語音的質量就會有延時或者斷續。
 騰訊無線的VOIP殺手鐧產品;VoIP與IPTV(Interactive Personality TV);Android平台的P2P語音傳輸技術
  VoIP(Voice over Internet Protocol)即首先數字化語音信號並壓縮成幀,轉換為IP數據包在網絡上傳輸,以此完成語音通話的業務,是一種利用IP協議傳輸語音數據的、新興的通信技術。 既然Phone-Phone和PC-Phone的VoIP屬於基礎電信業務,沒有基礎業務牌照的電信業務經營者顯然不能從事。QQ、飛信等即時通信軟件中的實時語音通話功能其實就是這類VoIP。


VoipSdk(主控模塊);UPnP框架天生就是為對等網絡連接(P2P)的結構設計的


used in many data communication protocols- https://github.com/Jhuster/TLV


PigeonCall:一款Android VoIP網絡電話App架構分析- http://blog.51cto.com/ticktick/1746136
WhatsApp /Skype采用 VoIP 的技術


If you need VoIP but not SIP, check out WebRTC http://www.webrtc.org/


voip的意思是網絡電話,會話發起協議(SIP)是建立VOIP連接的IETF標准。
BroadVoice (音頻編碼的),ffmpeg(音視頻編解碼的);微信的語音通話、SKYPE,技術上就是VoIP。另外,運營商的VoLTE業務,技術上也是VoIP。


android sdk 19 sample代碼中的SipDemo的例子-  http://download.csdn.net/detail/huang_rong12/9504286 


微信占據了太多的運營商信令資源.信令方案.微信電話本


sipdroid,imsdroid(doubango),linphone,csipsimple(pjsip)。
好用的是linphone 和csipsimple,linphone的最大優勢在於全平台支持,android,ios,winphone,windows,linux,mac osx,web 全都支持,但是質量上還是欠火候,改過他的庫,添加過g.729的支持,他的c 代碼,命名和縮進都覺得亂。
 https://git.oschina.net/zencodex/CSipSimple

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com