Badoo 和 Bumble 是海外的社交、交友约会平台与应用，于 2006 年在伦敦创立。据公开报道显示，其活跃用户达1.3 亿。
我们在Badoo和Bumble上的视频通话功能，采用的是支持 H.264 编解码标准的 WebRTC实现的。凭着以往经验，你可能会觉得这个编解码器应该可以在任何Android设备（Android 5.0及更高版本）上顺利运行。但实际上并非如此。本文介绍了WebRTC中H.264编解码器的硬件编码的实现功能，以及要在多个设备上启用它的方法。
为什么选择H.264？
通过WebRTC连接时，参与会话的所有设备都会传输不同的通信参数，包括视频和音频编解码器。如果设备支持多个编解码器（例如VP8和H.264），就会首先列出平台优先级最高的编解码器。这些编解码器会在WebRTC的协商阶段得到应用，此后会仅保留所有设备支持的编解码器。有关此类数据的详细示例，请参见本文档。
在视频通话中，如果有一个设备不支持H.264编解码器，那么两个设备都可以切换到其他编解码器，例如不依赖于设备硬件实现的VP8编解码器。但是我们的应用程序可在不同设备上运行，包括较老旧的智能手机。这就是为什么我们希望可以使用硬件编码进行视频通信，因为这样可以减少处理器的负担，消耗较少的电池电量，这一点对于老旧设备的运行至关重要。此外，与上述VP8相比，许多设备都支持H.264硬件编码。
Android对H.264的支持
根据多媒体格式支持的信息，H.264 Baseline Profile解码应该可以在所有Android设备上运行，而编码要在Android 3.0及更高版本的设备上才能运行。在Badoo和Bumble中，我们支持Android 5.0及更高版本的设备。按理说我们应该不会遇到任何问题。但其实没有这么简单，因为即使在使用5.x版本的情况下，我们发现设备都有大大小小的问题。
可能是什么原因导致的呢？
众所周知，在开发新的Android设备时，任何制造商都应进行兼容性测试套件（Compatibility Test Suite)这一步骤。该步骤在连接到新设备的PC上运行，然后结果需要发送给Google，以确认该设备符合Android OS要求。只有这样该设备才能投放市场。
我们更关心该步骤中的多媒体测试，特别是视频编码和解码测试。我选择了EncodeDecodeTest、MediaCodecTest、DecoderTest和EncoderTest，因为它们包含在所有4.3及更高的Android版本中。这些测试的SLOC计数如下所示：
在4.3版发布之前，大多数这样的测试还没出现。而在5版和7版发布时，测试数量已大大增加。因此可以肯定地说，在Android 4.3发布之前，Google并未测试设备是否符合其自己的视频编码和解码规范，而只是发布了版本5.0。
有人认为，从5.0版本开始，编码操作应该很顺利。但根据我以前对Android视频流解码的研究来说，情况并非如此。Google Groop discuss-webrtc中大量有关编码的帖子验证了这一点。
在我们寻找背后的漏洞时多亏了开源的WebRTC代码。接下来让我们详细了解下这个代码。
WebRTC的H.264支持
让我们从HardwareVideoEncoderFactory开始。
这里我们看到了一个很直白的名为HardwareSupportedInCurrentSdkH264的方法，：
private boolean isHardwareSupportedInCurrentSdkH264(MediaCodecInfo info) {
// First, H264 hardware might perform poorly on this model.
if (H264_HW_EXCEPTION_MODELS.contains(Build.MODEL)) {
return false;
}
String name = info.getName();
// QCOM H264 encoder is supported in KITKAT or later.
return (name.startsWith(QCOM_PREFIX) && Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT)
// Exynos H264 encoder is supported in LOLLIPOP or later.
|| (name.startsWith(EXYNOS_PREFIX)
&& Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP);
原文作者：Ivan Dyatlov
