FPlayer 技术面试准备

三端架构 + 控制面/数据面分离

桌面端 (C++) ──RTMP推流──→ ZLMediaKit ──HTTP-FLV/HLS──→ 移动端 (Flutter)
    │                            ↑                            │
    └─── REST API ──→ Gateway (Go) ←─── REST API ────────────┘
                      控制面 (会话管理/地址编排)

关键话术：

• "控制面用 Go 写了一个 Gateway，管理流会话、做 IP 可达性探测、地址编排"
• "数据面用 ZLMediaKit 做协议转换，RTMP 推进去自动出 HLS/HTTP-FLV/RTSP，一端推流全协议分发"
• "分离设计的好处：Gateway 挂了不影响正在推的流，ZLM 照常分发"

📍 gateway/main.go (859行) · kernel-console/main.go (647行)

• Go 编译为单二进制，部署简单 — 零外部依赖，仅用 net/http 标准库
• 内存会话管理（sync.RWMutex），比 Node.js 的 GC 可控
• 配合 kernel-console 做无头部署，一个 exe 搞定

📍 gateway/main.go · kernel-console/main.go

app/       → 入口 (main.cpp)               ~140 行
widget/    → UI 层 (CaptureWindow)        ~8,800 行
service/   → 业务编排层 (工厂模式)         ~1,800 行
runtime/   → 运行时工厂 (后端切换)          ~190 行
backend/   → 后端实现 (FFmpeg/Qt6/DXGI)   ~13,800 行
api/       → 抽象接口层 (纯虚类)            ~340 行
common/    → 公用工具 (OpenGL渲染器)       ~1,200 行

"依赖方向是 app → widget → service → runtime → backend → api，上层不依赖具体实现，通过 api/ 的纯虚接口解耦。"

📍 CMakeLists.txt 子目录依赖顺序

三线程架构：

1. 解复用线程 (demux)：av_read_frame() 读包 → 按 stream_index 分别 push 到视频/音频 packet queue
2. 解码线程 (decode)：从 packet queue 取包 → avcodec_send_packet / avcodec_receive_frame → YUV frame → push 到 frame queue
3. 音频线程 (audio)：从解码后的音频 frame queue 取 → swr_convert 重采样 → Qt QAudioSink 输出

关键细节：音视频同步以音频时钟为主时钟；非 YUV420P 用 sws_scale 转换；Seek 用 avformat_seek_file + 刷新编解码器缓冲区；EOF 循环自动重播。

📍 backend/media_ffmpeg/src/playerffmpeg.cpp (~1265行)

1. 音频线程每输出一帧，更新 audio_clock（基于 PTS + 已播放样本数/采样率）
2. 视频帧解码后读取其 PTS，与 audio_clock 比较：视频超前 → sleep（精确到毫秒）；视频落后 → 立即渲染（丢帧策略防止延迟累积）
3. 使用音频为主时钟的原因：人耳对音频不连续更敏感

📍 playerffmpeg.cpp — PTS 同步逻辑

• OpenGL 渲染需要统一格式，YUV420P 是三平面格式（Y/U/V 分离），纹理上传效率高
• YUV420P → RGB 转换在 GPU 侧 shader 完成，比 CPU 转省带宽
• OpenGL 纹理可以用 3 个 sampler2D 分别绑定 Y/U/V 平面

📍 common/src/fglwidget.cpp — OpenGL YUV 渲染器，双缓冲 PBO

编码器	厂商	FFmpeg 名称
NVENC	NVIDIA	h264_nvenc / hevc_nvenc
AMF	AMD	h264_amf / hevc_amf
QSV	Intel	h264_qsv / hevc_qsv
MediaFoundation	Windows 通用	h264_mf
软编码回退	—	libx264

选择策略：先检测 GPU 设备 → 优先同厂商硬编 → 无 GPU 回退软编 → 码率基于 BPP 模型自动估算

📍 backend/stream_ffmpeg/src/streamffmpeg.cpp

两种方案，可切换：

1. FFmpeg gdigrab：兼容性好，性能一般
2. DXGI Desktop Duplication：Windows 原生，低延迟，直接从 GPU 显存获取桌面帧，无需 CPU 拷贝，延迟比 gdigrab 低 80%+

📍 backend/media_ffmpeg/src/screencaptureffmpeg.cpp · backend/desktopcapture_dxgi/

协议	延迟	兼容性	适用场景
RTMP	1-3s	Flash 时代，H5 不支持	推流端（OBS/ffmpeg 生态好）
HTTP-FLV	1-3s	H5 需 MSE/flv.js	Web 低延迟播放
HLS	5-15s	全平台原生支持	移动端/Web 通用播放
RTSP	1-3s	监控行业	IPC 摄像头接入
SRT	1-3s	新兴协议	公网不稳定网络推流

设计逻辑：RTMP 做推流入口，ZLMediaKit 自动转封装 → HTTP-FLV（低延迟 Web 播放）+ HLS（iOS/Safari/微信内置浏览器），五种输出共存，客户端按能力选。

• 端到端延迟：局域网 1-3s（HTTP-FLV），公网 2-5s
• HLS 延迟高：分片策略（2s/段 × 3 段 = 最少 6s 缓冲），可调但牺牲稳定性
• 瓶颈：编码延迟 > 网络传输 > 播放缓冲
  • 编码：硬件编码器（NVENC ~10ms/frame）vs 软编码（x264 ultrafast ~30ms/frame）
  • 传输：局域网 RTMP over TCP 几乎无延迟
  • 缓冲：播放器的 jitter buffer / GOP 大小决定起播延迟
• 低延迟方案：WebRTC（<500ms），CMake 已预留编译开关，待后续版本实现

📍 fplayer-ff-service 项目 — ZLM HLS 分片配置 (segDur=2, segNum=3)

问题：服务在内网（192.168.x.x），外网客户端需要公网 IP

方案：Gateway 接受 publicHost 参数 → 地址编排时替换 URL 中的 host → FRP 做端口映射

外网客户端 → frp公网IP:1935 → FRP隧道 → 内网ZLM:1935
              ↑                      ↑
           publicHost覆盖        实际服务在内网

📍 gateway/main.go — publicHostOverride / publishHostForResponse()

"CaptureWindow 确实偏长，因为它承担了四种模式（摄像头/屏幕/文件/合成）的所有 UI 逻辑 + 推流拉流控制 + AI 对话框 + 截图库侧栏。当时为了快速迭代，先在一个文件里实现完整功能。如果要重构，会拆成独立 Controller + 组合模式。实际上 Service 层已经用工厂模式解耦了业务逻辑，UI 层的臃肿是时间问题不是设计问题。"

📍 widget/src/capturewindow.cpp (~6730行)

• 自定义 add_standard_module 宏：统一处理 AUTOMOC/AUTOUIC/AUTORCC + src/include/private/uis/res 目录结构 + 导出符号
• FFmpeg：预编译库，根据编译器（MSVC/MinGW/GCC）自动选择 lib 路径
• Logger/yaml-tool：通过 CPM.cmake 从 Git 拉取
• Qt6：通过 CMake find_package
• 构建选项：FPLAYER_BUILD_MEDIA_FFMPEG / FPLAYER_BUILD_STREAM_FFMPEG 等按需裁剪
• CPack 打包：NSIS (Win) + DEB/TGZ (Linux) + 自动下载 VC++ 可再发行组件

📍 CMakeLists.txt · cmake/3rd.cmake · cmake/utils.cmake

组件	Windows	Linux
桌面端	MSVC/MinGW + Qt6	GCC + Qt6
服务端	PowerShell 脚本 + .bat	Bash 脚本 + systemd
屏幕捕获	DXGI / gdigrab	X11 / xdg-portal
公网主机选择	直接选本机 IP	IP 可达性探测（UDP + 子网 + TCP）

1. 端口冲突处理：动态端口探测 — 优先常用端口，被占用则随机 — ZLM INI 动态补丁
2. 健康检查重试：Gateway 启动后轮询 /healthz，最多重试 8 次
3. 优雅关闭：退出时按顺序终止子进程（UI→Gateway→ZLM），1.5 秒超时后强制 kill
4. 播放器 EOF 处理：文件播放到末尾自动从头循环
5. API 幂等：同 app+stream 名称重复调用 start 不创建重复会话

📍 gateway/main.go · kernel-console/main.go (fplayer-ff-service)

• 单页播放器 lib/main.dart 1,431 行
• 双模式输入：服务模式（Gateway API 解析 URL）+ 直连模式（手动输入 URL）
• media_kit（libmpv 封装）支持 HLS/HTTP-FLV/RTMP
• 平台自适应：Web/Android 默认 HLS，Windows 默认 HTTP-FLV
• 设置持久化（SharedPreferences，7 个键值）
• 日志系统（200 条上限，按级别着色）
• Material 3 深/浅色主题

📍 lib/main.dart (1431行) · pubspec.yaml

• video_player 不支持 RTMP 和 HTTP-FLV（只支持 HLS/DASH/MP4）
• media_kit 底层是 libmpv，协议支持全（HLS/FLV/RTMP/RTSP 都行）
• libmpv 解码性能好（硬件解码），适合直播场景
• 代价：包体积增大 ~15MB（libmpv native libs）