并非真正使用了 WebRTC，但此處存在使用 WebRTC 技術性質的相似之處。

Netflix的應用程序可以在數百臺智能電視、電視棒和付費電視機頂盒上運行。Netflix的合作工程師的角色是幫助設備制造商在他們的設備上啟動Netflix應用程序。在這篇文章中，我們將討論一個特別困難的問題，它影響了一款設備在歐洲的正常發布。

神秘的開始

2017年底，我參加一個電話會議，其中主要討論一個關于Netflix應用程序在新機頂盒上啟動的問題。box是一款全新的Android電視設備，具有4k播放功能，基于Android開放源碼項目（AOSP） 5.0版本，又名“棒棒糖”。我在Netflix工作了幾年，過去發布過很多臺設備，但這是我推出的第一款Android電視設備。

與該設備相關的四家公司都在此次電話會議中：推出該設備的大型歐洲付費電視公司（運營商）、集成機頂盒固件的承包商（集成商）、系統芯片供應商（芯片供應商）和我（Netflix）。

這家集成機頂盒固件的承包商（集成商）和Netflix已經完成了嚴格的Netflix認證程序，但在這家電視運營商的內部測試過程中，該公司的一名高管報告了一個嚴重問題：Netflix在他的設備上播放“結巴（卡頓）”。即視頻會播放很短的時間后暫停，接著重新開始，隨后又暫停。這種情況并不會一直發生，但肯定會在機頂盒通電后的幾天內開始發生。他們提供了一段演示視頻，情況看起來很糟糕。

設備集成商找到了重現這個問題的方法：反復啟動Netflix，開始播放，然后回到設備的用戶界面。他們提供了一個腳本來自動化這個過程，有時這個過程會持續長達五分鐘的時間，但是腳本總是能夠穩定地重現錯誤。

與此同時，芯片供應商的一名現場工程師診斷出了根本原因：Netflix的Android電視應用程序Ninja傳輸音頻數據的速度不夠快。卡頓是由于設備音頻管道緩沖不足引起的。當解碼器等待Ninja傳送更多的音頻流時，播放停止，等待更多的數據到達后恢復播放。集成商、芯片供應商和運營商都認為問題已經確定，他們向我傳達的信息很明確：Netflix，你的應用程序中有一個漏洞，你需要修復它。我從通話里聽出了壓力。他們設備的上線時間推遲了，而且超出了預算，他們期待我的解決方案。

調查

我持懷疑態度。同樣的Ninja應用程序在數以百萬計的Android電視設備上運行，包括智能電視和其他機頂盒。如果Ninja存在漏洞，為什么它只出現在這款設備上？

我首先使用他們提供的腳本重現了問題，同時聯系了芯片供應商的同事，詢問他以前是否見過類似的情況（他沒有見過）。接下來我開始檢查Ninja的源代碼，我想找到傳輸音頻數據的那行代碼。我認識很多，但我在播放代碼中開始不知所措，我需要幫助。

我上樓找到了Ninja編寫音頻和視頻傳輸代碼的工程師，他幫我梳理了代碼。我自己花了一些時間研究源代碼來理解它的工作部分，并添加了我自己的日志記錄來確認我的理解。Netflix應用程序很復雜，簡單來說，它從Netflix服務器傳輸數據，在設備上緩沖數秒的視頻和音頻數據，然后一次一次地將視頻和音頻幀發送到設備的播放硬件。

圖1：設備播放管道（簡化）

讓我們花點時間來討論Netflix應用程序中的音頻/視頻管道。在每個機頂盒和智能電視上，直到“解碼器緩沖區”都是相同的，但是將A/V數據傳輸到設備的解碼器緩沖區是一個特定的程序，在它自己的線程中運行。它的例行工作是通過調用提供音頻或視頻數據下一幀的API（Netflix提供）來保持解碼器緩沖區滿狀態。在Ninja中，這一任務是由Android線程執行的。有一個簡單的狀態機和一些邏輯來處理不同的播放狀態，但在正常播放下，線程將一幀數據復制到Android播放API中，然后告訴線程調度程序等待15毫秒并再次調用處理程序。當你創建一個Android線程時，可以請求線程重復運行，就像在一個循環中一樣，但是調用處理程序的是Android的線程調度程序，不是你自己的應用程序。

60幀/秒是Netflix能播放視頻的最高幀率，設備必須每16.66毫秒渲染一個新幀，所以每15毫秒檢查一個新樣本的速度足以領先于Netflix提供的任何視頻流。因為集成商已經確定音頻流是問題所在，所以我將注意力集中放在將音頻樣本傳遞給Android音頻服務的特定線程處理程序上。

我想回答這個問題：額外的時間在哪里？假設罪魁禍首是處理程序調用的某個函數，所以我在處理程序中添加了日志消息，假設錯誤代碼是顯而易見的。很快就可以看出，處理程序中沒有任何不正常的行為，即使播放不流暢，處理器也能在幾毫秒內運行正常。

啊哈，洞察力

最后，我關注了三個數字：數據傳輸速率，處理程序被調用的時間，以及處理程序將控制權交還給Android的時間。我編寫了一個腳本來解析日志輸出，并制作了下面的圖表，它給出了答案。

圖2：可視化音頻吞吐量和線程處理器時間

橙色的線是數據從流媒體緩沖區移動到Android音頻系統的速率，單位是字節/毫秒。在這張圖表中，你可以看到三種不同的行為：

這兩個又高又尖的部分，數據速率達到500字節/毫秒。這是在播放開始之前的緩沖階段。處理程序正在盡可能快地復制數據。

中間的區域是正常播放階段。音頻數據以大約45字節/毫秒的速度傳輸。

當音頻數據以接近10字節/毫秒的速度傳輸時，卡頓區域在右側。速度還不夠快，無法維持正常播放。

不可避免的結論是橙色線證實了芯片供應商工程師的報告：Ninja傳輸音頻數據的速度不夠快。

為了理解這其中的原因，讓我們看看黃線和灰線又說明了哪些問題。

黃色的線顯示花費在處理程序本身的時間，根據處理程序頂部和底部記錄的時間戳計算。在正常播放和卡頓的區域，處理程序花費的時間是相同的：大約2毫秒。峰值顯示由于在設備上其他任務花費了時間而導致Ninja傳輸音頻數據的速度不夠快。

真正的原因

灰色的線是兩次調用處理程序之間的時間，它說明了不同的情況。在正常播放的情況下，你可以看到處理程序大約每15毫秒被調用一次。在播放卡頓的情況下，在右側大約每55毫秒調用一次處理程序。調用之間有額外的40毫秒，沒有辦法跟上播放的速度。但這是為什么呢？

我把我的發現告訴了集成商和芯片供應商 （看，這是Android線程調度程序！），但他們對這一發現并不感冒。為什么不在每次調用處理程序時復制更多的數據呢？這是一個合理的質疑，但改變這種行為涉及更深層次的變化，超出了我的準備，我繼續尋找根本原因。我深入研究了Android源代碼，了解到Android線程是一個用戶空間結構，線程調度程序使用epoll（）系統調用進行計時。我知道epoll（）的性能不能得到保證，所以我懷疑有什么東西以系統的方式影響epoll（）。

就在這時，芯片供應商的另一位工程師救了我，他發現了一個漏洞，這個漏洞在下一個名為“棉花糖”（Marshmallow）的Android版本中已經修復了。Android線程調度程序根據應用程序是在前臺運行還是在后臺運行來改變線程的行為。后臺線程被分配額外的40毫秒（4000萬ns）的等待時間。

Android系統本身的一個深層漏洞意味著當線程移動到前臺時，這個額外的定時器值被保留。通常音頻處理線程是在應用程序處于前臺時創建的，但有時線程是在Ninja仍然在后臺時創建的。當這種情況發生時，播放就會卡頓。

經驗教訓

這并不是我們在這個平臺上修復的最后一個漏洞，但卻是最難追蹤的一個。它在Netflix應用程序之外，在播放線程之外的系統部分，所有的初始數據都表明Netflix應用程序本身存在缺陷。

這個故事確實體現了我熱愛這份工作的一個方面：我不能預知我們的合作伙伴會向我拋出的所有問題，要解決這些問題，我必須了解多個系統，與優秀的同事合作，并不斷督促自己學習更多知識。我所做的事直接影響著現實中的人們以及他們的用戶體驗。我知道，當人們在客廳里享受Netflix時，我是Netflix團隊中不可或缺的一員，是我們讓這一切成為現實。

責任編輯：lq