FPlayer Desktop

画面从哪来

FPlayer 支持三种画面来源：本地视频文件、摄像头、电脑屏幕。每一种都有不同的技术实现路径。

先理解：电脑是怎么"看到"画面的

在深入三种采集方式之前，需要先讲清楚一个最基本的问题：一幅画面在电脑里到底长什么样？

电脑屏幕上显示的每一幅画面，都是由大量小方块组成的。每一个小方块叫做一个像素。如果你凑近屏幕仔细看，甚至能看到一个个像素的格子。1920×1080 的分辨率，就是宽 1920 个像素、高 1080 个像素——总共约 207 万个像素排列成一个巨大的矩阵。

每个像素只做一件事：发出一种颜色。而所有颜色都可以用三个数字来描述——红（R）、绿（G）、蓝（B）。这不是随便选的：人眼视网膜上恰好有三种感知颜色的细胞，分别对红光、绿光、蓝光最敏感。所以用红绿蓝三种光的混合，就能模拟出人能看到的几乎所有颜色。电脑屏幕上的每一个像素，其实就是三个超微型灯泡——一个红的、一个绿的、一个蓝的，靠调节各自的亮度来混合出不同颜色。

每个数字的范围是 0 到 255。0 表示"这个颜色完全不发光"，255 表示"开到最亮"。举个例子：纯红色 = (255, 0, 0)，纯白色 = 三色全开到 255 = (255, 255, 255)，纯黑色 = 三色全关 = (0, 0, 0)，灰色 = 三色等量一半 = (128, 128, 128)。

所以一幅 1920×1080 的静态图片，在电脑内部的存储形式就是 207 万组 (R, G, B) 数字。每秒连续播放 30 张这样图片，就是 30fps 的视频。画面采集——无论是读视频文件、拿摄像头数据、还是抓取屏幕——本质上都是获取这些 (R, G, B) 数值的过程。

▲ 左：一个像素放大后的 RGB 三色子像素结构。右：1920×1080 画面 = 207 万个像素组成的大矩阵，每个像素存储一组 (R,G,B) 数值。

采集方式一：播放本地视频文件

这是最直观的方式——从硬盘上打开一个 .mp4 或 .mkv 文件，把里面的画面一帧帧读出来。

但实际做起来不简单，因为视频文件里的数据是压缩过的。我们刚才算过，1920×1080、每秒 30 帧的原始画面，一秒钟就是 186MB，一分钟超过 10GB。你的硬盘根本存不下几部电影，网络也传不动。所以存储和传输之前，视频必须被压缩——这个压缩的过程叫编码。播放时要做的第一件事就是解码——把压缩数据还原成可以显示的画面。

解码之后还有一个问题：怎么让声音和画面对上？视频文件里的画面数据和音频数据是分开存的（因为它们的压缩方式完全不同）。播放时需要根据每段数据上的时间戳——就是记录"这一帧画面应该在视频的第几秒第几毫秒出现""这一段音频应该在什么时刻播放"的标记——来同步画面和声音。如果时间戳没处理好，就会出现"画面比声音慢半拍"的情况，这叫做"音画不同步"。

FPlayer 的文件播放功能有两套实现：

• FFmpeg 后端：自研播放器，约 1265 行代码。内部把工作拆成三个可以同时进行的任务——一个专门从文件里读取压缩数据，一个专门把压缩数据还原为画面，一个专门处理音频——让它们互不等候、各跑各的。这种"几个任务同时做"的安排叫做多线程，本章后面会详细解释。这个后端支持精确到毫秒的进度跳转、0.5 到 2 倍速播放（音频也会同步变速）、循环播放等精细控制。
• Qt 6 后端：直接调用 Qt 框架自带的播放器。代码简单，但功能受限——能播什么格式取决于操作系统装了哪些解码器。Windows 自带了一些常见格式的解码器，但如果遇到小众格式可能就播不了。

这里出现了两个名字——FFmpeg 和 Qt。FFmpeg 是一个开源工具集。"开源"的意思是代码是公开的，任何人都可以免费使用和修改。它几乎能处理所有音视频格式、支持所有流媒体协议、还能利用显卡做硬件加速。Qt 是一个做桌面软件界面的工具箱——它提供按钮、窗口、菜单这些"界面零件"，让开发者不需要从零画一个按钮出来。Qt 也顺带提供了一些媒体播放和摄像头访问的能力。FPlayer 同时用这两套工具来实现同一个功能（播放文件），这就是"多后端"的由来——第四章会展开讲这种设计。

采集方式二：摄像头

摄像头的工作原理不复杂：镜头把环境光汇聚到感光芯片上 → 感光芯片把光信号转为电信号 → 芯片内部电路把电信号转为数字像素数据 → 通过 USB 线把数据传给电脑。

FPlayer 拿到摄像头数据之前需要做三件事：

• 列出设备：电脑上可能连着多个摄像头——笔记本内置的、USB 外接的、甚至虚拟摄像头软件（比如 OBS 可以把自己模拟成一个摄像头，这样其他软件就能把 OBS 的画面当作摄像头画面来用）。FPlayer 自动搜索所有可用的摄像头，列出来给你选。在 Windows 上，它是通过微软提供的一套叫 DirectShow 的系统接口来搜索的；在 Linux 上，用的是 Linux 内核自带的 Video4Linux2（简称 v4l2）驱动框架。
• 协商参数：每个摄像头都支持多种分辨率和帧率的组合。比如一个摄像头可能同时支持 1080p 每秒 30 帧、720p 每秒 60 帧、480p 每秒 120 帧。FPlayer 向摄像头询问"你能支持哪些模式"，然后列出让你选。这个"询问-应答"的过程叫"格式协商"。
• 持续读取：选定格式后，FPlayer 持续从摄像头读取画面帧。采集到的原始数据通常是 YUV 格式（一种比 RGB 更省空间的颜色表示方式，第三章会详细解释），被放入帧总线——一个各模块之间共享画面数据的中转区——然后再分两路走：一路送去屏幕给你看（预览），一路供推流或组合模式使用。

采集方式三：屏幕捕获

屏幕捕获就是把"显示器上正在显示的内容"作为画面来源。这比摄像头复杂，因为要抓的画面已经存在显卡里面了——关键不是去哪找画面，而是怎么最高效地拿出来。

FPlayer 有三套屏幕捕获方案，性能和平台适配各有侧重：

• Qt 6 方案：用 Qt 框架自带的 QScreenCapture。代码最简单，但在 Windows 上性能不是最优的——数据还是要经过 CPU 内存。
• FFmpeg 方案：在 Windows 上用 gdigrab（微软最早期的图形设备接口——GDI——提供的屏幕抓取方式），在 Linux 上用 x11grab（Linux 上最常用的图形系统 X11 的抓屏工具）。兼容性非常好——几乎所有 Windows 和 Linux 系统都能用，但性能一般，数据必须从显存搬到系统内存。
• DXGI 方案（仅 Windows）：DXGI 是 DirectX Graphics Infrastructure 的缩写，属于微软 DirectX 图形技术栈的一部分。它允许程序直接在显存里访问 GPU 渲染好的画面，不需要把数据搬到系统内存。采集、缩放、编码全部在显卡内部完成——数据从头到尾没离开过显存。结果就是 CPU 占用几乎为零，帧率更高、延迟更低。这是 Windows 上抓屏的最优方案。

三套方案都支持：选择多个显示器中的某一个、自定义捕获哪个矩形区域、控制每秒抓多少帧、选择是否在画面中包含鼠标光标。

flowchart TD
    subgraph 来源["三种画面来源"]
        FILE["视频文件 .mp4/.mkv"]; CAM["摄像头 USB/内置"]; SCR["屏幕 显示器画面"]
    end
    subgraph 后端["两种后端实现"]
        FF["FFmpeg 后端"]; QT["Qt 6 后端"]
    end
    subgraph 输出["统一输出"]
        YUV["转为 YUV 格式"]
    end
    FILE-->FF; FILE-->QT; CAM-->FF; CAM-->QT; SCR-->FF; SCR-->QT
    FF-->YUV; QT-->YUV
    style YUV fill:#cc785c,stroke:#cc785c,color:#fff
      

▲ 不论来源是什么、用哪个后端实现，最终都统一输出 YUV 格式画面帧。这是系统最重要的设计约定——让后续所有处理（编码、组合、推流）只面对一种数据格式。

采集之后：一帧画面同时做两件事

采集到的每一帧画面会同时走两条路：

• 预览路径：画面被送到一个叫 FGLWidget 的显示控件。这个控件内部使用 OpenGL——一种让程序直接指挥显卡做图形计算的技术标准。OpenGL 让显卡把 YUV 格式的画面数据实时转换成 RGB 格式显示在屏幕上。显卡有几千个核心，可以同时处理几百上千万像素的转换，速度极快而且不占用 CPU 的计算时间。
• 数据路径：画面被放入帧总线（FrameBus）。帧总线是程序中不同任务之间传递画面数据的一块共享存储区。采集任务把画面放进去，编码任务（如果正在推流的话）从里面取走。这个放入和取出的过程不是随意的——帧总线内部有一个叫锁的保护机制：一个任务正在往里写的时候，另一个任务不能同时读取；反之亦然。这就保证不会出现"读了一半数据就被覆盖"的坏数据情况。

两条路同时运转。即使你只是在预览画面（没有推流），采集、格式转换、显卡渲染这一整套流程也已经在运行了。

画面怎么到达观众

画面采集好了、组合好了，接下来要压缩编码，然后通过网络发送出去。这是整个链路中计算量最大的环节。

推流和拉流

推流：一台设备持续地把编码压缩后的视频数据发送给另一台设备或服务器。FPlayer 桌面端做的是推流——把采集到的（或组合好的）画面压缩后发出去。拉流：一台设备从服务器持续拉取视频数据，然后解码播放。FPlayer 手机端做的是拉流。

两者的关键区别在于谁发起传输：推流是发送方主动发，拉流是接收方主动要。

数据在网络上是按什么规矩传的？

两台设备要在网络上传输数据，必须事先约定好一套规矩——数据包长什么样、谁先发谁后发、传错了怎么补救。这套规矩就叫协议。

流媒体领域常用协议：

• RTMP：Adobe 公司十几年前设计的一种传输方式。它在推流端和服务器之间建立一条TCP 连接——TCP 是网络上两种主要传输方式之一（另一种叫 UDP），它的特点是保证数据一定送到、顺序一定不乱、如果中途丢了一个包会自动重发。相当于"挂号信"——寄到了才罢休。RTMP 靠这条 TCP 连接持续传视频数据，端到端延迟大约 1~3 秒，目前仍是推流的主力协议。缺点是使用 1935 端口，有些公司防火墙会拦截非标准端口。
• HTTP-FLV：把 RTMP 格式的视频数据包装在 HTTP 格式里传输。HTTP 就是浏览器上网用的那个协议——你在地址栏输入网址时前面那个 "http://" 或 "https://"。所有防火墙都放行 HTTP（否则网页就上不了了），所以 HTTP-FLV 的网络穿透性比纯 RTMP 好，延迟同样在 1~3 秒。
• HLS：Apple 公司设计的一种方式。它不传输持续的数据流，而是把视频切成一段一段几秒钟长的小文件（.ts 文件），然后用一个播放列表（.m3u8 文件）把这些小文件串起来。播放端就像下载普通文件一样，依次下载这些分片并按顺序播放。这种方式延迟最高（5~15 秒，因为必须攒够一个分片才能开始播），但有一个巨大的好处：兼容性极好——几乎所有手机、平板、浏览器都能直接播；而且这些分片文件可以被 CDN 缓存。CDN 是分布在世界各地的文件缓存服务器——把热门内容提前存放在离用户最近的服务器上，这样用户不用每次都去源服务器下载，速度快很多。

FPlayer 推流支持 RTMP / RTSP / SRT 三种协议（RTMP 最常用），拉流支持 RTMP / HTTP-FLV / HLS 三种。桌面端也具备拉流能力——可通过输入播放 URL 直接拉取远端流，并支持拉流同时录制。在服务器模式下，ZLMediaKit 会自动把收到的 RTMP 流转成 HTTP-FLV 和 HLS 两种格式同时输出。

先理解 YUV —— 画面在 FPlayer 内部的"通用语言"

在第一章讲 RGB 时我们说过，每个像素用 (R, G, B) 三个数值来表示颜色。但 FPlayer 内部不用 RGB 来存储和传输画面，而是用 YUV。为什么？

RGB 把每个像素的红、绿、蓝都完整存下来。一个 1920×1080 的画面，每个像素 3 个值，共约 6.2MB。YUV 的做法不同：它把"亮度"和"颜色"拆开了——Y 通道专门存亮度（明暗），U 和 V 通道存颜色信息。关键来了：在 YUV420 格式中，Y 每个像素都存，但 U 和 V 每 4 个像素才存一组。这样一帧只需要约 3.1MB——比 RGB 直接省了一半。

能这么省是因为人眼的生理特性：人眼视网膜上感知亮度的细胞（约 1.2 亿个视杆细胞）数量是感知颜色细胞（约 600 万个视锥细胞）的将近 20 倍。我们对"明暗"的敏感度远高于对"颜色细节"的敏感度。所以把颜色信息压缩到四分之一，人眼几乎看不出来。

▲ RGB 每像素存满 3 个值；YUV420 中 Y（亮度）每个都存，UV（颜色）4 个像素共用一组。利用人眼对亮度比颜色敏感 20 倍的生理特性，省一半空间而不影响观看体验。

怎么把海量数据压到能传得动？

YUV 格式已经比 RGB 省了一半——1080p 30fps 大约 93MB/秒。但这还是太大，局域网里勉强跑，互联网上传不动。必须用编码再压缩几百倍。

FPlayer 支持两种编码标准：H.264（目前最通用，所有设备都支持，压缩比约 100:1 ~ 200:1）和 H.265（也叫 HEVC，H.264 的升级版，相同画质下码率能再省约一半，但编码更费计算力，只有较新的设备才支持硬件解码）。

编码有两种实现途径：

硬件编码：显卡芯片上有一块专用的硬件电路，只做视频压缩这一件事，别的什么都不干。因为压缩算法被直接刻在了电路上（不是靠软件一步步执行），所以速度极快、功耗极低，而且不占 CPU 和 GPU 的通用计算资源。这块专用电路在不同品牌的显卡上有不同名字——NVIDIA 的叫做 NVENC，AMD 的叫做 AMF，Intel 核显的叫做 QSV（Quick Sync Video）。缺点是参数调节的灵活度不如软件编码——比如码率范围、某些高级画质参数可能调不了。

软件编码：用 CPU 运行一个编码程序。因为编码算法是软件代码，所有参数都可以自由调节，画质上限更高。但缺点也明显——CPU 要同时处理操作系统、FPlayer 界面、网络通信等一堆事情，再来一个极高负载的编码任务，很容易占满 CPU，导致整个电脑变慢。FPlayer 用的软件编码器是 libx264——H.264 标准的一个开源软件实现，是全世界应用最广的软件编码器之一。

FPlayer 启动推流时，会自动按优先级探测可用的编码器：

flowchart TD
    START["需要编码"] --> NV{"有 NVIDIA 显卡？"}
    NV -->|"有"| NVENC["NVENC 硬件编码"]
    NV -->|"无"| AMD{"有 AMD 显卡？"}
    AMD -->|"有"| AMF["AMF 硬件编码"]
    AMD -->|"无"| INTEL{"有 Intel 核显？"}
    INTEL -->|"有"| QSV["QSV 硬件编码"]
    INTEL -->|"无"| SW["libx264 CPU 软件编码
任何电脑都能用"]
    style NVENC fill:#cc785c,stroke:#cc785c,color:#fff
    style AMF fill:#cc785c,stroke:#cc785c,color:#fff
    style QSV fill:#cc785c,stroke:#cc785c,color:#fff
    style SW fill:#e8e0d2,stroke:#d9d0c0,color:#141413
      

这套策略对用户完全透明——你不需要知道自己电脑是什么显卡，软件自动找最好的方案。好显卡用硬件加速，没有独显用核显，连核显都没有就老老实实用 CPU——保证在任何电脑上都能正常推流。

推流的六种内部处理路径

FPlayer 的推流模块收到推流指令后，根据画面来源自动选择内部处理方式：

"流拷贝"（行业内叫 remux）和"转码"（行业内叫 transcode）有本质区别：流拷贝只换"外包装"——视频容器格式从 .mp4 变成 RTMP 网络流——但里面的压缩数据完全没动。所以速度只受硬盘读取速度限制，画质完全无损。转码则要把压缩数据完全解开再重新压缩——可以改变分辨率、码率、编码格式，但每次重新压缩都会有质量损失（就像反复保存 JPEG 图片，每次都会更模糊一点）。

声音是怎么处理的

推流不只有画面。FPlayer 处理声音的整个流程叫"音频管线"——"管线"在编程中的意思是数据经过的一系列按顺序排列的加工步骤。音频管线分五步：

1. 采集：在 Windows 上使用 WASAPI 接口直接捕获电脑正在播放的声音。WASAPI 是 Windows Vista 以后内置在操作系统里的音频子系统——相当于操作系统替你做了一套"录音"的底层机制，应用程序只需要调用它提供的接口，不需要自己去跟声卡硬件打交道。同时可以采集麦克风输入。
2. 混音：如果同时开了系统声音和麦克风，在这一步把两路混合成一路。需要处理音量平衡（系统声音和麦克风音量可能相差很大）、采样率不一致（系统声音可能是 48000Hz、麦克风是 44100Hz）的问题。Hz 即赫兹，表示每秒对声音波形取多少次样——数值越高声音越保真。
3. 格式统一：不同来源的音频可能有不同的声道数（单声道 vs 立体声）和采样率，在这一步统一成编码器需要的格式。
4. AAC 编码：把原始音频压缩成 AAC 格式。AAC（Advanced Audio Coding，高级音频编码）是目前最通用的音频压缩格式，所有手机、电脑、浏览器都支持。
5. 音视频交错：这是防止"音画不同步"的关键一步。音频帧和视频帧各自都带着时间戳，发送时不是"先把画面全发完再发声音"（那样播放端就会先看到画面没声音、然后突然有声音没画面），而是按时间戳交替排列：视频帧1 → 音频帧1 → 音频帧2 → 视频帧2 → 音频帧3 → 视频帧3。交错发送后，播放端按时间戳把画面和声音配对还原，就得到了同步的视听体验。

▲ 上：音频管线的五个处理步骤。下：音视频交错发送的顺序——视频帧和音频帧按时间戳交替排列，蓝色=视频，绿色=音频。

代码是怎么组织的

整个桌面端的代码分成 7 层，只遵循一条核心规则：只有 runtime 层知道所有后端的存在。

先讲清楚两个概念

接口 —— 一份"功能清单"

写程序就像盖房子。如果你把厨房、卧室、电线、水管全部混在一起砌——以后想换一个水龙头，就得砸墙。所以盖房子要分成结构、水电、装修等不同工种，每个工种只按规定的方式和其他工种对接。软件也是一样——要分模块，模块之间通过接口对接。

接口是什么？就是一份"你必须能做什么"的清单。比如"播放器接口"可能写：必须有播放、暂停、快进、调音量四个功能。至于这四个功能具体怎么实现——是用 FFmpeg 解码再渲染，还是调用系统自带的播放器——接口不管。接口只管"有没有"。

定义接口的好处：使用播放器的那些代码，只依赖这份清单，不依赖清单是怎么被实现的。以后想换一种播放方式，只要新的实现也满足接口的要求，所有使用它的代码一行都不用改。这种做法的核心价值是"解耦"——让软件的不同部分彼此不知道对方内部的细节，从而可以独立修改和替换。

FPlayer 定义了四个核心接口：IPlayer（播放器）、ICamera（摄像头）、IScreenCapture（屏幕捕获）、IStream（推拉流）。

后端 —— 接口的多种实现

同一个接口可以有多个后端——就是对于同一份"功能清单"，有几种不同的实现方式。FPlayer 的"播放器"接口就有两个后端：用 FFmpeg 自己写的（功能最强、支持格式最全）和用 Qt 自带的（代码最简单、集成最方便）。

你要一个播放器的时候，拿到的只是一个"实现了 IPlayer 接口的对象"——你可以调它的播放、暂停、快进，但它内部到底是 FFmpeg 还是 Qt，你不知道，也不需要知道。这种设计叫"策略模式"：同一个功能有多种实现策略，可以在运行时按配置选用哪一种。FPlayer 为什么要多后端？因为不同场景的最优解不一样——随手放个视频用 Qt 够简单，要全格式支持和精准控制用 FFmpeg，Windows 上高速抓屏用 DXGI。

七层架构

graph TD
    APP["app/ 启动层"]; WIDGET["widget/ 界面层"]; SERVICE["service/ 业务层"]
    RUNTIME["runtime/ 工厂层
← 唯一切换点"]
    BACKEND["backend/ 后端层
FFmpeg | Qt6 | DXGI"]
    API["api/ 接口层"]; COMMON["common/ 工具层"]
    APP-->WIDGET; WIDGET-->SERVICE; SERVICE-->RUNTIME
    RUNTIME-->BACKEND; BACKEND-->API; API-->COMMON
    WIDGET-->API; SERVICE-->API
    style RUNTIME fill:#cc785c,stroke:#cc785c,color:#fff
    style BACKEND fill:#e8e0d2,stroke:#d9d0c0,color:#141413
    style API fill:#efe9de,stroke:#e6dfd8,color:#141413
      

1. app/ 启动层 — ~140 行

   程序的入口。做的事：初始化环境 → 读命令行参数确定用哪个后端 → 创建主窗口 → 启动事件循环。事件循环是桌面程序运行的基础：程序启动后进入一个循环，不断问"有人点按钮了吗？有新画面帧到了吗？有网络数据来了吗？"——每发现一件事就调用对应的处理代码。这就是为什么你点按钮程序能立刻响应——事件循环一直在那等着。

2. widget/ 界面层 — ~8,800 行

   所有你看得到的按钮、弹窗、菜单、视频画面。核心组件：CaptureWindow（主窗口，管理三种采集模式切换 + 组合模式布局 + 推流设置）、FVideoView（视频显示控件，内部根据后端类型自动选择用 OpenGL 渲染还是 Qt 原生控件显示）、AiChatDialog（AI 对话窗口）、ImagePoolSidebar（截图管理侧栏）。

3. service/ 业务层 — ~1,800 行

   不做具体音视频处理，只做决策。比如你点"开始推流"，这一层判断：推的是摄像头还是屏幕还是文件还是组合画面？→ 组织推流参数 → 找 runtime 创建对应的推流对象 → 启动推流。

4. runtime/ 工厂层 — ~190 行（最关键）

   整个项目唯一知道所有后端存在的一层。它根据配置决定创建 FFmpeg 后端还是 Qt 后端还是 DXGI 后端。以后想加一个新后端——比如基于 GStreamer 或 MediaFoundation 的后端——只需实现 api/ 中的接口并在这一层注册，其他层完全不用动。这就是"把创建决策集中在一个地方"的价值。

5. backend/ 后端层 — ~13,800 行（真正干活）

   五个子模块：media_ffmpeg（FFmpeg 播放/采集）、media_qt6（Qt 播放/采集）、stream_ffmpeg（推拉流，最复杂）、desktopcapture_dxgi（显卡直接抓屏，仅 Windows）、net_qt6（局域网设备发现，空桩，默认关闭）。

6. api/ 接口层 — ~340 行

   只有四个头文件（.h 文件——在 C++ 中用来声明"有哪些东西可以用"而不写具体实现的文件），每个定义一个纯接口。刻意不引用任何 FFmpeg 或 Qt 的内部头文件——保持接口"纯净"。因为如果接口层依赖了 FFmpeg，所有使用接口的层也会被间接传染依赖 FFmpeg，那就失去了可替换后端的意义。

7. common/ 工具层 — ~1,200 行

   FGLWidget（OpenGL 渲染画面）、FrameBus（线程间传递帧数据）、DesignTokens（统一视觉配色）。

技术选型：为什么选这几样