共计 1670 个字符，预计需要花费 5 分钟才能阅读完成。
简介： 本文将小结本次云控平台画面传输的视频流计划。
背景
ARC（高德车机云控平台）是一个基于车载设施业务深度定制的云控平台，通过该平台咱们可能实现近程应用不同类型的车载设施。为了让近程使用者像在本地一样应用车载设施，须要将车载设施的画面及时的传回给使用者。因而，画面传输能力是 ARC 平台的一个外围组件。
起初咱们采纳行业内广泛在用的画面传输开源计划（minicap）。该计划获取到屏幕数据后压缩生成 JPG 图像，逐帧传输到 Web 端进行展现。因为车机性能比手机差很多，压缩图片耗费 CPU 性能大，在局部低端车机设备上压缩图片能耗费 80% 左右的 CPU，容易使设施应用呈现卡顿。同时图像压缩率不算很高，传输耗费带宽大，在低带宽下造成用户看到的画面适度提早。
因而，咱们须要一个解决方案可能均衡传回的画面质量和车机端的 CPU 资源耗费。本文将小结本次云控平台画面传输的视频流计划。
思路办法
基于图像数据的根本传输链路，为了可能不耗费设施端 CPU 资源，首先想到了图像不进行压缩，先传输到服务端进行解决。然而通过调研，车机的 USB 带宽传输根本无法满足高清图像不压缩进行传输，高清原始数据十分大，根本 1 秒只能传输三帧左右的数据。
另一个思路是采纳设施端的硬件编码器缩小 CPU 资源的耗费。通过调研 Android 4.1 开始根本都自带了 H264 视频编码器。因而，决定尝试采纳视频流的计划，在设施端通过硬件编码器编码成视频流，通过服务端转发到 Web 端进行解码展现。
实现计划
整个实现计划能够分为以下三个局部：
设施端：负责画面的获取和编码。
服务端：解决视频流的传输和管制。
Web 端：视频流的解码和展现。
画面的获取和编码
图像画面的获取间接采纳的是 Android 的 Virtual Display。编码方式有多种实现办法：
因为 Java 计划只能反对 Android 5.0 以上机器，而目前车载市场 Android 4.x 的占比还比拟大，无奈疏忽。因而只能应用 cpp 的计划，最低可兼容 Android 4.3 版本。
视频流的传输和管制
Web 端最常见的直播计划是 rtmp/hls/flvjs 等。然而这些计划最低都有 1 -3s 的提早。对于个别直播平台没有影响，然而对于有实时交互场景的云控平台，要求达到毫秒级提早。所以，最终决定采纳 H264 裸流通过 Socket 传输的计划，设施端编码 H264 视频流间接传输到 Web 端进行播放。
同时，为了进步应用体验，对视频流的传输减少了弹性控制。通过在服务端退出缓存队列用来监控前端带宽负载状况，依据带宽情况主动调节帧率和码率，优先保障使用者的晦涩感。
Web 端展现和解码
Web 端展现应用 media source extensiton(MSE) + fragment mp4 的计划，把 H264 裸流封装成 fragment mp4 后，通过 MSE api 进行解码播放，具体实现是参考了开源的 Jmuxer 计划。
**
丢帧和补帧 **
默认状况下 Android Virtual Display 产生的最大帧率是 60fps，而咱们肉眼 30fps 就能感觉晦涩。为了可能节俭带宽，咱们定义了视频流最大输入帧率是 30fps。在网络带宽较差的状况下，咱们还可能升高帧率来最大限度的防止提早。同时，Android MediaCodec 不反对管制帧率，帧率是由每秒送入的帧数量决定的。因而，咱们须要通过实现丢帧来进行帧率控制。
Win7 硬件解码器没有低提早模式，须要大略 10 帧左右数据能力开始播放，而 VirtualDisplay 是画面有变动才会产生图像帧，因而须要实现补帧来打消解码提早。
咱们通过创立一个 EglSurface 对丢帧补帧进行解决，通过工夫距离管制 eglTexture 绘入 EglSurface 的频度进行丢帧，通过反复绘入最初一帧数据进行补帧。
总结
该计划在 ARC 平台上的应用，在保障传输品质的同时，无效的晋升了使用者操作的晦涩感。该计划实践上也能够利用于其余相似的云控平台上，如果不须要反对 Android 4.x 设施，采纳 Java 层 API 来获取视频流数据，则能够升高开发和适配老本。
原文链接
本文为阿里云原创内容，未经容许不得转载。
