1. 项目背景与核心价值
去年在给客户做智能家居方案时,经常遇到这样的场景:客户手机里的视频想投到客厅电视上播放,但市面上的投屏方案要么需要额外硬件,要么操作流程复杂。这让我萌生了开发一个轻量级局域网投屏工具的想法。经过三个月的迭代,最终完成这个开源项目,核心特点就是"最小可用"——不需要安装APP,打开网页就能用,延迟控制在200ms以内。
这个项目的技术本质是实现了WebRTC协议在局域网内的点对点传输。相比传统DLNA方案,我们的方案有两大突破:一是完全绕过云端服务器,数据直连更安全;二是采用自适应码率技术,能根据网络状况动态调整分辨率。实测在5GHz Wi-Fi环境下,1080P视频的端到端延迟可以稳定在180ms左右。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术架构设计解析
2.1 整体架构分层
项目采用典型的前后端分离架构:
code复制[前端] Web页面(React) ↔ [信令服务器](Node.js) ↔ [后端] 媒体中转服务(Golang)
前端负责视频采集和渲染,信令服务器处理设备发现和连接协商,媒体服务仅在中继模式下启用。这种设计使得在理想局域网环境下,数据可以不经过服务器直接传输。
2.2 关键协议选型
我们放弃了传统的RTSP协议,选择WebRTC主要基于三点考量:
- 浏览器原生支持,无需插件
- 内置NAT穿透能力(通过STUN/TURN)
- 支持硬件加速的H.264编码
实测数据表明,在相同网络条件下:
- WebRTC的端到端延迟比RTMP低40%
- CPU占用率比软解的RTSP低35%
2.3 信令系统设计
信令服务器采用WebSocket协议,主要处理三种消息类型:
- 设备发现:通过UDP组播广播设备信息
- SDP交换:协商媒体参数和网络地址
- ICE候选:收集NAT穿透所需网络路径
这里有个设计细节:我们为每个会话生成唯一的6位字母数字码(类似Zoom会议号),既避免了IP地址暴露,又方便用户快速配对。
3. 核心功能实现细节
3.1 视频采集与编码
前端使用MediaDevices API获取视频流,关键配置参数:
javascript复制const constraints = {
video: {
width: { ideal:
