乐趣区

关于jquery:浅析云控平台画面传输的视频流方案

简介: 本文将小结本次云控平台画面传输的视频流计划。

背景
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 来获取视频流数据,则能够升高开发和适配老本。

原文链接
本文为阿里云原创内容,未经容许不得转载。

退出移动版