本文來自《WebRTC Native開發實戰》書籍作者許建林在LiveVideoStack線上分享中的內容，詳細分析總結 WebRTC 的視頻數據流程，并對大型項目如何快速上手：分析方法，如何在工作中按需進行定制開發或調試分析問題等內容進行了深入解讀。

文 / 許建林

整理 / LiveVideoStack

直播回放：https://www.livevideostack.cn/video/online-piasy/

大家好，非常高興能有機會和大家進行分享。我叫許建林，英文名Piasy，目前在PowerInfo從事高穩定、低延遲的音視頻實時傳輸技術的研發工作。到目前為止已經有五年的工作經驗，前兩年主要是做視頻直播的安卓APP開發，之后的三年在PowerInfo一直在做RTC SDK的開發。我是一個開源愛好者，在GitHub也有發過許多的開源項目，非常歡迎大家關注一起交流。

本次分享的主題是WebRTC視頻流數據流程分析，主要內容可以分為以下幾個部分：

• WebRTC 代碼庫簡介

• 分析方法

• 視頻流程介紹

• 實戰：客戶端視頻錄制

01

PART

WebRTC 代碼庫簡介

1.1 WebRTC簡單介紹

關于什么是WebRTC，如何用一兩句話簡單說明？

WebRTC是一個Web端 RTC的互聯網標準，同時我們也會用WebRTC來指代一個開源項目，是目前完成度最高、最流行的RTC框架，是由Google開源的項目。

1.2 WebRTC版本說明

上圖展示的是Chromium項目網站上公開的版本發布規劃表，圖中Milestone 81是Milestone的編號，簡寫為M81。表中其它列如Chromium、Skia以及WebRTC等都是其對應的版本分支，例如Skia有同名的m81分支，之前WebRTC也是有同名的m75、m76分支，只不過后來改變了分支的命名方式。

在《WebRTC Native開發實戰》中有提到過書中對于WebRTC的代碼分析是基于某次提交版本，例如“#30432提交”。如圖所示為WebRTC的Git提交記錄圖，藍色箭頭所指位置:Cr-Commit-Position：refs/head/master@{#30432}，“#30432”的含義是指該項目從開始到現在第幾次提交。WebRTC的代碼庫有一個特點，其主干分支是一條直線，無其它分支（當然在發布新版本時，會開出發布分支，可能會同步一些需要帶上去的提交，但是這個分支上的提交都不會再合并回來），這也就使得WebRTC的版本歷史非常清晰，開發者在查詢提交記錄或變更歷史時會非常簡單方便。

上圖是我在之前參與過的一個項目中截取的，是在Sourcetree中截取的。我們可以看到其分支非常復雜，但其實這是遵循GitFlow的版本控制模式運行所導致的結果，Gitflow被很多人詬病的地方就是提交的版本記錄分支結構非常復雜，難以追溯歷史。

1.3 WebRTC代碼目錄

圖為MacOS中WebRTC iOS的代碼庫目錄

首先是“api”，主要是C++代碼的公開api，開發者在使用C++開發時就會用到其預先定義的接口程序，例如pPear_cConnection類。同時，在安卓或iOS上使用Java或者ObjectiveC接口的話，其實也都是對C++接口的bouninding。

“call、pc、media”：這三個目錄在我理解，是WebRTC主要流程和業務邏輯的實現代碼。

“audio、common_aduio、video、common_video”：這四個目錄主要是音頻和視頻類相關的代碼。

“modules”：很多公司可能不會直接使用整個WebRTC的代碼庫，而只是使用其中的一些常用模塊，這些模塊大都包含在“modules”中，例如回聲抑制、噪音抑制等處理，視頻編碼、Jitterbuffer等。

“p2p”：與p2p連接相關的代碼。

“sdk”：Android和iOS平臺相關的代碼，如視頻采集、預覽、渲染、編解碼等需要調用系統接口的代碼，對C++接口的bouninding。

“rtc_base”：Chromium項目中一些公用的基礎代碼，例如線程、鎖相關代碼。

“third_party”：包含許多Google的其它開源項目以及非Google開源的項目，被WebRTC用到的都放在third_party中，例如FFmpeg、libvpx等。

“system_wrappers”：包含另一個系統相關的代碼的目錄，如sleep函數。SDK主要涉及的是Androic和iOS平臺相關的代碼，system_wrappers則包含更多平臺如windows等相關的代碼。

“stats 、logging”：狀態統計，日志打印相關的代碼。

“examples”：包含有各個平臺的demo，例如Android、iOS、Windows、Linux、MacOS等。

目前就我的學習和了解，還沒有觸及其它的一些目錄，不過它們應該也不是主干流程相關的內容。

本次分享的第一部分我們以《WebRTC Native開發實戰》書中第一部分的標題Hello WebRTC來做一個結尾。

第一章：開發環境的搭建：書中有非常詳細的一步步的教程，只要解決了科學上網的問題，按照教程基本上應該不會再遇到其它問題。

第二章：運行官方Demo：主要是剛才提到的examples目錄中的各種Demo。

第三章：基本流程分析：這里的基本流程與我們此次分享的內容有些區別，這里的基本流程更多的是如何使用WebRTC的接口，實現簡單的1V1的音視頻通話，也就是Demo實現的一個功能。

02

PART

分析方法-如何上手大型項目

對于個人來說如何盡快上手大型項目？例如WebRTC或者其它的開源項目像FFmpeg、GStreamer等。包括大家入職新公司，很可能會接手或參與到較大的項目中，雖然可能不都會像WebRTC那么巨大，但還是存在一定的挑戰性。在這里分享一些我的經驗，希望能為大家提供些幫助。

首先，第一步就是“跑起來”，只有把相關項目的demo運行起來，以此才能對項目有更加直觀的了解，了解其相關功能，以功能實現的位置作為切入點，思考其實現方式、方法。

第二步，“從外部的API入手，順藤摸瓜”。例如下圖是iOS的代碼，首先找到外部的API，如代碼中RTCCameraVideoCapture是用來實現相機采集的，然后就可以看類中是如何調用接口和處理數據的。

第三步“基于基礎知識（音頻采播系統接口），搜索定位關鍵函數/類”，第二步例如在Android或者iOS下我們是先找到實現相應功能所需要調用的外部接口，可以根據這些關鍵的接口在代碼中進行搜索發現關鍵的函數和類。但不是所有的邏輯都會有外部Web接口，例如WebRTC中音頻相關的實現就是不需要調用任何接口的。下圖是一個iOS的例子，對于音頻播放最關鍵的函數是AudioOutputUnitStart，即開啟一個Audio Unit。我們在搜索后可以找到voice_processing_audio_unit.m文件，其中包含的一個Start函數，我們就可以進一步觀察函數以及頭文件有哪些接口，例如初始化start、stop等，音頻就可以從這里進行外擴或閱讀源碼。

第四步“靜態閱讀源碼+單步調試”。靜態閱讀源碼主要是利用IDE的代碼跳轉，但是gn其生成exXcode工程文件的方式有一些特殊，很多代碼跳轉會跳不過去或者跳轉到錯誤地方。所以更多的時候我還是使用全局搜代碼，盡管效率稍低，但目前沒有其它更合適的辦法。單步調試，在代碼中的某些位置，我們希望了解其下一步是如何跳轉的，而代碼無法直接跳轉，搜索的結果也并不知道是什么作用無法準確判斷，這時我們可以通過加斷點進行驗證。

如圖所示，是視頻編碼相關的一個類的函數，在加入斷點后，我們可以觀察到視頻數據是如何從系統的回調接口到采集RTCCameraVideoCapture的類再一步步到編碼的類，非常清晰。

在軟件開發中，沒有銀彈，都是那些看似樸實無華但往往非常有效的辦法，掌握這些方法后，再上手一些新的項目就會有一些幫助。

03

PART

視頻流程介紹

WebRTC的視頻數據流程在各個平臺基本上都是一致的。

視頻數據首先由VideoCapturer采集，然后交給VideoSource，通過其中的VideoBroadcaster傳輸給接收對象，例如Encoder、Preview等。Preview負責進行本地預覽，Encoder負責編碼發送。從網絡層接收到數據之后，首先會通過VideoDecoder進行解碼，接下來同樣會將其傳輸VideoBroadcaster，再分發給數據的接收方。VideoSource在上圖中未體現，但也是一個比較關鍵的類，它位于VideoTrack和VideoBroadcaster中間，其實是對VideoBroadcaster接口的封裝。

VideoTrack是WebRTC中比較重要的一個概念，音頻、視頻等媒體從概念上來說其實就是一個Track，我們通常會添加或從遠端接收一個Track。另外，IOS的流程與上圖中流程有一些區別，其視頻預覽不是從VideoBroadcaster接收每一幀的數據然后進行渲染，而是其系統存在接口可以將采集和預覽兩個系統類關聯并自動實現渲染。但其實我們也可以像RemoteRenderer類一樣，獲取到一幀個數據后再進行渲染，用RemoteRenderer類添加到采集端的VideoBroadcaster中進行渲染。

在非iOS的平臺上，本地預覽以及遠端視頻的渲染其實都是通過一個類來實現的。

完整視頻數據流程（調用棧）

圖中詳細的列出了視頻數據的整體采集、處理、傳輸相關步驟。簡單來看，就是從上到下到最底部網絡層，再由下到上最終到渲染的整體流程。所有平臺的視頻數據流程基本上都是大同小異的，區別只在于采集、編解碼和渲染的實現不同，其余的流程基本是一致的。

采集：

首先RTCCameraVideoCapture會從系統數據回調，接收到實際的視頻數據，交給VideoSource通過_nativeVideoSource將數據傳遞到C++這一層，最后提交AdaptedVideoTrackSource進行一些如旋轉、裁剪之類的操作。

編碼：

視頻數據經過AdaptedVideoTrackSource層之后，就可以通過broadcaster_進行分發。在安卓或者linux中可能會有多個分支，一個預覽一個編碼，這里我們以編碼為主干進行分析。Sink實際上就是數據的消費者，通過VideoStreamEncoder來實現編碼，但其只是概念上的編碼，最終實際編碼還是調用系統相關的類，因此最終會回到ObjectiveC層，通過一些調用到達RTCVideoEncoderH.264，再調用VideotoolbBox接口，實現H.264的硬件編碼。編碼完成之后會實現系統的回調，再將編碼后的數據交回給C++層，即VideoStreamEncoder的OnEncodedImage回調函數中，表示一幀視頻數據已經完成編碼。

發送：

VideoSendStream表示要發送的視頻流，通過rtp_vVideo_sSender_進行RTP打包處理，再接下來就是需要進行的RTP封包和網絡傳輸。假設通過網絡傳輸數據已經到達RtpVideoStreamReceiver，我們可以看到左右兩邊的sender和receiver在類以及函數的命名上會有一些對稱的地方。RtpVideoStreamReceiver接收到RTP，并且已經完成解包以及其它的網絡亂序、錯誤重傳等處理，獲得一幀完整可解碼的幀，然后就會調用解碼回調，送到VideoReceiveStream中進行解碼操作，在這里會調用vVideo_rReceiver_的Decode函數。

解碼：

vVideo_rReceiver_的Decode函數其實也是概念上的解碼，叫VCMGenericDecoder，最終也會調到平臺相關的ObjectiveC實現的視頻硬解，即RTCVideoDecoderH.264，也是調用VideoToolBox進行解碼，解碼后通過DecodedFrameCallback交還給C++這一層。

解碼后的數據最終還是到達了VideoStreamdDecoder，交給了incoming_vVideo_sStream_。這里會存在一個視頻幀的隊列，解碼和編碼不太一樣，編碼是采集到一幀視頻幀，編碼完成后立刻發送，但解碼完成后卻不會立刻進行渲染，而是需要一定的緩沖，以避免由于抖動而導致卡頓。所以視頻數據解碼完成后會首先放入隊列中，等待渲染模塊控制節奏，需要時再獲取數據。

渲染：

獲取到視頻數據后，會通過Broadcaster將數據交給sink，sink在iOS上具體是通過RTCMTLVideoView對數據進行渲染，MTL是調用iOS的Metal接口進行視頻渲染。

其實圖中只是視頻流程中調用棧的總結，書中有一章節的內容總結了視頻數據流程的更多示例代碼的分析以及講解。

04

PART

實戰：客戶端視頻錄制

首先要明確需求：1. 推流和收流都需要，即發送的數據需要錄制成文件并且接收到的內容也要錄制成文件；2. 其次是不希望做額外的編碼，因為通常接收或者發送的視頻都是已經處理（編碼）好的，額外的編碼會造成資源浪費。3.在不需要額外編碼的情況下，我們只需要調用FFmpeg把編碼后的數據存儲到文件內即可。4.我們應該從哪里拿數據？

要回答從哪里拿數據這個問題，首先需要對視頻數據流程有一定了解，也就是前面第三部分所介紹的內容。如上圖紅框所示，VideoSendStreamlmpl：：OnEncodedimage中已經接收了編碼后的視頻數據，但其數據存在形式還是完整一幀，并沒有拆分成一個一個的RTP包。接收端情況比較復雜，在網絡傳輸時會出現亂序到達、丟包缺失等問題，造成網絡數據的不可用。因此，我們需要找到一個已經對上述問題進行過處理的數據點，即解碼之前的數據點，VidioReceiveStream的HandleEncodedFrame函數中。

當我們找到數據接入點后，需要進行的操作就是修改代碼，增加API，實現相關功能。如在Android和iOS上希望有Java或Object C的接口暴露出來供APP層調用。想要修改iOS接口，就需要修改SDK目錄下的代碼。

舉例如圖所示 ，我們需要修改RTCPeerConnection文件，其中所定義為WebRTC的主類。增加Start/StopRecoder的接口，通過dir的參數表明想要錄制視頻的方向（發送或者接收）。

SDK僅為C++接口的boinunding，因此還需要修改API目錄里面的C++接口，即修改peer_connection_interface.h，為C++的PC類增加接口。

API里面只是程序接口，我們需要修改程序的實現類，實現類主要在pc中，但這里有一點特殊的是，業務流程和實現邏輯，call中也是很重要的一部分。

如圖所示，它是對api/peer_connection_interface的一個子類，一個具體集成的實現類，我們為其增加接口，但是在這里我們不在peer_connection_interface的類中調用錄制相關的代碼，而是在call里進行修改。

前面我們介紹到的VideoSendStream和VideoReceiveStream以及本次沒有介紹到的VAideo相關的類，其實例的管理都在call對象里。在我理解，在以前WebRTC的概念模型中，主類其實是一個Call，而pPeercConnection是在后續標準化過程中所定義的接口。所以實際的視頻錄制調用功能被封裝成一個Recorder類，Recorder類的管理都會放在call里面，修改pc peer connection以及call的頭文件。

完成上述操作后，下一步就是截取數據。截取數據的操作其實就是VideoSendStream和VideoReciveStream的函數調用，Recorder的對象在call里面，兩種Stream的對象也在call里面，那我們就只需要將Recorder設置給Stream，注入進去即可。

從call到VideoSendStream有如上圖所示的文件需要修改，Call里面有一個Stream接口的定義，然后在video目錄下會有call里面定義的Stream接口的子類、實現類，video_send_stream_impl，在OndecodedImage中，將完整的一幀給recorder，再調用FFmpeg的頭文件接口即可。

數據收留端和發送端情況類似，ReceiveStream和SendStream在功能上非常對稱，在call目錄下也有一個接口定義，在video目錄下也有一個接口的實現。

錄制相關完整的代碼在github上有一個完整的提交，大家可以作為參考。

（https://github.com/HackWebRTC/webrtc/commit/dfbcd2c75d27dafd24512d6ca3d24c6d86d63b82）

LiveVideoStackCon 2020?北京

2020年10月31日-11月1日

點擊【閱讀原文】了解更多詳細信息

總結

以上是生活随笔為你收集整理的WebRTC视频数据流程分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。