Miracast投屏反控原理

Miracast投屏反控

一、 Miracast介绍

Miracast是对支持Wi-Fi Display功能设备的认证名称，也就是通过Miracast认证的设备应该都支持Wi-Fi Display功能。

二、 缩略词以及定义

• Source 端：支持通过WiFi链路将多媒体内容流式输入到接收端的设备，即发送端。
• Sink 端：从source端通过WiFi链路接收多媒体内容并进行渲染的设备，即接收端。
• WFD : Wi-Fi Display
• UIBC: User Input Back Channel 用户输入反向通道，将用户输入的操作传输到Sink端和- Source端。
• HIDC：Human Interface Device Class
• HID: Human Interface Device

三、 Miracast会话过程

1. Device discovery
   发现设备，通过WiFi P2P查找附近支持WiFi P2P的设备。前提是两个设备都支持P2P功能，现在大部分手机能连WiFi都支持P2P，在ScreenBox项目中，Source端即笔记本电脑，Sink端为ScreenBox盒子，将笔记本投屏到ScreenBox上，Sink端不断向外广播，Source端不断扫描，扫描就是发现设备的过程。
2. Service discovery
   服务发现。在两个设备连接之前发现彼此的服务功能。
3. Device selection
   设备A发现设备B，用户选择是否与设备B进行配对。
4. Connection setup
   Source端和Sink端建立P2P连接，此时建立连接之后，两个设备会协商出谁来当Group Owner（Group Owner中的DHCP服务进程分配IP），至于如何协商，比较两者的Intent参数，在ScreenBox项目中，手动把盒子的Intent值设为最高，盒子即成为Group Owner。此时盒子会为投屏设备分配一个IP，现在还缺一个端口，端口是默认的7236。TCP连接建立，该端口也用于下一步RTSP会话的管理和控制。
5. Capability negotiation
   能力协商阶段。在成功建立了WFD连接以及TCP连接后，开始WFD协商阶段，该阶段主要是Source端和Sink端两者交互它们支持的一些rtsp编码格式以及后续用到的参数等等。具体看下图M1、M2、M3、M4四个阶段。
   

图 基于RTSP的Capability Negotiation

• M1 消息：Source端发送一条RTSP Options请求给Sink端， Sink端响应给Source端，确定了Sink端支持的一些RTSP methods。
• M2 消息：与M1消息类似，Sink端发送一条RTSP Options请求给Source端，Source端响应给Sink端，确定了Source端支持的一些RTSP methods。
• M3 消息：双方交换信息完成后，Source端发送RTST GET_PARAMETER 请求给Sink端，指明了后续交互中需要的一系列参数，Sink端做出响应。
• M4 消息： Source端确定了需要的参数，并通过RTST SET_PARAMETER 请求发送给Sink端
  该过程中，Source端询问Sink端是否支持反控，若它回复支持反控，则Source端会发送自己的端口号50000过去，此时一个用于发送鼠标消息的TCP连接也将被建立，具体的鼠标消息如何发送请看第8条User Input Back Channel Setup。

6. Content protection setup
   内容保护设置。在音视频传输过程中，对于需要保护的内容，Source端应该建立HDCP，起到一个数据加密的作用。
7. Session establishment and streaming
   会话建立。在完成第四步rtsp的能力协商之后，建立WFD会话，并且将Source端的音视频发送到Sink端，在两者完成RTSP M7的请求和响应之后，会话才是真正的建立。Source端的视音频数据将由（H264,AAC）编码，复用成MPEG2TS流后通过RTP协议由UDP传给Sink端，Sink端将解码收到的数据，并最终显示出来。（打包成ts包，封装给RTP，由UDP发送给sink端）具体会话的建立过程见下图。
   

图 会话建立时间线

• M5 消息：Source端发送一条RTSP 触发器设置的请求，Sink端作出响应。
• M6 消息：成功交换M5消息之后，Sink端向Source端发送RTSP SETUP请求，Source端作出响应，此时如果状态代码为RTSP OK，那么说明会话建立成功了。
• M7 消息：Sink端向Source端发送RTSP PLAY请求，此时Sink端已经准备好接收RTP流
• M8 消息：消息中包含一个RTSP TEARDOWN请求，用于Source端终止RTSP程序，停止音/视频流，终止相应的RTP。
• M9 消息：Sink端向Source端发送RTSP PAUSE请求
• 还有其他一系列消息都是用于两者间音视频的传输，这里不在赘述,详细请看《Wi-Fi Display Specification_v1.1》。

8. User input back channel setup
   用户输入通道。UIBC用于将用户的操作传输到Sink端和Source端，通过TCP传输，这里用户输入类别有两种：generic和HIDC。
   1）Generic：硬件无关型，如鼠标点击、按键点击、touch点击、放大缩小等。
   2）HIDC人机接口设备控制：包括红外线、USB、蓝牙、WIFI、游戏杆、遥控器等，用于由HID生成的用户输入。
   这里笔记本支持的大多数都是HIDC类型，因此通过TCP传输过去的数据需要用到HID报告描述符。HID报告描述符描述其是什么设备，以及后续控制数据的解析格式。例如Sink端发送过去的a1,a2,a3,a4，但是Source端并不认识这些数据，HID描述符告知其a1,a2表示X坐标，a3,a4表示Y坐标。
9. Payload control
   负载控制。在数据流建立之后，需要有控制管道负载的能力，包含以下功能： 1）时间同步 如果有2个sink设备，二者音视频必须同步，实现保真。2）编码速率控制：因信道条件和电源管理优化控制管道负载。
10. Display session teardown
    会话终止。

记录学习过程，仅供参考，有错误希望多多指正，感谢ldl同学的大力支持