OpenHarmony之媒体组件模块简介

源码

本文基于OpenAtom OpenHarmony（以下简称“OpenHarmony”）3.2 Release源码foundation目录下的player_framework，在OpenHarmony 2.0 Release版本当中，这个模块的名字叫媒体组件模块，为了方便理解我们在本文中仍旧延用其之前的名字，其源码仓目录结构如下：

frameworks目录下包含了两个部分，第一个是沟通js应用与框架层的napi，另一个是供napi调用底层能力的native接口。services目录下的内容可以粗略的理解为多媒体的系统服务，对应为OpenHarmony中的media_service进程，其下的engine目录中的内容是其核心所在,而services目录下主要是与frameworks/native下同名的接口，用于实现C/S模式。

功能

跟其源码路径名字一样，多媒体组件模块提供了通过url播放本地音频/视频的能力。但其功能远不止此，可以说是整个多媒体子系统的基石。结构如下图：

从结构图中可以看出，提供给应用的接口层在基本能力的基础上提供了相当多的功能。但实际归纳起来，主要是录制、播放、编解码、媒体信息。分别对应图中的Recoder、Player、AVCodec、AVMetadata四个子模块，这四个子模块功能相互独立，结构相似。大致的工作模式可以简化为：

OpenHarmony应用通过调用系统提供的Napi接口调用到Client层的框架代码，之后Client通过跨进程方式IPC调用Engine的能力。

Engine的实现

GStreamer

在功能与结构部分有一张来自于OpenHarmony源码中提供的结构图，可以看出各个Engine依赖于GStreamer实现，GStreamer是一个多媒体应用程序的框架。其支持了大部分当前主流的媒体文件如AVI、MP4、Ogg等的解封装，以及视频编码格式H264、H265、VPX等的解码，还具备对一些常见协议如RTSP、RTMP等的支持。GStreamer通过其管道(Pipeline)与插件(plugin)机制，提供了强大的可扩展性以及可操作性，后文中会讨论相关内容。

Pipeline与Plugin机制

其实如果仔细看媒体组件模块的源码，不难发现，每一个Engine中都包含关键函数Start、Prepare、Stop，且都管理了一个Pipeline。例如Recoder引擎的实现代码：

每一个多媒体应用都会涉及到对多媒体信息的处理，且往往有好几个流程。就拿一个最简单的本地Ogg格式文件播放来举例。需要对Ogg文件进行解封装，之后可以拿到封装再其中经过编码压缩的音频和视频数据，再然后需要分别对音频与视频进行解码，最后将解码后得到的音频PCM帧给扬声器播放、视频帧画面给屏幕渲染。

在GStreamer中上述的整个流程对应为一条Pipeline，而每一层处理的过程是一个Element也可以叫做一个插件。如下图：

sink是数据的入口，src是数据的出口。准确的来说，上图中的每一个大方框在GStreamer应该叫做Element。它的功能是对某一种数据做处理，而插件(plugin)在官网上的定义是：Just writing a new element is not entirely enough, however: You will need to encapsulate your element in a plugin to enable GStreamer to use it. A plugin is essentially a loadable block of code, usually called a shared object file or a dynamically linked library. A single plugin may contain the implementation of several elements, or just a single one. plugin本质上是一个可导入的代码块，可能包含一个或多个element。单个element是不够的，需要将其封装到一个plugin上才能供GStreamer使用。

OpenHarmony的引擎中有的是使用的GStreamer自带的pipeline如playbin，有的是OpenHarmony中实现的pipeline如codecbin。bin的概念在GStreamer中比pipeline更高一级，可以简单的认为bin是一条可以执行的pipeline。而上文中提到的每个Engine中都有的Start()、Stop()等函数其实是对一条pipeline进行状态控制的函数。一条pipeline设置好所需的参数，通过Start()将pipeline设置为工作状态，之后就像水管一样，数据从入口流入从出口(可能有多个)流出。下图为AVCodecEgine开始流水线的代码。

在设置完状态后，pipeline会自动工作。因为流水线上的每个环节都预先设置了其可以支持的数据类型与参数，在很多情况下，pipeline的结构也是根据数据的内容自动组建的(具体的协商过程不在本文讨论范围内)。我们所需做的只是将需要的插件注册到GStreamer中或者什么都不做让GStreamer从自带的插件中选择。

实践

OpenHarmony支持RTMP播放

在前面的讨论中我们知道了，GStreamer是一款强大的多媒体工具。其功能可以满足绝大多数多媒体场景的需求，但是OpenHarmony原生的播放器并不支持直接播放RTMP链接。让我们看看OpenHarmony 3.2中播放器引擎BUILD.gn中的依赖。(gn文件路径为foundation\multimedia\player_framework\services\engine\GStreamer\BUILD.gn)

依赖中的gstplugins_bad_packages对应GStreamer gstplugins_bad(rtmp协议插件所在的目录)路径下插件所编译出来的库。(gn文件源码路径为third_party\GStreamer\gstplugins_bad\BUILD.gn)

可以看到OpenHarmony 3.2源码中并没有将RTMP加入编译当中，这样就导致了即使依赖于GStreamer，原生的OpenHarmony也不支持播放RTMP链接。而要支持该协议也很简单，在这个gn文件中把RTMP相关内容加入编译。可以参考如下写法(原配置文件太长，截取一小部分展示)：

group("gstplugins_bad_packages") {deps = [":gstcurl",":gsthls",":gstmpegtsdemux",":gstvideoparsersbad",":myrtmplugin"]
}

编译插件所需的.c文件:在GStreamer每个插件源码目录下都有一个meson.build文件，里面有所涉及的.c文件

ohos_source_set("my_rtmp_source") {sources = ["gst/rtmp2/gstrtmp2.c","gst/rtmp2/gstrtmp2element.c","gst/rtmp2/gstrtmp2locationhandler.c","gst/rtmp2/gstrtmp2sink.c","gst/rtmp2/gstrtmp2src.c","gst/rtmp2/rtmp/amf.c","gst/rtmp2/rtmp/rtmpchunkstream.c","gst/rtmp2/rtmp/rtmpclient.c","gst/rtmp2/rtmp/rtmpconnection.c","gst/rtmp2/rtmp/rtmphandshake.c","gst/rtmp2/rtmp/rtmpmessage.c","gst/rtmp2/rtmp/rtmputils.c", ]configs = [ ":gst_plugins_config" ]
}ohos_shared_library("myrtmplugin") {deps = [":my_rtmp_source","//third_party/glib:glib","//third_party/glib:gobject","//third_party/GStreamer/gstplugins_bad:gstadaptivedemux","//third_party/GStreamer/gstplugins_bad:gsturidownloader","//third_party/GStreamer/gstplugins_base:gsttag","//third_party/GStreamer/GStreamer:gstbase","//third_party/GStreamer/GStreamer:GStreamer",]relative_install_dir = "media/plugins"part_name = "multimedia_player_framework"subsystem_name = "multimedia"
}

在上文中我们提到，播放引擎所使用的playbin会根据输入的内容自动组建pipeline。把RTMP插件加入编译后，playbin在自动组建pipeline时会在注册的插件中找到它。

本文中我们讨论了OpenHarmony 3.2 Release中媒体组件模块的功能以及结构，并且对其实现的原理进行了一些简单的探讨。

GStreamer是一个功能强大的多媒体库，上文中作为例子讨论的PlayerEngine使用的是一款"全自动"的pipeline。而OpenHarmony中也有像AVCodecEngine那种OpenHarmony化的pipeline，包含了依赖于OpenHarmony平台编解码能力的插件。

涉及的内容不单单包括媒体组件跟GStreamer，还包括驱动相关的内容。除此之外还有如何像AVCodecEngine一样手动实现自己的plugin、element这样的问题，在这里先留个悬念，如果后续有机会咱们再展开讨论。

最后

有很多小伙伴不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以有一份实用的鸿蒙（HarmonyOS NEXT）资料用来跟着学习是非常有必要的。

这份鸿蒙（HarmonyOS NEXT）资料包含了鸿蒙开发必掌握的核心知识要点，内容包含了（ArkTS、ArkUI开发组件、Stage模型、多端部署、分布式应用开发、音频、视频、WebGL、OpenHarmony多媒体技术、Napi组件、OpenHarmony内核、Harmony南向开发、鸿蒙项目实战等等）鸿蒙（HarmonyOS NEXT）技术知识点。

希望这一份鸿蒙学习资料能够给大家带来帮助，有需要的小伙伴自行领取，限时开源，先到先得~无套路领取！！

获取这份完整版高清学习路线，请点击→纯血版全套鸿蒙HarmonyOS学习资料

鸿蒙（HarmonyOS NEXT）最新学习路线

HarmonOS基础技能

HarmonOS就业必备技能
HarmonOS多媒体技术

鸿蒙NaPi组件进阶

HarmonOS高级技能

初识HarmonOS内核
实战就业级设备开发

有了路线图，怎么能没有学习资料呢，小编也准备了一份联合鸿蒙官方发布笔记整理收纳的一套系统性的鸿蒙（OpenHarmony ）学习手册（共计1236页）与鸿蒙（OpenHarmony ）开发入门教学视频，内容包含：ArkTS、ArkUI、Web开发、应用模型、资源分类…等知识点。

获取以上完整版高清学习路线，请点击→纯血版全套鸿蒙HarmonyOS学习资料