OpenHarmony3.1媒体能力全景

一、背景

在当前全民直播时代，我们每天刷着五花八门的抖音短视频，看着各式各样电视剧、电影以及随时映入眼帘的各类视频广告等等，每天有无数的视频文件被生成、播放。我们的眼球被花里胡哨的视频疯狂的冲击，或无脑搞笑、或夸张讽刺、或鸡汤淋头、或无效科普等等，与此同时我们是否也可以想一想这些个撩人的视频是怎么在我们眼前设备播放出来的？？播放一个视频文件对于OpenHarmony 3.1（以下简称OH）来说自然不在话下，这篇文章将告诉你一个视频文件（本文以MP4封装格式、H264压缩格式的的视频文件为例）是怎么在OH的设备上播放出来的。

二、OpenHarmony3.1媒体能力全景

OH技术架构如下图所示，完成视频文件播放功能的是多媒体子系统。

多媒体子系统框架如下图所示：

OH拉起了一个叫mediaserver的服务来处理媒体事务，并且封装了接口层包括JS接口、native接口提供给APP调用，mediaserver的核心则是引入了gstreamer（以下简称gst）框架来完成媒体功能。gstreamer是一套功能强大、兼容性好、结构清晰的开源媒体框架，这里不做赘述，后面有专文解析。OH也在gst的基础上开发了player engine来实现播放，同时也利用的gst丰富的插件资源实现几乎所有的媒体功能，当前已移植进来的开源插件包括file source、demuxer、video decoder、libav插件等等，当然也包括OH自研的video sink、memsink、Codec hdi插件等等。

三、H264视频播放道路

大象装进冰箱分几步，我们来看视频播放流程：

播放一个视频大致分为4步：
解协议->解封装->解压缩->送显
播放pipeline

根据视频播放的步骤，我们在OH上每一个环节都能找到对应的插件来完成：

1、对于一个本地视频文件（比如uri=file:///data/h264-640x480.mp4），对应的filesrc插件来完成文件的解析，拿到MP4文件流；

2、拿到MP4文件流后，对应的qtdemux插件来解封装，完成音视频分流，输出H264裸码流和音频流；

3、拿到H264码流后，h264parse插件开始切片，输出H264帧数据；

4、处理H264帧数据，就由avdec_h264插件来完成，一般情况会输出NV12的像素数据，当然这个解码器是基于ffmpeg的软解插件，相信不久各个芯片厂商的硬件加速解码器都会加进来；

5、至此解码的工作已经完成，后面就要根据显示的像素格式、size来对解码输出数据进行后处理（转换、缩放、裁剪等），会有Converter、Scaler、Clip插件来完成；

6、满足显示要求后就会使用suRFacesink插件完成送显。

再加上audio的插件解码出音频数据，OH的player会完成音视频同步，至此一个视频文件就会播放显示在屏幕上。

在OH为了更好的用户体验，同时也引入了一些解决性能问题的插件，比如multiqueue插件来实现buffer队列，也使用decodebin高级插件来完成解码element的选择。

最终我们可以梳理出来一条播放的pipeline：

通过播放OH自带的图库播放本地H264视频，抓取log，搜索OnElementSetuPCB关键字也可以得到播放的pipeline，也进一步验证了本文的分析。

我们也可以使用gst-launch手动创建pipeline来验证：

gst-launch --gst-plugin-path=/system/lib/media/plugins filesrc location=/data/media/h264.mp4 ! qtdemux ! h264parse ! avdec_h264 ! videoconvert ! videoscale ! video/x-raw,width=640,height=480 ! surfacememsink

审核编辑 ：李倩