企业官网建设流程全解析

• 文档
• 教程

H.264 视频编码相比传统 VNC 的 JPEG 帧压缩能显著节省网络流量、提升弱网环境下的操作响应性。本篇技术文章以 PiKVM 项目 2021 年初发起"在 VNC 中实现 H.264 支持"的社区倡议为起点，结合仓库内后续的 KVMD 版本发布记录与 VNC 官方使用文档，完整梳理该功能从协议协商、IANA 注册、服务端实现到 TigerVNC 客户端支持落地的演进过程，并给出在 PiKVM 上实际启用 VNC、配置 H.264 客户端的具体操作步骤。

背景：为什么 VNC 需要 H.264

PiKVM 是一个基于 Raspberry Pi 的开源 DIY IP-KVM，视频链路是硬件级采集的：OS -> 显卡 -> PiKVM 视频采集 -> PiKVM 服务端 -> 网络 -> 客户端（见 docs/vnc.md 中的说明）。它不像常规远程桌面那样由操作系统内部直接出流，因此在同等画质下对编码效率更为敏感。

经典 VNC 协议默认使用JPEG 帧内压缩（Tight/JPEG 编码），每帧都是独立编码，流量开销大；而H.264是帧间预测编码，能利用时间冗余大幅降低码率。对 PiKVM 这类需要长时间看管 BIOS、安装操作系统、处理卡死服务器的场景来说，H.264 意味着在同等网络条件下更低的流量消耗和更跟手的操作体验。README 中也将"H.264-over-HTTP 与 WebRTC、MJPEG"并列为项目的核心视频能力（见 README.md）。

2021-01-19：面向社区的 H.264-in-VNC 开发倡议

仓库中的 docs/blog/posts/2021/2021-01-19/index.md 是一篇发布于 2021 年 1 月 19 日的开发日志，标题为Implementing H264 support for VNC，其核心内容如下：

• 目标：让使用 VNC 的用户能够通过 H.264 降低流量。
• 核心困难：没有任何 VNC 客户端支持 H.264。服务端方面作者已经准备好——他愿意编写服务器端代码，并且已经拥有稳定的 H.264 编码器，瓶颈完全在客户端一侧。
• 协作计划：作者打算与TigerVNC开发者协商，共同确定一套新协议：作者实现服务端，TigerVNC 实现客户端。
• 众筹提议：由于这对 TigerVNC 团队而言优先级较低，作者建议有需求的用户自愿参与众筹（目标金额约 $500），用于酬谢 TigerVNC 的开发工作，并计划通过 BountySource 发放赏金。

这篇日志的定位是"项目发起方向社区征求客户端侧协作"的公开倡议：H.264 编码、RFB 协议扩展、服务端实现均已具备可行基础，缺的只是生态中客户端对新增编码格式的接纳。

仓库中的后续进展：从注册协议到客户端落地

倡议并非停留在口头，仓库内后续的多篇发布日志记录了该功能的完整落地过程，形成了一条清晰的时间线：

2021-02-21：协议在 IANA 注册

docs/blog/posts/2021/2021-02-21/index.md（KVMD 2.27 发布日志）中写道：

A lot of work has been done to use H.264 with VNC. At the moment, we have registered our new protocol in IANA and are waiting for the applying of patches in TigerVNC and the fixing of some bugs in the kernel related to HDMI and H.264.

即在 2021 年 2 月，PiKVM 团队已将H.264-in-VNC 的新协议在 IANA 完成注册，进入标准化通道；剩余工作是与 TigerVNC 的补丁对接，以及修复内核中与 HDMI 采集和 H.264 编码相关的 bug。同期该版本还加入了 VNC X.509 加密支持，并改进了 VNC 帧处理效率。

2021-03-13：内核 bug 修复，H.264 for VNC 开放试用

docs/blog/posts/2021/2021-03-13/index.md（KVMD 2.31 发布日志）标志着功能进入可试用阶段：

A critical bug has been fixed in the kernel that prevents the H264 encoder from being enabled by default, so now everyone can try H264 for VNC for v2 and CSI bridge (only).

关键信息：

• 修复了一个阻止H.264 编码器默认启用的内核关键 bug；
• VNC 场景下的 H.264 现已可尝试，适用范围为PiKVM V2 及基于 CSI bridge 的采集方案；
• 当时仍强调"这还不是最终的官方实现，但一切应当工作正常"，Web 界面侧的 H.264 支持仍在推进中；
• 同时进行了H.264 RFB（VNC）协议的标准化工作，"标准正在等待确认"。

2021-06-10：KVMD 3.0 大版本发布，WebRTC H.264 全面上线

docs/blog/posts/2021/2021-06-10/index.md（KVMD 3.0 发布日志）宣布了六个月的研发成果：视频不再依赖流量巨大的 MJPEG，而是可以在 Web UI 中使用WebRTC + H.264模式，显著降低流量消耗并提升弱网响应性，MJPEG 与 H.264 两种模式可随时切换。H.264 编码能力正式成为 PiKVM 的默认视频能力。

客户端侧：TigerVNC >= 1.13.0 支持 H.264

当前官方 VNC 使用指南 中已明确记录客户端侧的支持状态：

If you're using PiKVM V3+ or DIY based on CSI bridge, you can try the latest version (>= 1.13.0) of TigerVNC with H.264 support. It will improve performance and save traffic. H.264 video mode is available in binary builds for Windows, for other OS it needs to be compiled manually (ffmpeglibraries required to build).

也就是说：

• TigerVNC 1.13.0 及以上版本已内置 H.264 支持，适用于 PiKVM V3+ 或基于 CSI bridge 的 DIY 设备；
• Windows 二进制构建直接可用；其他操作系统需要手动编译，编译依赖ffmpeg库。

从 2021 年 1 月的倡议，到协议注册、内核修复、KVMD 3.0 发布，再到 TigerVNC 客户端原生支持，这一"服务端开源实现 + 客户端厂商协作"的路线图在仓库文档中完整可查。

服务端配置：在 PiKVM 上启用 VNC

要体验 VNC 场景，首先需在 PiKVM 侧启用 VNC 服务。官方步骤见 docs/vnc.md：

1. 客户端推荐使用TigerVNC（H.264 支持的关键前提）。

2. 将 PiKVM 文件系统切换为读写模式：

   rw

3. （可选）若客户端不支持直接键盘访问，为非 US 键盘强制指定客户端布局，在/etc/kvmd/override.yaml中配置：

   vnc: keymap: /usr/share/kvmd/keymaps/ru

   可用 keymap 位于/usr/share/kvmd/keymaps目录下（对应截图见 docs/vnc/keymaps.png）。

4. （可选，非 TigerVNC 客户端且不推荐）为不支持用户名/密码认证的客户端（如 TightVNC，勿与 TigerVNC 混淆）启用 VNCAuth 口令模式：

   vnc: auth: vncauth: enabled: true

   口令写入/etc/kvmd/vncpasswd文件。官方明确警告：这是一种不安全的认证方式，应优先使用 TigerVNC。

5. 启用kvmd-vnc守护进程，VNC 监听在5900端口：

   systemctl enable --now kvmd-vnc

6. 将文件系统切回只读模式：

   ro

注意：若启用了 2FA，需将一次性验证码无空格地附加到密码之后，例如密码foobar、验证码123456时，应输入foobar123456。

从仓库结构看，kvmd-vnc是 KVMD 服务栈中与 Web UI 并列的独立守护进程：API 文档 的info_extras_state事件中列出了kvmd-vnc（端口 5900）作为可展示的附加服务信息项，与kvmd-ipmi（端口 623）并列，说明 VNC 是 PiKVM 正式的一等公民访问通道。

客户端配置：TigerVNC 的 H.264 设置

桌面端推荐使用 TigerVNC。在 PiKVM V3+ 或 CSI bridge 方案上，应使用>= 1.13.0 的版本以启用 H.264 模式；若客户端不支持 H.264，则压缩方式应选择Tight作为回退。

官方 VNC 指南 给出了推荐的客户端设置（Compression 与 Security 两个标签页），见 docs/vnc/tigervnc_compression.png 与 docs/vnc/tigervnc_security.png：

• Compression 标签页：选择支持 H.264 的编码方式（不支持 H.264 时选择Tight）；
• Security 标签页：使用 TLS/X.509 或 vencrypt 等安全认证方式。

同时官方给出安全警告：不要在不可信网络上使用无 X.509 或 TLS 加密的 VNC，否则密码将以明文在网络上传输——这是 VNC 协议本身长期存在的现实问题。

iOS / Android 移动端推荐使用bVNC客户端。

理解 H.264 流参数：bitrate 与 gop 对流量和延迟的影响

当 VNC 会话使用 H.264 后，流质量与流量消耗主要由两个参数决定，相关说明见 docs/video.md：

• H.264 kbps（比特率）：值越大画质越好，但网络流量同步上升；
• H.264 gop（Group of Pictures，帧组）：强制插入参考帧（关键帧）的间隔帧数。gop 越大，参考帧越稀疏，平均码率越低；gop 越小，随机访问和错误恢复越快。

视频模式文档 给出的调优建议是：

• 网络良好：使用WebRTC或Direct模式，设H.264 gop = 0；
• 弱网 + WebRTC：设H.264 gop = 60；
• 弱网 + Direct：设H.264 gop = 0。

这套参数同样适用于 VNC 场景的带宽管理：H.264 正是通过减少参考帧、压缩时间冗余来实现"save traffic"，而这正是最初倡议所追求的目标。另外从源码文档可确认，KVMD 的 API 层提供了h264_bitrate与h264_gop两个可配置项（默认值分别为 5000 kbps 与 30，见 docs/api.md），是 Web UI 与底层 ustreamer 编码器之间的参数通道。

使用前提与已知局限

结合仓库文档，实际使用 H.264-in-VNC 需要注意以下边界条件：

• 硬件前提：H.264 编码依赖 Raspberry Pi 的 GPU/CSI 采集链路。2021-03-13 发布日志明确 H.264 for VNC 面向V2 与 CSI bridge 方案；VNC 指南 进一步将客户端支持范围描述为PiKVM V3+ 或基于 CSI bridge 的 DIY 设备；
• 客户端前提：需要TigerVNC >= 1.13.0；Windows 有官方二进制，其他平台需以ffmpeg库手动编译；
• 认证安全：优先使用 TigerVNC 的用户名/密码认证与 TLS/X.509 加密；VNCAuth 口令模式被官方明确标注为不安全；
• 协议仍在演进：历史上该 RFB 扩展经历了 IANA 注册与标准化确认过程，早期试用版本（KVMD 2.31 时代）即被注明"尚非最终官方实现"。

综合来看，PiKVM 的 H.264-in-VNC 是一个罕见的"开源服务端 + 上游客户端协作"成功样例：项目方在 2021 年初公开倡议并牵头协议标准化，随后通过 IANA 注册、内核 bug 修复与 KVMD 大版本发布逐步落地，最终在 TigerVNC 1.13.0 中获得了客户端原生支持，让 VNC 用户得以在保持兼容性的同时享受 H.264 带来的流量节省与弱网响应性提升。

• 文档
• 教程