一、基本概念

        Miracast 是一套通用无线投屏标准，底层协议为 Wi-Fi Display（WFD），旨在让手机、笔记本电脑等设备，能通过Wi-Fi直连的方式，实时把屏幕画面、音频同步镜像传输到电视、投影仪等大屏幕上，源设备屏幕上显示什么，接收端同步显示什么，整个过程无需任何线缆，标准 P2P 模式下也无需依赖现有无线路由器（Source和电视直接 Wi-Fi Direct 连接）。

        Wi-Fi Display（WFD）是由 Wi-Fi Alliance（Wi-Fi 联盟）制定的技术规范、底层通信协议标准，定义一套完整无线屏幕镜像交互规则。

        RTSP（Real-Time Streaming Protocol，实时流协议）是 Miracast 体系的核心信令控制协议，在投屏场景下固定使用 TCP 7236 端口通信，仅负责会话控制，不承载音视频码流，音视频媒体数据由 RTP 承载传输。RTSP是通过 OPTIONS、GET_PARAMETER、SETUP、PLAY、TEARDOWN 等指令完成设备能力查询、媒体通道创建、投屏启停与链路保活等控制逻辑。

二、核心角色

1、Source（发送方/源端）

        通俗的来讲就是手里有画面、负责往外“输出屏幕”的设备，比如你手机开启无线投屏，手机本身就是 Source。主要是用来采集屏幕画面、音频，编码音视频，发起连接，持续推送音视频流。常见设备有安卓手机、Windows PC等。

                

2、Sink（接收方/宿端）

        通俗的来讲就是负责接收画面、解码、显示出来的设备。主要用来接收码流、解码、渲染画面与音频，输出显示，常见设备有智能电视、电视盒子、投影仪等。

                 

 

二、RTSP 信令流程

        WFD 规范将两端交互信令定义为 M1~M8 共 8 个交互阶段。

表1    WFD 规范文档里定义的协议阶段

编号	RTSP 方法	方向	作用
M1	OPTIONS	Source → Sink	Source探测 Sink 支持哪些 RTSP 方法
M2	OPTIONS	Sink → Source	Sink 反向探测Source支持哪些方法
M3	GET_PARAMETER	Source → Sink	Source查询 Sink 的视频/音频/HDCP 能力
M4	SET_PARAMETER	Source → Sink	Source下发自身参数，Sink 做交集
M5	SET_PARAMETER	Source → Sink	Source指定触发方式（SETUP 或 PLAY）
M6	SETUP	Sink → Source	Sink 发起音视频传输通道协商
M7	PLAY	Sink → Source	Sink 请求开始传输音视频流
M8	TEARDOWN	Sink → Source	Sink 请求正式拆链，终止会话

1、OPTIONS（双向探测 WFD 协议支持）

        M1 由Source询问 Sink ，查询Sink端支持哪些 RTSP 指令，然后Sink会回复，如果 Sink Public 没有宣告支持GET_PARAMETER，Source就会直接终止投屏握手。而M2是Sink 反过来向Source发 OPTIONS查询支持哪些指令，只有双方互相确认支持WFD之后，才能进入 M3 能力查询阶段。关键报文如下：

M1请求报文：

Request：客户端请求包。

OPTIONS：RTSP 请求方法。用来查询 Sink 端支持哪些 RTSP 指令（GET_PARAMETER、SETUP、PLAY 等），Miracast 会话第一条消息。

RTSP/1.0：使用 RTSP 1.0 标准协议。

Date: 报文发送UTC 标准时间； Miracast 里一般不做校验，标准 HTTP/RTSP 规范必填字段。

Server: stagefright/1.2 (Linux;Android 12)，标识发送端（手机 Source）多媒体框架 stagefright为 Android 原生多媒体引擎，说明发送端是 Android 设备。

CSeq：Command Sequence 命令序列号，每一条 RTSP 请求携带一个递增数字； Sink 回复消息必须携带相同 CSeq 编号，用来请求与应答一一匹配。 多条 RTSP 消息并发时，依靠 CSeq 区分哪个回复对应哪条请求。

Require：扩展能力要求字段，org.wfa.wfd1.0 代表Wi-Fi Display WFD 1.0 协议标识。

M1响应报文：

Response：服务端返回响应；

Public：告知对端本设备支持的扩展协议与 RTSP 方法；

org.wfa.wfd1.0：支持 WFD 1.0（Miracast 投屏协议）；

GET_PARAMETER：支持查询参数（投屏心跳、读取设备能力）；

SET_PARAMETER：支持设置参数（协商 UIBC、配置媒体参数）。

M2请求报文：

M2响应报文：

2、GET_PARAMETER（能力查询，获取参数）

        Source 向 Sink 查询硬件能力，请求读取 wfd_video_formats（分辨率、帧率、H.264 Profile/Level 等视频解码规格）、wfd_audio_codecs（支持的音频编码格式）、wfd_content_protection（是否支持 HDCP 加密）、wfd_client_rtp_ports（RTP 接收端口）以及 wfd_uibc_capability（反向控制能力）等关键参数。Sink 将自身解码能力全量上报，Source 拿到后将 Sink 的能力清单与自身编码能力取交集，据此为下一阶段 M4 选定最终的音视频输出规格。关键报文如下：

M3请求报文：

rtsp://localhost/wfd1.0：URL地址，代表 WFD 投屏会话资源地址；

Content-type: text/parameters，消息体格式，WFD 标准规定，代表正文是参数名称列表；

Content-length: 标识后面消息体数据总字节长度。

表2 消息体内全部 wfd 参数释义

参数名称	含义
wfd_content_protection	HDCP 版权加密支持能力
wfd_video_formats	支持的视频规格：分辨率、帧率、码率、H.264 Profile/Level
wfd_audio_codecs	支持的音频编码（AAC 等）
wfd_client_rtp_ports	Sink 用于接收 RTP 音视频流的 UDP 端口
wfd_uibc_capability	是否支持 UIBC 反向触控通道
wfd_hme_version	WFD 硬件媒体引擎版本
wfd_hme_vendor_id	硬件厂商 ID
wfd_hme_product_id	设备产品 ID
wfd_hme_hevc_formats	是否支持 H.265 (HEVC) 编码
wfd_hme_vtp	WFD 虚拟传输协议能力标识
wfd_hme_video_60fps	是否支持 60fps 视频输出
wfd_hme_avsync_sink	接收端音视频同步能力

M3响应报文：

wfd_client_rtp_ports: RTP/AVP/UDP;unicast 1025 0 mode=play，传输方式为UDP 单播 RTP；1025是Sink 用于接收媒体流的 UDP 端口；后续 SETUP 信令会基于该端口建立音视频传输通道；

wfd_audio_codecs:LPCM 00000003 00, AAC 0000000f 00, AC3 00000007 00，表示Sink 支持的音频编码有LPCM、AAC、AC3，Miracast 常规投屏优先使用 AAC 编码；

wfd_video_formats: 二进制编码字符串，代表支持的 H.264 规格，分辨率、最大帧率、码率、Profile/Level；Source 拿到此字段后，和自身支持能力做交集，协商最终投屏视频参数；

wfd_content_protection: none，代表无 HDCP 加密，投屏画面不需要版权加密校验；如果是hdcp2.2则代表强制 HDCP2.2 加密，源端需要开启加密，否则无法投屏；

wfd_uibc_capability：支持 UIBC 反向控制，可接收键盘、鼠标、多点触控、手势、遥控器指令； port=none代表控制通道复用 RTSP TCP 信令通道（不独立开辟 UDP 端口）。

3、SET_PARAMETER（能力配置，触发控制）

        M4 SET_PARAMETER用于下发 Source 与 Sink 协商取交集后的投屏参数，固化分辨率、帧率、编码规格、HDCP 加密模式等配置，由 Sink 校验参数合法性。M5 SET_PARAMETER 携带 wfd_trigger_method 标识，通知 Sink 主动发起音视频 SETUP 请求以创建 RTP 媒体传输通道。关键报文如下：

M4请求报文：

M4响应报文：

M5请求报文：

wfd_trigger_method：WFD 私有扩展参数；通知对端即将发起 SETUP 请求指令。

M5响应报文：

4、SETUP（建立传输通道）

       Sink 主动向 Source 发送音视频 SETUP 请求，报文通过 Transport 字段协商两端 RTP/RTCP UDP 端口对，Source 应答中分配全局唯一 RTSP 会话 Session ID，音视频流共享同一会话标识。关键报文如下：

M6请求报文：

Transport：RTSP 核心传输协商头；

RTP/AVP/UDP：使用 UDP 承载 RTP 音视频数据包；AVP=Audio/Video Profile；

unicast：单播传输（Miracast 标准方式，一对一投屏）；

client_port=1028-1029：1028表示RTP 媒体数据包端口（H.264 视频流）；1029表示配套RTCP 控制报文端口（时钟同步、丢包反馈）；Client 表示Sink 接收端，Source 要求 Sink 在这一对端口接收视频流。

M6响应报文：

Session: 核心会话标识，Miracast 最重要字段之一；

509423075：全局唯一Session ID 会话句柄，后续所有 PLAY、GET_PARAMETER、TEARDOWN 信令都必须携带此 Session，区分不同投屏会话；

timeout=30：会话超时时间，单位秒，若 30 秒内没有收到任何有效 RTSP 信令保活，Sink 自动释放会话、断开媒体通道；

server_port=25368-25369：Source 发送端口 Source 从本机 25368 向外发送 H.264 RTP 视频包，25369 发送 RTCP 报文。

5、PLAY（正式投屏推流）

        Sink发送 PLAY 指令，Source 返回成功后，立刻启动进行屏幕采集、H.264 编码、封装RTP、UDP持续发送音视频流，投屏画面正式出现；运行阶段Source周期性发送GET_PARAMETER进行心跳保活。关键报文如下：

M7请求报文：

M7响应报文：

Range: npt=now- ：RTSP 标准时间范围字段；从当前时刻开始持续播放，无结束时间，适配 Miracast 实时投屏（直播流，不是点播文件）。

6、TEARDOWN（终止投屏）

       Source 通过SET_PARAMETER下发wfd_trigger_method: TEARDOWN 通知 Sink 结束投屏；Sink 确认后主动发送 TEARDOWN 请求正式拆链，Source 返回 200 OK，会话终止。随后两端释放 RTP 端口、销毁 RTSP 会话、回收解码器资源，TCP 连接通过四次挥手关闭。关键报文如下：

SET_PARAMETER请求报文：

wfd_trigger_method: TEARDOWN：Miracast 标准扩展字段，通知对端即将发起 TEARDOWN，准备结束投屏会话。

SET_PARAMETER响应报文：

M8请求报文：

M8响应报文：

Connection：代表连接状态，close表示本次 RTSP 事务完成之后，TCP 连接会被关闭。

三、完整时序图