重庆企业网站建站,flash网站制作软件,中国建设人才网络学院,阜宁县住房和城乡建设局网站源码
本文基于OpenAtom OpenHarmony#xff08;以下简称“OpenHarmony”#xff09;3.2 Release源码foundation目录下的player_framework#xff0c;在OpenHarmony 2.0 Release版本当中#xff0c;这个模块的名字叫媒体组件模块#xff0c;为了方便理解我们在本文中仍旧延…源码
本文基于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/pluginspart_name multimedia_player_frameworksubsystem_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学习资料
《鸿蒙 (OpenHarmony)开发入门教学视频》 《鸿蒙生态应用开发V2.0白皮书》 《鸿蒙 (OpenHarmony)开发基础到实战手册》
OpenHarmony北向、南向开发环境搭建 《鸿蒙开发基础》
ArkTS语言安装DevEco Studio运用你的第一个ArkTS应用ArkUI声明式UI开发.…… 《鸿蒙开发进阶》
Stage模型入门网络管理数据管理电话服务分布式应用开发通知与窗口管理多媒体技术安全技能任务管理WebGL国际化开发应用测试DFX面向未来设计鸿蒙系统移植和裁剪定制…… 《鸿蒙进阶实战》
ArkTS实践UIAbility应用网络案例…… 获取以上完整鸿蒙HarmonyOS学习资料请点击→纯血版全套鸿蒙HarmonyOS学习资料
总结
总的来说华为鸿蒙不再兼容安卓对中年程序员来说是一个挑战也是一个机会。只有积极应对变化不断学习和提升自己他们才能在这个变革的时代中立于不败之地。
