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会话过程
- Device discovery
发现设备,通过WiFi P2P查找附近支持WiFi P2P的设备。前提是两个设备都支持P2P功能,现在大部分手机能连WiFi都支持P2P,在ScreenBox项目中,Source端即笔记本电脑,Sink端为ScreenBox盒子,将笔记本投屏到ScreenBox上,Sink端不断向外广播,Source端不断扫描,扫描就是发现设备的过程。 - Service discovery
服务发现。在两个设备连接之前发现彼此的服务功能。 - Device selection
设备A发现设备B,用户选择是否与设备B进行配对。 - Connection setup
Source端和Sink端建立P2P连接,此时建立连接之后,两个设备会协商出谁来当Group Owner(Group Owner中的DHCP服务进程分配IP),至于如何协商,比较两者的Intent参数,在ScreenBox项目中,手动把盒子的Intent值设为最高,盒子即成为Group Owner。此时盒子会为投屏设备分配一个IP,现在还缺一个端口,端口是默认的7236。TCP连接建立,该端口也用于下一步RTSP会话的管理和控制。 - 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。
- Content protection setup
内容保护设置。在音视频传输过程中,对于需要保护的内容,Source端应该建立HDCP,起到一个数据加密的作用。 - 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》。
- 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坐标。 - Payload control
负载控制。在数据流建立之后,需要有控制管道负载的能力,包含以下功能: 1)时间同步 如果有2个sink设备,二者音视频必须同步,实现保真。2)编码速率控制:因信道条件和电源管理优化控制管道负载。 - Display session teardown
会话终止。