简介围绕Miracast无线投屏的Source与Sink两端实现面向Android系统应用与框架开发者的代码示例包重点展示Sink接收端项目及Wi-Fi Display相关修改可帮助理解投屏链路中的设备发现、连接建立、视频流传输与显示等核心环节。压缩包共64个文件约212KB以C源码19个cpp、16个h为主辅以Java5个java、Android.mk构建脚本、XML配置、diff补丁及README等覆盖native/JNI层到框架修改层。已有5532人学习下载适合正在研究与实现Miracast/Wi-Fi Display功能的中高级开发者参考。通过分析其中源码、WifiDisplayController.diff补丁与构建脚本开发者能直观了解Sink端的初始化流程、协议处理、视频流解码与显示驱动调用路径。附带项目结构与脚本方便在Android系统上集成、调试或迁移到自有方案。 我最初想搜点 miracast 投屏 source/sink 端的代码案例结果前几页几乎全是 Source Insight 怎么配置护眼背景色的教程真正讲投屏协议栈怎么写的反而很少。这几年做车机投屏和电视盒子相关项目前期在 Wi-Fi Display 的 source 端和 sink 端上补了不少课把关键代码结构和踩过的坑整理出来给同样要做投屏开发的人当个参考。不管是做手机镜像到车机、电视盒子接收投屏还是想把桌面的内容投射到自研终端上这篇都适用。1. Miracast投屏的核心链路与角色定位1.1 source端与sink端到底在干什么Miracast 投屏里最基本的概念就是 source 和 sink。source 是发送端负责把本机的屏幕内容采集下来、编码成 H.264 视频流再通过无线网络发出去sink 是接收端负责接收网络上的视频流解码之后在本地显示。手机的“无线显示”开关就是 source 端电视、投影仪、车机大屏这些接收设备则扮演 sink 端。不少人会误会 source 和 sink 是上下级关系实际上它们在 Wi-Fi Display 架构里是对等的两个角色。source 主动投屏但协议栈的控制会话由 sink 发起sink 负责展示内容但推流节奏由 source 把控。理解这个关系对后面读代码和排查问题很有帮助。1.2 两条通道一条命RTSP控制面 RTP数据面Miracast 传递数据时有两条完全分开的链路。控制面走 TCP 7236 端口使用 RTSP 协议负责能力协商、会话建立、播放暂停等控制操作数据面走 RTP/RTCP使用 UDP 传输负责实际的音视频流。这两条通道缺一不可协商不通过数据面无法启动。用生活里的例子来类比RTSP 像两个人打电话约饭确定几点吃、吃什么、去哪吃RTP 就是真正的外卖送餐餐到了要确认送到、吃得是否满意。控制面协议严格但杂事多数据面流量大但职责单一。Wi-Fi Display 规范中定义了 M1 到 M16 一共 16 组 RTSP 交互报文其中建立会话阶段用 M1 到 M10后续控制用 M11 到 M16。我最初看到这些编号时有点懵后来总结了一个顺口溜先 OPTIONS再 GET_PARAMETER接着 SET_PARAMETER然后 SETUP最后 PLAY。核心流程能记住这句话协商阶段基本不会迷路。1.3 为什么建议自己动手写一遍源码你可能想系统不是自带投屏功能吗Android 有 Wireless DisplayWindows 也有 Miracast直接调用系统 API 不就行了。这个想法没错但有个前提你只是想在系统里“使用”投屏功能而不是“改造”投屏功能。一旦涉及的场景是车机 HMI、自研盒子、私有协议扩展或者需要在投屏链路上插播自己的 UI 和数据处理时系统 API 往往只能给你一个封装好的黑盒内部怎么协商、怎么处理异常完全不受控制。另一个现实原因是很多嵌入式平台根本没有官方投屏 SDK 可用。这种情况下自己实现一个精简可靠的 WFD 协议栈反而更实际。Miracast 的 RTSP 控制面其实不难难的是你愿不愿意把协议报文的每一个字段抠明白。2. Source端代码示例与实现要点2.1 搭建RTSP服务并等待sink接入source 端启动后第一步是在 TCP 7236 端口上起一个 RTSP server等待 sink 连接。在 Linux/嵌入式平台上用原生 socket 就能实现核心代码如下#include sys/socket.h #include netinet/in.h #include unistd.h #include string.h #include stdio.h #define WFD_RTSP_PORT 7236 int wfd_source_start(void) { int srv socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(WFD_RTSP_PORT); addr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(srv, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); return -1; } listen(srv, 4); for (;;) { int conn accept(srv, NULL, NULL); if (conn 0) { handle_rtsp_client(conn); close(conn); } } }这里要特别提醒生产环境不要用这种单线程阻塞模型至少要用 select/poll 或直接上 libevent。上面的代码仅用于演示协议交互逻辑实际项目中把 handle_rtsp_client 换成事件驱动的处理函数就可以了。2.2 能力参数的格式与含义RTSP 交互的核心是能力协商。sink 连上后会发送 OPTIONS、GET_PARAMETER、SET_PARAMETER 等请求source 端要能解析并正确响应。响应报文里的关键参数是 wfd_video_formats、wfd_audio_codecs、wfd_client_rtp_ports。这几个参数不填对sink 可能直接断开连接。void handle_rtsp_request(int conn, const char *request) { char method[16], rtsp_uri[128], version[16]; int cseq 0; // 解析请求行: OPTIONS rtsp://127.0.0.1/wfd1.0 RTSP/1.0 sscanf(request, %15s %127s %15s, method, rtsp_uri, version); if (strcmp(method, OPTIONS) 0) { dprintf(conn, RTSP/1.0 200 OK\r\n CSeq: %d\r\n Public: org.w3.2020_11.wfd\r\n\r\n, cseq); } else if (strcmp(method, GET_PARAMETER) 0) { // 返回本端支持的参数组合 dprintf(conn, RTSP/1.0 200 OK\r\n CSeq: %d\r\n Content-Type: text/parameters\r\n Content-Length: 200\r\n\r\n wfd_video_formats: 01 1 000000FF 00000000 00000000 00 0000 0000 00 none 0 0 0 none\r\n wfd_audio_codecs: LPCM 00000003 00 AAC 0000000F 00\r\n, cseq); } else if (strcmp(method, SET_PARAMETER) 0) { // 保存 sink 希望使用的参数 dprintf(conn, RTSP/1.0 200 OK\r\n CSeq: %d\r\n\r\n, cseq); } else if (strcmp(method, SETUP) 0) { dprintf(conn, RTSP/1.0 200 OK\r\n CSeq: %d\r\n Session: 0123456789\r\n\r\n, cseq); } else if (strcmp(method, PLAY) 0) { // 收到 PLAY开始推流 dprintf(conn, RTSP/1.0 200 OK\r\n CSeq: %d\r\n Range: npt0.000-\r\n\r\n, cseq); } }注意代码里 CSeq 需要从请求头里解析出来并原样返回这里省略了解析函数。实际开发中如果不回 CSeq 或者回错很多严格实现的 sink 端会直接认为协商失败。wfd_video_formats 那一串参数从“01”到“none”每个字段都有含义依次是 native 格式数量、偏好格式索引、编码 Profile 支持掩码、最大分辨率布局等。平时不遇到兼容性问题是最好遇到以后再逐字段抠也来得及。2.3 屏采、编码和RTP推流协商完成之后source 端开始正式干活核心链路是“屏幕采集 → H.264 编码 → RTP 打包发送”。屏幕采集在 Windows 上一般用 DXGI Desktop DuplicationLinux 上可以用 PipeWireAndroid 上用 MediaProjection。编码优先使用硬件编码器比如 NVENC、VAAPI、MediaCodec软编 x264 在低分辨率场景也能接受但高分辨率下 CPU 会吃不消。RTP 打包最省事的方式是直接用 FFmpeg 的 rtp_mpegts 或 rtp_h264 相关 muxer它会自动处理 H.264 的 NALU 分片和 FU-A 拆分。想快速验证链路可以用 GStreamer 的命令行不需要写代码# source 端采集桌面并推流 gst-launch-1.0 ximagesrc use-damagefalse ! videoconvert ! \ x264enc tunezerolatency ! h264parse ! rtph264pay pt96 ! \ udpsink hostsink_ip port8000实际项目中我会先跑通这条管道再逐步替换成自己的采集和编码模块。RTP 推流时有一个关键点每个关键帧 I 帧的开头最好带一个关键帧标志方便 sink 端快速定位每个 NALU 的最后一包要打上 RTP Marker 位否则对端无法判断 NALU 边界。3. Sink端代码示例与实现要点3.1 扫描P2P设备并建立RTSP会话sink 端的工作流程和 source 是对称的。第一步是搜索附近的 source 设备并建立 Wi-Fi Direct 连接。通常 source 端会作为 P2P Group OwnerIP 地址往往是固定的 192.168.49.1sink 加入该 P2P 组后直接连接这个地址的 7236 端口。建立 TCP 连接后sink 需要依次发送 M1 到 M10 的 RTSP 请求。发送非常简单就是一个带格式的文本报文关键在于请求顺序和参数匹配int wfd_start_rtsp(const char *source_ip) { int fd socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_port htons(7236); inet_pton(AF_INET, source_ip, addr.sin_addr); if (connect(fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(connect); return -1; } // M1: OPTIONS send_rtsp(fd, OPTIONS rtsp://127.0.0.1/wfd1.0 RTSP/1.0, 1); // M3: GET_PARAMETER send_rtsp(fd, GET_PARAMETER rtsp://127.0.0.1/wfd1.0 RTSP/1.0, 2); // M5: SET_PARAMETER设定视频/音频格式和接收端口 send_rtsp(fd, SET_PARAMETER rtsp://127.0.0.1/wfd1.0 RTSP/1.0\r\n Content-Type: text/parameters\r\n Content-Length: 120\r\n\r\n wfd_video_formats: 01 1 000000FF 00000000 00000000 00 0000 0000 00 none 0 0 0 none\r\n wfd_client_rtp_ports: RTP/AVP/UDP 38500 0 0\r\n, 3); // M7: SETUP send_rtsp(fd, SETUP rtsp://127.0.0.1/wfd1.0 RTSP/1.0, 4); // M9: PLAY send_rtsp(fd, PLAY rtsp://127.0.0.1/wfd1.0 RTSP/1.0, 5); return fd; }这里 wfd_client_rtp_ports 后面的 38500 就是本端希望接收视频流的 UDP 端口source 端会往这个端口发数据。很多新手会把 source 的 IP 填到 host 字段实际上在控制面协里RTSP 请求的 URL 一直写 rtsp://127.0.0.1/wfd1.0 即可因为 RTSP 请求本身就跑在已建立的 TCP 连接上这个 URL 只是用于标识会话对象。3.2 接收RTP与解码显示链路RTSP 会话建立成功后sink 就需要在 38500 端口监听 UDP 数据包。收到的 RTP 包解出来是 H.264 码流要经过“组帧 → 解码 → 显示”三个步骤。组帧阶段要注意一个 NALU 可能被拆成多个 FU-A 分片包发送需要根据 RTP Sequence Number 和 Marker 位来拼接还原完整的 NALU再交给 H.264 解码器。用 FFmpeg 接收 RTP 流时有一个省力技巧直接用 libavformat 的 rtp 协议和 h264 depay 插件它会自动处理 RTP 解包、FU-A 重组以及 SPS/PPS 缓存。库的调用逻辑是标准的“打开输入流 → 读取 AVPacket → 解码 → 渲染”不需要自己在应用层处理 RTP 解析代码量会小很多。想快速验证 sink 端同样推荐先跑通 GStreamer 管道再上代码# sink 端接收 UDP 8000 端口的 RTP 流并显示 gst-launch-1.0 udpsrc port8000 ! \ application/x-rtp,encoding-nameH264 ! \ rtph264depay ! h264parse ! avdec_h264 ! autovideosink这套管道我在调试中用过无数次配合源端的推流命令几乎可以在一分钟内验证两端的数据通路是否正常。3.3 时钟同步和延迟控制音视频同步是 sink 端最容易翻车的一环。Miracast 的数据面通过 RTCP Sender Report 报文传递时间戳信息sink 端拿到 RTP 时间戳后需要把它映射到本地播放时钟。很多开发者在最初会把本地系统时间直接当作播放时钟结果一旦投屏中断重连或者 RTCP 报文抖动音画就彻底对不上。CTS 测试里关于 sink 端 clock latency 的流程本质上就是验证 sink 是否能在合理的时间窗口内完成音视频缓冲和播放。我自己的做法是在 sink 端维护一个独立的 RTP 时钟基准根据 RTCP SR 报文中的 NTP 时间戳和 RTP 时间戳建立映射关系音频和视频都基于同一个基准进行播放调度而不是各自用系统时间。缓冲长度一般控制在 100ms 到 300ms 之间太低容易卡顿太高延迟明显。4. 常见问题与排查技巧实录4.1 连接建立失败这是投屏开发里出现频率最高的问题现象是 sink 发起连接时超时或者 source 端根本看不到 sink 发来的 RTSP 报文。排查顺序我通常固定为三步第一步看 P2P 连接是否建立成功source 是否拿到了设备列表第二步检查 7236 端口是否在监听用 netstat 一看便知第三步看防火墙和 ACL 规则是否把端口放行。不少嵌入式设备在生产环境中会配置网络安全策略ACL 规则往往只放行了常用的 80、443 端口7236 不在放行列表里自然连不上。还有一个隐蔽的坑是有些射频方案在低功耗模式下会定期休眠 P2P 接口sink 扫不到设备这类问题要检查驱动层的电源管理策略。4.2 花屏、绿屏和黑屏播放过程中出现花屏或者绿屏第一个要怀疑的是关键帧丢失。H.264 的 P 帧依赖前面的参考帧一旦参考帧数据不完整后续所有帧都会解码异常。Miracast 协议里专门定义了 wfd_idr_request 参数sink 端在发现解码异常时可以通过 RTSP 的 SET_PARAMETER 请求主动向 source 要一个关键帧这是标准的恢复手段。第二个常见原因是 MTU。Wi-Fi Direct 的链路 MTU 通常和普通 Wi-Fi 一样是 1500 字节但实际射频环境可能会有更小的链路 MTU。如果 RTP 包过大导致中间分片丢失视频流就会出现周期性花屏。排查时可以在 source 端把 RTP 的 max_packet_size 调小比如设置为 1400观察是否改善。还有一个嵌入式环境特有的坑交叉编译时找不到arm_acle.h、core_cm0plus.h这类内核头文件。这是因为解码库依赖了编译工具链之外的 CMSIS 头文件需要把对应的头文件路径加进编译器的 include 目录。遇到这种错误不要慌本质是头文件搜索路径配置问题手动指定一下就行。4.3 音画不同步和延迟控制音画不同步分两种情况一种是从投屏开始就一直不同步比如音频快视频慢这类问题多半是解码器和播放流程里音视频两路操作的等待时间不一致导致的另一种是投屏之后过了一段时间才出现不同步这种通常是 RTP 时间戳和本地时钟出现漂移需要靠 RTCP 的 Receiver Report 反馈来逐步校正。延迟过高是另一个被反复投诉的问题。在保证画面流畅的前提下延迟的优化空间主要在缓冲队列。sink 端解码前的输入队列不要一味地“攒包”应该根据 RTCP 的网络统计动态调整source 端编码时使用 zerolatency 参数并关闭 B 帧也能显著降低链路延迟。不过我实际体验下来延迟和稳定性之间永远需要做 trade-off不要为了追求极低延迟而让画面频繁卡顿。5. 实操心得与后续扩展思路5.1 做source和做sink的心态差异做了几个项目之后我有个比较深的感受source 端的开发复杂在采集和编码一旦链路搭通后面基本都是协议细节的修修补补sink 端的开发前期看着简单后期容易陷进兼容性泥潭。同一个 source 发来的流在不同品牌电视上可能表现完全不同问题往往出在对 WFD 参数格式的解析严格程度上。所以如果你做的是 sink 端产品建议一开始就把 RTSP 解析器写得健壮一些对各种参数缺失、格式不规范的场景都要能兜底。不要假设所有 source 都会规规矩矩地发标准报文实际产品里的 source 设备五花八门兼容性就是 sink 的生命线。5.2 从demo到产品的扩展点跑通最基本的投屏 demo 之后真正的产品化才是重头。第一个要加的是异常恢复机制比如 RTSP 会话超时重连、RTP 流中断检测后自动重新协商。第二个是 UI 交互层source 端需要显示“正在连接”“连接失败”的状态反馈sink 端可能需要做多设备管理或者投屏码验证。第三个是安全和数据保护如果投屏内容涉及敏感信息可以在 RTP 层做加密和鉴权尽管这会引入一定的延迟开销。投屏这个领域不算特别新颖但真正能把 source 和 sink 两端代码写得通透、跑得稳定的人其实并不多。多调试、多看协议、多记录坑能力就是在这一次次踩坑中积累起来的。本文还有配套的精品资源点击获取