基于QT和FFmpeg实现自己的视频播放器FFMediaPlayer（一）—

基于QT和FFmpeg实现自己的视频播放器FFMediaPlayer（一）——项目总览

news2025/5/18 17:58:11

在音视频开发的学习过程中，开发一款视频播放器是FFmpeg进阶的最好实战方法。本文将基于 QT 和 FFmpeg 着手实现自定义视频播放器 FFMediaPlayer，作为系列文章的开篇，我们先来整体了解项目的设计思路、架构与配置。

一、软件设计五大原则

在软件项目开发过程中，我们应该尽可能遵循以下 5 个重要的软件设计原则，确保项目具有良好的可维护性、可扩展性和稳定性。

单一职责原则（SRP）：每个类或模块只负责一项单一的功能。在 FFMediaPlayer 中，将视频解码、音频解码、界面渲染、用户交互等功能分别封装到不同的类中。例如，专门创建一个FF_Video类负责调用 FFmpeg 进FF_Audio类处理音频解码，避免功能混杂导致代码臃肿难以维护。
开放封闭原则（OCP）：软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。当我们需要为 FFMediaPlayer 添加新的视频格式支持或特殊播放功能时，通过创建新的类或继承现有类来实现扩展，而不是直接修改已有的稳定代码。比如，后续如果要支持新的视频编码格式，可以继承现有的FF_Decode类，重写解码相关方法。
里氏替换原则（LSP）：所有引用基类的地方必须能透明地使用其子类的对象。在设计 FFMediaPlayer 的类层次结构时，确保子类能够完全替代父类的功能，并且不会出现功能异常。例如，在播放控制相关的类中，子类继承父类的播放、暂停、停止等方法，必须保证这些方法在子类中的行为符合父类的预期。
接口隔离原则（ISP）：客户端不应该依赖它不需要的接口。在 FFMediaPlayer 项目中，将复杂的功能接口拆分成多个小的、特定的接口。比如，将视频播放控制接口与内部解封装解码接口分离，避免一个接口过于庞大，使类只实现自己需要的接口，提高代码的灵活性和可维护性。
依赖倒置原则（DIP）：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。在 FFMediaPlayer 中，高层的播放逻辑模块不直接依赖 FFmpeg 底层的具体解码函数，而是通过定义抽象的解码接口，让底层的解码类去实现这些接口，这样可以降低模块之间的耦合度，方便后续替换底层实现。

如果严格遵守以上原则会导致代码封装复杂，我希望平衡代码开发和维护的难度，所以不会严格遵守以上原则。

二、项目类图

为了更清晰地展示 FFMediaPlayer 项目的架构和类之间的关系，下面通过类图进行呈现：

上述类图从功能维度将 FFMediaPlayer 的核心架构拆解为左右两大核心板块，形成 “窗口交互层” 与 “解封装解码层” 的清晰分工。在左侧窗口交互部分，FF_Mdia_player作为整个播放器的主窗口中枢，通过模块化集成的方式，将负责视频画面渲染的FF_Video_Widget、提供播放进度与控制功能的FF_Slider等组件有机整合，构建出直观的用户交互界面。

右侧解封装解码部分以FF_Demux_Thread为核心枢纽，它犹如整个音视频处理流水线的总指挥，通过精准调度FF_Demux解封装器以及并行运作的FF_Video_Thread视频解码线程、FF_Audio_Thread音频解码线程，实现媒体文件的高效解析与数据提取。在视频处理链路中，FF_Video_Widget专注于视频帧的渲染工作，通过抽象的纯虚函数类FF_Video_Call与FF_Video_Thread建立松耦合通信，确保解码后的视频数据能实时流畅地呈现在界面上；音频处理部分则由FF_Audio_Play负责音频播放，同样依托纯虚函数类FF_Audio_Call与FF_Audio_Thread对接，保证音频解码与播放的无缝衔接。这种架构设计既实现了前后端功能的清晰分离，又通过抽象接口保障了各模块间的灵活协作与可扩展性。