一个关于Netflix应用程序在新机顶盒上启动的问题

并非真正使用了 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