OpenHarmony4.0源码解析之媒体框架

最新推荐文章于 2025-04-30 15:25:25 发布

原创最新推荐文章于 2025-04-30 15:25:25 发布 · 1.4k 阅读

26 ·

CC 4.0 BY-SA版权

文章标签：

#媒体 #harmonyos #Openharmony #鸿蒙开发 #华为 #深度学习

移动开发同时被 3 个专栏收录

951 篇文章

订阅专栏

HarmonyOS

866 篇文章

订阅专栏

OpenHarmony

690 篇文章

订阅专栏

媒体框架简介

媒体框架 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 是否过长时间未发送指令，若出现异常，则调用暂停命令，否则调用恢复播放指令。

为了能让大家更好的学习鸿蒙（HarmonyOS NEXT）开发技术，这边特意整理了《鸿蒙开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05