文档教程【免费下载链接】pikvmOpen and inexpensive DIY IP-KVM based on Raspberry Pi项目地址https://gitcode.com/gh_mirrors/pi/pikvm点击查看免费下载H.264 视频编码相比传统 VNC 的 JPEG 帧压缩能显著节省网络流量、提升弱网环境下的操作响应性。本篇技术文章以 PiKVM 项目 2021 年初发起在 VNC 中实现 H.264 支持的社区倡议为起点结合仓库内后续的 KVMD 版本发布记录与 VNC 官方使用文档完整梳理该功能从协议协商、IANA 注册、服务端实现到 TigerVNC 客户端支持落地的演进过程并给出在 PiKVM 上实际启用 VNC、配置 H.264 客户端的具体操作步骤。背景为什么 VNC 需要 H.264PiKVM 是一个基于 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.mdKVMD 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.mdKVMD 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 编码器默认启用的内核关键 bugVNC 场景下的 H.264 现已可尝试适用范围为PiKVM V2 及基于 CSI bridge 的采集方案当时仍强调这还不是最终的官方实现但一切应当工作正常Web 界面侧的 H.264 支持仍在推进中同时进行了H.264 RFBVNC协议的标准化工作标准正在等待确认。2021-06-10KVMD 3.0 大版本发布WebRTC H.264 全面上线docs/blog/posts/2021/2021-06-10/index.mdKVMD 3.0 发布日志宣布了六个月的研发成果视频不再依赖流量巨大的 MJPEG而是可以在 Web UI 中使用WebRTC H.264模式显著降低流量消耗并提升弱网响应性MJPEG 与 H.264 两种模式可随时切换。H.264 编码能力正式成为 PiKVM 的默认视频能力。客户端侧TigerVNC 1.13.0 支持 H.264当前官方 VNC 使用指南 中已明确记录客户端侧的支持状态If youre 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客户端推荐使用TigerVNCH.264 支持的关键前提。将 PiKVM 文件系统切换为读写模式rw可选若客户端不支持直接键盘访问为非 US 键盘强制指定客户端布局在/etc/kvmd/override.yaml中配置vnc: keymap: /usr/share/kvmd/keymaps/ru可用 keymap 位于/usr/share/kvmd/keymaps目录下对应截图见 docs/vnc/keymaps.png。可选非 TigerVNC 客户端且不推荐为不支持用户名/密码认证的客户端如 TightVNC勿与 TigerVNC 混淆启用 VNCAuth 口令模式vnc: auth: vncauth: enabled: true口令写入/etc/kvmd/vncpasswd文件。官方明确警告这是一种不安全的认证方式应优先使用 TigerVNC。启用kvmd-vnc守护进程VNC 监听在5900端口systemctl enable --now kvmd-vnc将文件系统切回只读模式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.pngCompression 标签页选择支持 H.264 的编码方式不支持 H.264 时选择TightSecurity 标签页使用 TLS/X.509 或 vencrypt 等安全认证方式。同时官方给出安全警告不要在不可信网络上使用无 X.509 或 TLS 加密的 VNC否则密码将以明文在网络上传输——这是 VNC 协议本身长期存在的现实问题。iOS / Android 移动端推荐使用bVNC客户端。理解 H.264 流参数bitrate 与 gop 对流量和延迟的影响当 VNC 会话使用 H.264 后流质量与流量消耗主要由两个参数决定相关说明见 docs/video.mdH.264 kbps比特率值越大画质越好但网络流量同步上升H.264 gopGroup 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.0Windows 有官方二进制其他平台需以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 带来的流量节省与弱网响应性提升。赞分享文档教程【免费下载链接】pikvmOpen and inexpensive DIY IP-KVM based on Raspberry Pi项目地址https://gitcode.com/gh_mirrors/pi/pikvm点击查看免费下载相关推荐Label Studio 数据标注完全指南4步从本地部署到导出标注数据Label Studio 数据标注完全指南4步从本地部署到导出标注数据 Label Studio 是一个开源的多模态数据标注工具图像、文本、音频、视频、时间数据标注人工智能Authlib动态客户端注册终极指南RFC7591和RFC7592协议完整实现Authlib动态客户端注册终极指南RFC7591和RFC7592协议完整实现 在当今的数字化时代OAuth 2.0动态客户端注册协议RFC7591和RF深入理解PettingZoo AEC与Parallel API选择最适合你项目的接口深入理解PettingZoo AEC与Parallel API选择最适合你项目的接口 PettingZoo作为多智能体强化学习环境的API标准提供了两种核心人工智能深度学习机器学习上一篇如何以 Magisk 的 BusyBox ASH Standalone Shell Mode 运行自己的脚本下一篇K3s在海洋监测中的应用浮标设备数据处理创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考