媒体框架简介
媒体框架 multimedia_player_framework 主要提供音视频的录制与播放功能。
框架简介
从框架图中可以看出,媒体框架的主要工作模式为通过 Gstreamer 的插件自动化注册及插件组合功能,将其余媒体播放相关的框架功能插件化,配合 Gstreamer 自身丰富的插件,共同来对外提供音视频的录制与播放功能。如通过 audio-sink 及 audio-source 插件调用音频框架的播放及采集功能来实现音频的播放与录制;通过 surface-sink 调用图形框架,video-decoder 调用解码驱动模块实现视频的硬解播放等。
Gstreamer 基本概念
Gstreamer 是媒体框架中的重要组成部分,采用基于插件(plugin)和管道(pipeline)的体系结构,框架中的所有的功能模块都被实现成可以插拔的组件(plugin),能够很方便地安装到任意管道上。插件架构是 GStreamer 的核心,几乎所有的媒体处理功能都可以抽象成为插件的一部分。
以一个图中完整的 ogg 播放流程为例: GStreamer 内部使用 pipeline(管线)机制来做信令控制,元素组件管理和数据传输,一个 pipeline 内部存在多个 element(元素),每个元素内部存在输入和输出的端口(pad);
解码流程具体为 ogg 文件源 source 经过解封装器 demuxer 产生 vorbis 编码的数据流,之后经过解码器 decoder 解码为浮点 float 格式的 raw 数据,浮点 raw 数据通过转换器转换为整形 raw 数据,最后通过输出 sink 完成音频信号输出。虚线下面的标注为经过每个 pad 的输入格式和输出格式。
GStreamer 定义了以下元素概念:
Source:可以理解为数据源,也就是数据流的起始地。例如文件,网络源,摄像机麦克风的输入。
Filter: 过滤器, 也可理解为中间处理单元,将 sink pad 传入的数据经过内部处理通过 src pad 传出。编解码器,封装/解封装都可以认为是 Filter。有人可能会与 Ffmpeg 的 filter 相混淆,Ffmpeg 中 Filter 定义为处理原始数据(解码后数据的)的功能单元。提供音视频后处理功能。Gstreamer 中 Filter 更强调同时存在输入和输出的概念,功能的范围更大一些。
Sink:数据接受者,source 产生的数据流最终要流向的地方。例如输出文件,屏幕显示,扬声器输出。
Bin: 与 pipeline 类似,它们的区别为 pipeline 肯定是一个 bin,但 bin 不一定是 pipeline,它就像一个盒子,存放了多个元素,实现了部分甚至完整的由 source 到 sink 的流程。Bin 提供了软总线 Bus 用于处理内部产生的信号(这些消息包括:错误消息(error messages),卷标消息(tag messages),EOS 消息(EOS messages))。**PipeLine: pipeline 是高级的 Bin。**当你设定管道的暂停或者播放状态的时候,数据流将开始流动,并且媒体数据处理也开始处理。一旦开始,管道将在一个单独的线程中运行,直到被停止或者数据流播放完毕。
音视频播放流程
1.视频播放流程如下:
2.视频播放的接口调用时序图如下:播放器在设置播放源时,完成 Gstreamer engine 的加载,在 prepare 时 完成对于 gsreamer playbin 的初始化,后续的播放,暂停等接口都是通过控制 Gstreamer playbin 的状态来控制播放流。
音视频录制流程
1.音视频录制流程如下:
2.音视频录制接口调用时序图如下:以音频录制为例,用户在调用 prepare 接口时,会依次设置音频源,音频输出格式,以及音频配置参数和音频输出路径,在基本配置完成后,才会形成音频录制的 pipeline,与播放器不同,该 pipeline 为框架自定义。在音频录制的 pipeline 形成后,即可通过 recorderPipeline 的状态来控制录制流。
媒体框架 4.0 新增能力
1 ScreenCapture
ScreenCapture 为屏幕采集模块,提供屏幕画面采集及音频采集功能。主要提供如下接口:
class ScreenCapture {
public:
virtual ~ScreenCapture() = default;
virtual int32_t Init(AVScreenCaptureConfig config) = 0;
virtual int32_t SetMicrophoneEnabled(bool isMicrophone) = 0;
virtual int32_t StartScreenCapture() = 0;
virtual int32_t StopScreenCapture() = 0;
virtual int32_t AcquireAudioBuffer(std::shared_ptr<AudioBuffer> &audiobuffer, AudioCaptureSourceType type) = 0;
virtual sptr<OHOS::SurfaceBuffer> AcquireVideoBuffer(int32_t &fence, int64_t ×tamp, Rect &damage) = 0;
virtual int32_t ReleaseAudioBuffer(AudioCaptureSourceType type) = 0;
virtual int32_t ReleaseVideoBuffer() = 0;
virtual int32_t Release() = 0;
virtual int32_t SetScreenCaptureCallback(const std::shared_ptr<ScreenCaptureCallBack> &callback) = 0;
};
从提供的结构体 AVScreenCaptureConfig
来看,主要采集类型如下:CaptureMode : 采集模式包括了主屏幕、特定屏幕(暂不支持)、特定窗口(暂不支持)采集;DataType : 数据类型包括原始流,编码流(暂不支持)和文件(暂不支持);AudioInfo : 音频信息包括对采样率,采样格式以及音频源的设置。音频源支持麦克风以及系统内部音源;VideoInfo : 视频信息主要包括分辨率以及视频源类型,视频源类型主要为 yuv(暂不支持),es 流(暂不支持),rgba;
struct AVScreenCaptureConfig {
CaptureMode captureMode;
DataType dataType;
AudioInfo audioInfo;
VideoInfo videoInfo;
RecorderInfo recorderInfo;
};
音视频数据的流转如下图,分别存在音频和视频数据的缓存队列,通过 bufferavailable 来通知用户可用 buffer,用户可通过 acquireBuffer 和 releaseBuffer 来获取和删除音视频数据
2 SoundPool
SoundPool 为音频池管理模块,提供集中管理多个音频资源的功能。该框架实际并未经过媒体框架的 IPC,而是在 client 端直接调用了音频解码器和音频渲染器。
SoundPool 通过 SoundIdManager 来管理 SoundParser 获取音频流解码数据,通过 StreamIdManager 来管理 CacheBuffer 控制音频流的播放,加载资源及播放的调用流程如下:
3 Monitor
媒体框架的播放及录制 client 与 stub 分别通过继承 MonitorClientObject,MonitorServerObject 来实现对于媒体播放录制运行状态的监控。client 在开始播放或者录制后每隔 1s 向 server 端发送 click 指令,Server 端每隔 1.5s 检查对应的 client 是否过长时间未发送指令,若出现异常,则调用暂停命令,否则调用恢复播放指令。
写在最后
有很多小伙伴不知道学习哪些鸿蒙开发技术?不知道需要重点掌握哪些鸿蒙应用开发知识点?而且学习时频繁踩坑,最终浪费大量时间。所以有一份实用的鸿蒙(OpenHarmony)资料用来跟着学习是非常有必要的。
想更深入的学习 OpenHarmony (鸿蒙南向)全栈开发的内容可点击领取一下学习文档,限时开源,先到先得~无套路领取!!
请点击→《鸿蒙南向开发学习路线》
OpenHarmony入门学习视频
鸿蒙南向开发实战教学视频
获取以上完整鸿蒙HarmonyOS学习文档,请点击→《鸿蒙南向开发学习路线》
《OpenHarmony源码解析》:
- 搭建开发环境
- Windows 开发环境的搭建
- Ubuntu 开发环境搭建
- Linux 与 Windows 之间的文件共享
- ……
系统架构分析:
- 构建子系统
- 启动流程
- 子系统
- 分布式任务调度子系统
- 分布式通信子系统
- 驱动子系统
- ……