前言

近年來，隨著HTML5技術普及、移動設備迅猛增長和流量資費不斷下降，視頻已成為人們了解世界、獲取知識的主要途徑之一。現在音視頻播放器已隨處可見，但這個過程到底如何實現?播放器的原理又是什么?或者是作為生產者，應該依據哪些標準來選擇適合自己的播放器?UCloud將基于多年的實踐經驗，為客戶做出相應解答或建議。

一.播放器功能架構

首先來看常規播放器的功能架構：

(圖：常規播放器結構圖)

應用層：UI/統計/DRM(數字版權保護)/多碼率/彈幕/廣告等。

底層：數據接收模塊/解復用模塊/音視頻解碼、濾鏡、渲染模塊/字幕/應用層結合功能：DRM、多碼率/統計等。

播放器的功能比較多，本文就不再一一贅述，下面將重點講解多媒體引擎模塊。

二.多媒體引擎

作為播放器的核心部分，多媒體引擎主要負責音視頻數據的加載、處理和展現。以FFmpeg為例，它的基本運作流程如下圖所示：

(圖：多媒體播放流程圖)

我們詳細了解一下每個環節：

1、數據接收(Source)

作為數據入口，這里的文件可以通過本地文件(File://協議開頭)輸入，也可以通過網絡協議(如HTTP、RTMP、RTSP等)輸入。在找到對應的傳輸協議之后，FFmpeg會根據協議特性與本機或服務器建立連接并獲取到流數據。

2、解復用(Demux)

通過對文件的特征碼分析，可以找到文件的封裝格式，如常見的MP4、FLV、TS、AVI等。根據封裝格式的標準對其拆封，可以得到編碼的音視頻數據，一般稱之為“packet”。

3、解碼(Decode)

解碼器初始化時，利用之前源數據分析獲得的音視頻信息，分別設置對應的音頻解碼器和視頻解碼器。目前互聯網中比較常見的音頻編碼方式有AAC(Advanced Audio Coding)、MP3，視頻編碼方式有H.264、H.265。對packet分別進行解碼后，音頻解碼獲得的數據是PCM(Pulse Code Modulation，脈沖編碼調制)采樣數據，一般稱為“sample”。視頻解碼獲得的數據是一幅YUV或RGB圖像數據，一般稱為“picture”。

4、音視頻同步(Synchronizing)

音視頻解碼時是兩個獨立線程，因此獲得的音視頻數據是分開的，并無任何關聯。理想狀態下，音視頻按照自己固有頻率渲染輸出就能達到音視頻同步的效果。但是在現實中，斷網、弱網、丟幀、緩沖、音視頻不同的解碼耗時等情況都會妨礙實現同步，很難達到預期效果，所以要保證視頻內容和音頻內容對得上，必須做音視頻同步。

5、音視頻渲染(Render)

經過音視頻同步調整之后，需要把sample和picture分別輸送給聲卡和顯卡，這部分工作建議由成熟的庫來完成。常見的音頻庫有SDL、OpenAL/OpenAL ES、DirectSound、ALSA(Advanced Linux Sound Architecture)、OSS(Open Source System)等;視頻庫有SDL、OpenGL/OpenGL ES、DirectDraw、FrameBuffer等。

經過以上5個步驟，基本的播放流程就完成了。

三.各平臺視頻技術概況

要實現全平臺覆蓋的播放器，自然少不了技術支撐。這里主要討論Web、Android、iOS上的音視頻技術，講述一部分音視頻常用方案。

1、Web-HTML5

技術語言：JavaScript，HTML/CSS

使用環境：所有可以支持HTML5 Video標簽的終端瀏覽器(PC Windows/Mac/Linux/Unix、Android、iOS)即可播放視頻，目前覆蓋率已達95%。

(圖：Video element覆蓋率)

相關方案：

1.1 標簽

從代碼示例來看，HTML5的Video標簽非常簡單易用，controls= " controls "可以使用瀏覽器默認的播放器UI(不同瀏覽器UI不一樣)，如果不對controls賦值，則可以通過CSS和Video消息來實現自定義UI及控制。

1.2 MSE(Media Source Extensions)

Media Source Extensions (MSE) 是一個主流瀏覽器支持的新Web API，而且是W3C標準,允許JavaScript動態構建 和 媒體流。它定義了對象, 允許JavaScript傳輸媒體流片段到一個HTMLMediaElement。

通過使用MSE,可以動態地修改媒體流而不需要任何插件。這使前端JavaScript可以做更多事情, 比如可以在JavaScript進行轉封裝、處理，甚至轉碼，因此像ABR(Adaptive Bitrate)、hls.js、dash.js、flv.js也是基于這點來實現的。

雖然MSE不能讓流直接傳輸到media tags上, 但是MSE提供了構建跨瀏覽器播放器的核心技術, 讓瀏覽器通過JavaScript API來推音視頻到media tags上，目前MSE的覆蓋率已達77.93%。

(圖：MSE覆蓋率)

2、Web-Flash

技術語言：ActionStript

使用環境：安裝了FlashPlayer的瀏覽器(PC Windows/Mac/Linux/Unix、Android、iOS)即可播放視頻。曾經是互聯網時代早期富媒體老大的Web-Flash，因HTML5普及已慢慢淡出人們的視野，現在更多是作為HTML5播放器的互補方案來使用。

相關方案：

2.1 FLVPlayBack

Flash自帶封裝好的播放器，跟HTML5的瀏覽器默認播放器差不多，系統了一些播放器UI樣式供選擇，簡單幾句代碼就可以快速構建精美的播放器，但是靈活度較差。

2.2 NetStream

Flash處理多媒體的核心類，它提供了appendbytes這個API，允許外部傳入FLV封裝格式的數據進來播放，類似于HTML5的MSE。同理，可以用此接口實現視頻的轉封裝、處理、轉碼等操作，再配合RTMFP協議，還可以實現P2P的視頻傳輸播放。

2.3 CrossBridge & FFmpeg

曾幾何時，Flash還有個叫CrossBridge(又叫Alchemy、Flascc)的黑科技，允許在Flash規定范圍內跑自己編寫的C/C++代碼，這樣就徹底提升了運算效率，如果配合FFmpeg的多媒體處理能力，可能會有意想不到的效果。

3、Andorid

技術語言：Java、JNI(C/C++)

使用環境：Andorid系統(Andorid phone、Android pad、Andorid TV、Android Box等)。

相關方案：

3.1 MediaPlayer

Android提供的默認多媒體播放器，可以用來播放本地或網絡上的音頻、視頻數據，主要負責解協議、解碼，但不包含顯示部分。顯示部分需要配合SurfaceView或者SurfaceTexture來處理。

3.2 MeidaCodec (API 16+ ，Jelly Bean 4.1.x)

Android提供的硬編解碼類，第一次使用是在Android 4.1版本(API16),主要對音視頻數據進行編碼或解碼操作。在Android 4.3(API18)中，MediaCodec被擴展為包含一種通過 Surface 提供輸入的方法(即createInputSurface)，這允許輸入來自于相機的預覽或是經過OpenGL ES呈現。

3.3 JNI & FFmpeg

JNI是Java Native Interface的縮寫，一開始是為了本地已編譯語言，尤其是C和C++而設計的，但并不妨礙使用其他編程語言，只要調用約定受支持就可以了。使用java與本地已編譯的代碼交互，通常會喪失平臺可移植性，但有些情況下這樣做是可以接受的，甚至是必須的。例如，使用一些舊的庫與硬件、操作系統進行交互，或者為了提高程序的性能。JNI配合FFmpeg這個強大引擎，使Android平臺具備了較好的多媒體處理能力。

4、iOS

• 技術語言：Objective C、C/C++、Swift
• 使用環境：iOS系統(iphone、ipad)

相關方案：

4.1 AVFoundation.framework：AVPlayer、AVPlayerLayer

AVPlayer類只包含音視頻的數據接收、解碼、處理工作，不包含顯示部分，需要配合AVPlayerLayer來使用，可定制化強度大、靈活，消息也比較豐富，官方推薦使用，取代了MPMoviePlayerController的位置。

4.2 AVFoundation.framework：AVPlayerViewController

提供了默認的可視化控制界面，整合了一個完整的播放器，可以作為控制器進行操作顯示。官方推薦使用，取代了MPMoviePlayerViewController的位置。

4.3 MediaPlayer.framework：MPMoviePlayerController

iOS的基礎播放器，使用幾個簡單的API就能完成視頻文件播放，其內部已包含數據接收、解碼功能，如果要在UI中展示視頻，需要將view屬性添加到界面中，播放器UI方面需要自行開發。iOS 9.0以后，蘋果官方已棄用。

4.4 MediaPlayer.framework：MPMoviePlayerViewController

iOS的基礎播放器視圖控制器，MPMoviePlayerViewController在MPMoviePlayerController基礎上封裝了一層View，默認全屏模式展示，彈出后自動播放，作為模態窗口展示時如果點擊“Done”按鈕會自動退出模態窗口等，有一套自己的UI。iOS 9.0以后蘋果官方已棄用。

4.5 VideoToolbox.framework

VideoToolbox是一個底層框架，iOS 8.0以后，官方正式放開了硬件編解碼API，它為視頻壓縮和解壓縮提供服務，并存儲在緩沖區corevideo像素柵格圖像格式之中。這些服務以會話對象的形式提供(壓縮、解壓和像素傳輸)，應用程序不需要直接訪問硬件編碼器和解碼器相關內容，而只需要直接使用videotoolbox即可實現編解碼。iOS設備在硬件編解碼這塊的質量有一定保證，可以優先使用硬編解碼，FFmpeg軟解碼為互補方案。

4.6 FFmpeg

因Objective-C支持 C/C++混合編譯，所以很容易就可以把FFmpeg使用起來，讓iOS具備強大的多媒體處理能力。

5、小結

從HTML5、Flash、iOS、Android四個平臺上看，它們似乎都具備音視頻播放能力，但它們之間到底有些什么差別?我們應如何選擇合適自己的方案?

先對比一下播放方面的技術差異：

我們嘗試把產品場景分為四種，以下是對各自的建議：

四、幾個常見問題

做一個播放器遠沒有想象的那么簡單，來看一下播放器的幾個常見問題。

1、 怎么做音視頻同步?

對于系統封裝好的播放器，則無須關心這個問題，但如果要實現一個完全可控的播放器，從數據接收->解復用->解碼->音視頻同步->渲染都需要去干預。處理音視頻同步的原因已在前面章節講過了，這里著重講實現原理。

做音視頻同步之前，先補充個知識點，DTS與PTS(I幀、P幀、B幀請自行補充)。

• DTS(Decode Time Stamp)：解碼時間戳，這個時間戳的意義在于告訴播放器該在什么時候解碼這一幀的數據。
• PTS(Presentation Time Stamp)：顯示時間戳，這個時間戳用來告訴播放器該在什么時候顯示這一幀的數據。

視頻編碼中必存在I幀，可能存在B幀、P幀，B幀是雙向參考幀，因此會打亂幀的解碼和顯示順序，因此引入了DTS和PTS來應對這種情況。普遍情況下B幀壓縮率較I幀、P幀高，在點播視頻中比較常見，直播視頻中一般沒有B幀，在此情況下，DTS和PTS應該相同。音頻編碼因為沒有參考幀的概念，是不需要DTS的。 

(圖：I、P、B、DTS、PTS關系)

在清楚了DTS和PTS之后，可見PTS對音視頻同步起關鍵作用，音視頻常見的同步方式有三種，分別是：以音頻為主線同步、以視頻為主線同步和以外部時鐘同步。第一種最為常見，也是比較符合人類視覺聽覺感官的方式(音頻變速會導致變聲)，同時音頻的播放速率比較固定，比較容易作為主線管理，其同步過程總結如下：

a) 解碼器從輸入的數據封裝中解出音頻PTS、視頻PTS;

b) 創建音頻播放線程，音頻按固有的采樣頻率播放;

c) 創建視頻刷新線程，按一定頻率(10ms)定時檢測;

d) 通過音頻、視頻的時間基(time_base)換算成相同時間基準的PTS;

e) 在視頻刷新線程中計算當前真實的音頻PTS、視頻PTS：

• currentRealVideoPTS = 當前準備顯示的視頻幀PTS + 當前視頻幀流逝系統時間;
• currentRealAudioPTS = 最新已播放的音頻幀PTS + 當前音頻幀流逝系統時間;

f) 計算currentRealVideoPTS - currentRealAudioPTS的差值diff;

g) 若diff <= 0，說明視頻顯示慢了，這時需要馬上顯示該幀數據;

• 若diff > 0，則視頻酌情做適當的延時顯示;

h) 一幀數據的音視頻同步檢測就此結束。

以上方法的核心理念是通過延時評估算法來控制視頻幀慢放或快放，以此做音視頻在合理范圍內保持同步。

2、 怎么做到視頻秒開?

有以下幾點可以優化：

• a) 服務器端下發關鍵幀數據，保證播放器第一時間解碼到有用的數據;
• b) 播放器可以在選擇音視頻解碼器環節做優化，通過外部預設解碼器相關參數來減少解碼器類型探測耗時;
• c) 在業務層面上優化，使用HTTP-DNS服務做到精準調度，選擇最優服務器獲取播放數據;
• d) 提升音視頻服務節點質量;

3、 怎么做到低延時?

延時這詞是針對直播而言，先看直播系統的架構圖：

(圖：UCloud直播系統架構圖)

從圖中可以看出，可能產生延時的環節有：

a) 主播端推流至上傳節點的延時;

可以通過接入HTTP-DNS為主播選擇最優節點，減少傳輸延時。

b) 主播端發包的延時;

主播端應盡快發送本地數據至上傳節點，對于弱網環境，應該有合理的控制策略，盡量避免大量過期數據阻塞在本地。

c) 上傳節點到服務器集群的數據分發、轉封裝、轉碼等耗時;

分發的層級越多，延時則越大，這塊也主要依賴于服務器間的網絡狀況。

d) 觀眾端到下載節點的延時;

可以通過接入HTTP-DNS為觀眾選擇最優節點，減少傳輸延時。

e) 播放器本地存在buffer;

常規的播放器都會有本地緩存，合理的緩存設置可以為用戶帶來較好的觀看體驗，減少視頻的卡頓次數。如果對延時有較高要求，可以減少buffer的緩沖時長，甚至可以把buffer去掉。

4、 播放器卡頓的原因有哪些?

再看上圖，卡頓可能的原因有：

• a) 主播端推流與上傳節點傳輸不順暢;
• b) 服務器間傳輸出了問題;
• c) 觀眾與下載節點傳輸不順暢。

五、總結

看完這些，相信大家對基礎的播放流程及各平臺上音視頻處理技術已有初步了解，但是要做好多個平臺的播放器并非易事，要做大量兼容性適配、容災、性能調優、播放質量統計反饋、新功能迭代等工作。因此，一款好的播放器需要不斷打磨，UCloud也將持續投入更多資源去支持該領域的運作。

作者簡介

【劉宇峰，現任UCloud流媒體終端研發部經理，熱愛多媒體行業和專注于Web、Android、iOS方面的技術，擁有近十年的互聯網和多媒體領域的研發經驗，現主要負責UCloud視頻云SDK、直播云SDK的架構設計、研發管理和運營工作。此前，曾任職于騰訊，主要負責Web前端多媒體方面的研發工作。】