CN117083867A - 用于无线投屏的数据传输方法、装置、设备及存储介质 - Google Patents

用于无线投屏的数据传输方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN117083867A
CN117083867A CN202180096103.0A CN202180096103A CN117083867A CN 117083867 A CN117083867 A CN 117083867A CN 202180096103 A CN202180096103 A CN 202180096103A CN 117083867 A CN117083867 A CN 117083867A
Authority
CN
China
Prior art keywords
wfd
quic
receiving
receiving end
protocol
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202180096103.0A
Other languages
English (en)
Inventor
岳培锋
许天国
卢刘明
刘飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Oppo Mobile Telecommunications Corp Ltd
Original Assignee
Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangdong Oppo Mobile Telecommunications Corp Ltd filed Critical Guangdong Oppo Mobile Telecommunications Corp Ltd
Publication of CN117083867A publication Critical patent/CN117083867A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本申请公开了一种用于无线投屏的数据传输方法、装置、设备及存储介质，涉及移动通信领域。应用于无线投屏Miracast传输的无线保真显示WFD源端中，该方法包括：与WFD接收端建立QUIC连接；基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流，通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。该方法可以在保证无线投屏传输的安全性和可靠性的前提下，提高数据传输效率。

Description

用于无线投屏的数据传输方法、装置、设备及存储介质 技术领域
本申请涉及移动通信领域，特别涉及一种用于无线投屏的数据传输方法、装置、设备及存储介质。
背景技术
WFD(Wi-Fi Display，无线保真显示)是建立在Wi-Fi(无线保真)技术之上的一种无线投屏技术。WFD设备通过Wi-Fi Direct(Wi-Fi直连)发现对方WFD设备，然后建立连接，通过Wi-Fi传输音视频数据。其中，发送音视频数据的WFD设备称为源端(Source)，接收音视频数据的WFD设备称为接收端(Sink)。
相关技术中，在传输层采用TCP(Transmission Control Protocol，传输控制协议)和UDP(User Datagram Protocol，用户数据报协议)，在应用层采用RTSP(Real Time Streaming Protocol，实时流传输协议)和RTP(Real-time Transport Protocol，实时传输协议)，进行无线投屏的数据传输。
相关技术中的方法，采用TCP进行数据传输速率较慢，效率较低；采用UDP进行数据传输安全性和可靠性较低。
发明内容
本申请实施例提供了一种用于无线投屏的数据传输方法、装置、设备及存储介质，可以在保证无线投屏传输的安全性和可靠性的前提下，提高数据传输效率。所述技术方案如下：
根据本申请的一个方面，提供了一种用于无线投屏的数据传输方法，应用于无线投屏(Miracast)传输的无线保真显示(WFD)源端中，所述方法包括：
与WFD接收端建立QUIC连接；
基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；
响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流，通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
根据本申请的一个方面，提供了一种用于无线投屏的数据传输方法，应用于无线投屏(Miracast)传输的无线保真显示(WFD)源端中，所述方法包括：
通过TCP协议与WFD接收端进行RTSP协商，以创建RTSP会话；
与所述WFD接收端建立QUIC连接，基于所述QUIC连接创建第三QUIC流；
响应于通过所述RSTP会话接收到所述WFD接收端发送的播放请求，通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
根据本申请的一个方面，提供了一种用于无线投屏的数据传输方法，应用于无线投屏(Miracast)传输的无线保真显示(WFD)接收端中，所述方法包括：
与WFD源端建立QUIC连接；
通过第一QUIC流与所述WFD源端进行RTSP协商、以创建RTSP会话，所述第一QUIC流是所述WFD源端基于所述QUIC连接创建的；
通过所述RTSP会话向所述WFD源端发送播放请求；
通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的音频数据和视频数据中的至少一种，所述第二QUIC流是所述WFD源端基于所述QUIC连接创建的。
根据本申请的一个方面，提供了一种用于无线投屏的数据传输方法，应用于无线投屏(Miracast)传输的无线保真显示(WFD)接收端中，所述方法包括：
通过TCP协议与WFD源端进行RTSP协商，以创建RTSP会话；
与所述WFD源端建立QUIC连接；
通过所述RTSP会话向所述WFD源端发送播放请求；
通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，所述第三QUIC流是所述WFD源端基于所述QUIC连接创建的。
根据本申请的一个方面，提供了一种用于无线投屏的数据传输装置，用于实现无线投屏(Miracast)传输的无线保真显示(WFD)源端，所述装置包括：
第一QUIC模块，用于与WFD接收端建立QUIC连接；
第一QUIC模块，用于基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；
第一QUIC模块，用于响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流，通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
根据本申请的一个方面，提供了一种用于无线投屏的数据传输装置，用于实现无线投屏(Miracast)传输的无线保真显示(WFD)源端，所述装置包括：
第一TCP模块，用于通过TCP协议与WFD接收端进行RTSP协商，以创建RTSP会话；
第一QUIC模块，用于与所述WFD接收端建立QUIC连接，基于所述QUIC连接创建第三QUIC流；
第一QUIC模块，用于响应于通过所述RSTP会话接收到所述WFD接收端发送的播放请求，通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
根据本申请的一个方面，提供了一种用于无线投屏的数据传输装置，用于实现无线投屏(Miracast)传输的无线保真显示(WFD)接收端，所述装置包括：
第二QUIC模块，用于与WFD源端建立QUIC连接；
第二QUIC模块，用于通过第一QUIC流与所述WFD源端进行RTSP协商、以创建RTSP会话，所述第一QUIC流是所述WFD源端基于所述QUIC连接创建的；
第二QUIC模块，用于通过所述RTSP会话向所述WFD源端发送播放请求；
第二QUIC模块，用于通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的音频数据和视频数据中的至少一种，所述第二QUIC流是所述WFD源端基于所述QUIC连接创建的。
根据本申请的一个方面，提供了一种用于无线投屏的数据传输装置，用于实现无线投屏(Miracast)传输的无线保真显示(WFD)接收端，所述装置包括：
第二TCP模块，用于通过TCP协议与WFD源端进行RTSP协商，以创建RTSP会话；
第二QUIC模块，用于与所述WFD源端建立QUIC连接；
第二TCP模块，用于通过所述RTSP会话向所述WFD源端发送播放请求；
第二QUIC模块，用于通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，所述第三QUIC流是所述WFD源端基于所述QUIC连接创建的。
根据本申请的一个方面，提供了一种终端设备，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
所述收发器，用于与WFD接收端建立QUIC连接；
所述处理器，用于基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；
所述处理器器，用于响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流；
所述收发器，用于通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
根据本申请的一个方面，提供了一种终端设备，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
所述收发器，用于通过TCP协议与WFD接收端进行RTSP协商，以创建RTSP会话；
所述收发器，用于与所述WFD接收端建立QUIC连接；
所述处理器，用于基于所述QUIC连接创建第三QUIC流；
所述收发器，用于响应于通过所述RSTP会话接收到所述WFD接收端发送的播放请求，通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
根据本申请的一个方面，提供了一种终端设备，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
所述收发器，用于与WFD源端建立QUIC连接；
所述收发器，用于通过第一QUIC流与所述WFD源端进行RTSP协商、以创建RTSP会话，所述第一QUIC流是所述WFD源端基于所述QUIC连接创建的；
所述收发器，用于通过所述RTSP会话向所述WFD源端发送播放请求；
所述收发器，用于通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的音频数据和视频数据中的至少一种，所述第二QUIC流是所述WFD源端基于所述QUIC连接创建的。
根据本申请的一个方面，提供了一种终端设备，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
所述收发器，用于通过TCP协议与WFD源端进行RTSP协商，以创建RTSP会话；
所述收发器，用于与所述WFD源端建立QUIC连接；
所述收发器，用于通过所述RTSP会话向所述WFD源端发送播放请求；
所述收发器，用于通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，所述第三QUIC流是所述WFD源端基于所述QUIC连接创建的。
根据本申请的一个方面，提供了一种计算机可读存储介质，所述可读存储介质中存储有可执行指令，所述可执行指令由处理器加载并执行以实现如上述方面所述的用于无线投屏的数据传输方法。
根据本申请实施例的一个方面，提供了一种芯片，所述芯片包括可编程逻辑电路和/或程序指令，当所述芯片在计算机设备上运行时，用于实现上述方面所述的用于无线投屏的数据传输方法。
根据本申请的一个方面，提供了一种计算机程序产品，该计算机程序产品在计算机设备的处理器上运行时，使得计算机设备执行上述方面所述的用于无线投屏的数据传输方法。
本申请实施例提供的技术方案至少包括如下有益效果：
通过在传输层增加QUIC协议，通过QUIC协议进行无线投屏传输的音视频数据传输，同时保证源端和接收端连接和传输的稳定性，减少掉线和卡顿，减少传输时间，提高传输效率。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请一个示例性实施例提供的系统架构的示意图；
图2是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图3是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图4是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图5是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的Miracast架构的示意图；
图6是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图7是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的示意图；
图8是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的示意图；
图9是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图10是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图11是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图12是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图13是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图14是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图15是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图16是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图17是本申请一个示例性实施例提供的用于无线投屏的数据传输方法的流程图；
图18是本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图；
图19是本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图；
图20是本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图；
图21是本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图；
图22是本申请一个示例性实施例提供的通信设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组 合。
应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
首先，对本申请实施例中涉及的名词进行简单介绍：
WDF(Wi-Fi Display，无线保真显示)：是由Wi-Fi联盟(Wi-Fi Alliance)于2012年制定的一套标准协议，主要是以Wi-Fi Direct(无线直连)为基础的无线显示标准，支持该标准的电子产品可以通过无线方式分享图片和音视频等画面。手机/移动PC(Personal Computer，个人计算机)/电视/显示器将可以实现无线连接。WFD是建立在Wi-Fi技术之上的一种无线投屏技术。首先通过Wi-Fi Direct发现对方设备，然后建立连接，通过Wi-Fi传输音视频数据。
Miracast(无线投屏)：是Wi-Fi联盟对支持Wi-Fi Display功能的设备的认证名称。通过Miracast认证的设备将在最大程度内保持对Wi-Fi Display功能的支持和兼容。
TCP：是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF(The Internet Engineering Task Force，国际互联网工程任务组)的RFC(Request For Comments，征求意见稿)793定义。
UDP：是OSI(Open System Interconnection，开放式系统互联)参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务，IETF RFC 768是UDP的正式规范。UDP协议与TCP协议一样用于处理数据包，在OSI模型中，两者都位于传输层，处于IP(Internet Protocol，网际互连协议)协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。UDP用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用UDP协议。
QUIC(Quick UDP Internet Connection，快速UDP互联网连接)：是谷歌制定的一种基于UDP的低时延的互联网传输层协议。我们知道，TCP/IP协议族是互联网的基础。其中传输层协议包括TCP和UDP协议。与TCP协议相比，UDP更为轻量，但是错误校验也要少得多。这意味着UDP往往效率更高(不经常跟服务器端通信查看数据包是否送达或者按序)，但是可靠性不如TCP。通常游戏、流媒体以及VoIP等应用均采用UDP，而网页、邮件、远程登录等大部分的应用均采用TCP。QUIC很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，安全性，和低延迟。QUIC融合了包括TCP，TLS(Transport Layer Security，安全传输层协议)，HTTP/2(Hypertext Transfer Protocol/2，超文本传输协议第2版)等协议的特性，但基于UDP传输。QUIC的一个主要目标是减少连接延迟，当客户端第一次连接服务器时，QUIC只需要1RTT(Round-Trip Time，往返时间)的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。QUIC同时复用了HTTP/2协议的多路复用功能(Multiplexing)，但由于QUIC基于UDP所以避免了HTTP/2的线头阻塞(Head-of-Line Blocking)问题。因为QUIC基于UDP，运行在用户域而不是系统内核，使得QUIC协议可以快速的更新和部署，从而很好地解决了TCP协议部署及更新的困难。
RTSP(Real Time Streaming Protocol，实时流传输协议)：RFC 2326，是TCP/IP协议体系中的一个应用层协议，由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP(Real-time Transport Protocol，实时传输协议)和RTCP(RTP Control Protocol，RTP控制协议)之上，它使用TCP或UDP完成数据传输。HTTP与RTSP相比，HTTP请求由客户端发出，服务器作出响应；使用RTSP时，客户端和服务器都可以发出请求，即RTSP可以是双向的。RTSP是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制(Multicast)，除了可以降低服务器的网络用量，更进而支持多方视讯会议(Video Conference)。因为与HTTP1.1的运作方式相似，所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
RTP：是一个网络传输协议，是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。国际电信联盟ITU-T也发布了自己的RTP文档，作为H.225.0，但是后来当IETF发布了关于它的稳定的标准RFC后就被取消了。它作为因特网标准在RFC 3550(该文档的旧版本是RFC 1889)有详细说明。RFC 3551(STD 65，旧版本是RFC 1890)详细描述了使用最小控制的音频和视频会议。RTP协议详细说明了在互 联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTSP协议)，视频会议和一键通(Push to Talk)系统(配合H.323或SIP(Session Initiation Protocol，会话初始协议))，使它成为IP电话产业的技术基础。RTP协议和RTP控制协议(RTCP)一起使用，而且它是创建在UDP协议上的。
P2P(Peer to Peer，对等网络)：即对等计算机网络，是一种在对等者(Peer)之间分配任务和工作负载的分布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式。“Peer”在英语里有“对等者、伙伴、对端”的意义。因此，从字面上，P2P可以理解为对等计算或对等网络。国内一些媒体将P2P翻译成“点对点”或者“端对端”，学术界则统一称为对等网络(Peer-to-peer networking)或对等计算(Peer-to-peer computing)，其可以定义为：网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等)，这些共享资源通过网络提供服务和内容，能被其它对等节点(Peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源、服务和内容的提供者(Server，或称“服务端”)，又是资源、服务和内容的获取者(Client，或称“客户端”)。
AP(WirelessAccessPoint，无线接入点)：是无线局域网的一种典型应用。无线AP是无线网和有线网之间沟通的桥梁，是组建无线局域网(WLAN)的核心设备。它主要是提供无线工作站和有线局域网之间的互相访问，这样，在AP信号覆盖范围内的无线工作站可以通过它进行相互通信，没有AP基本上就无法组建真正意义上可访问Internet(因特网)的WLAN。AP在WLAN中就相当于发射基站在移动通信网络中的角色。在无线网络中，AP就相当于有线网络的集线器，它能够把各个无线客户端连接起来，无线客户端所使用的网卡是无线网卡，传输介质是空气(电磁波)。在逻辑上，它是一个无线单元的中心点，该单元内的所有无线信号都要通过它才能进行交换。AP是无线局域网基本模式中必不可少的设备，虽然只使用无线网卡而不使用AP也能组成一个点对点模式的无线局域网，但这样的无线局域网多少有些特殊，它只适用于临时性的无线连接。使用AP后不仅可以得到永久性的无线连接服务，而且能集中管理用户并大大提高无线网的安全性。通俗地讲，无线AP是无线网和有线网之间沟通的桥梁。由于无线AP的覆盖范围是一个向外扩散的圆形区域，因此，应当尽量把无线AP放置在无线网络的中心位置，而且各无线客户端与无线AP的直线距离最好不要超过30米，以避免因通信信号衰减过多而导致通信失败。
图1示出了本申请一个示例性实施例提供的无线投屏系统的框图。该无线投屏系统可以包括源端101和接收端102。
在投屏过程中，源端101将音视频数据传输给接收端102，由接收端102进行显示或播放。示例性的，本申请实施例中所提及的音视频数据包括：音频数据和视频数据中的至少一个。
源端101也可以称为WFD源端、源设备、Source端或QUIC客户端(Client)。源端101为计算机设备，例如，源端101可以为手机、电脑、平板电脑、笔记本电脑、电视、智能机器人中的至少一种。
接收端102也可以称为WFD接收端、接收设备、Sink端或QUIC服务端(Sever)。接收端102为计算机设备，例如，接收端102可以为手机、电脑、平板电脑、笔记本电脑、电视、投影仪、智能机器人中的至少一种。
源端101和接收端102通过P2P或AP的方式建立数据链路的连接。
请参考图2，其示出了本申请一个实施例提供的用于无线投屏的数据传输方法的流程图，该方法可以应用于图1所示的系统架构中。该方法包括如下步骤。
步骤201，源端与接收端建立QUIC连接。
在步骤201之前，源端与接收端通过P2P的方式建立数据链路的连接；或，源端与接收端通过AP的方式建立数据链路的连接。
示例性的，如图3所示，提供了一种源端与接收端建立数据链路的连接的方法流程图，该方法包括步骤2001至步骤2005：
步骤2001，源端接收用户指令(User command)。
步骤2002，源端与接收端进行无线投屏设备发现(Miracast Device Discover)。
步骤2003，源端与接收端进行无线投屏服务发现(可选)(Miracast Service Discovery(oprional))。
步骤2004，源端与接收端进行无线投屏连接设置(Miracast Connection Setup)。
步骤2005，源端与接收端进行无线直连或选项设置(Wi-Fi Direct or option Setup)。
示例性，如图4所示，步骤201包括步骤2011至步骤2016：
由源端发起QUIC连接，与接收端协商秘钥建立QUIC连接。对于源端与接收端第一次建立连接，需要1RTT获取相关信息来完成握手。
步骤2011，源端向接收端发送一个inchoate(“空的”或“初期的”)Hello包(或称“Client Hello包(客 户端Hello包)”，简称“CHLO”)，请求建立QUIC连接。
步骤2012，接收端接收CHLO后向源端发送REJ包，REJ包中包含了源端所需的信息，例如，token(令牌)和sever(服务)的证书。
步骤2013，源端向接收端发送完整CHLO包，完整CHLO包中包括源端的token和证书。
步骤2014，源端向接收端发送加密请求。
步骤2015，接收端向源端发送SHLO包(或称“Service Hello包(服务端Hello包)”，简称“SHLO”)，SHLO包中包括接收端的token和证书。
步骤2016，接收端向源端发送加密响应。
步骤202，源端基于QUIC连接创建第一QUIC流，源端和接收端通过第一QUIC流进行RTSP协商、以创建RTSP会话。
在建立QUIC连接后，源端与接收端通过QUIC协议进行RTSP协商和RTSP会话的创建。
源端创建第一QUIC流，通过第一QUIC流与接收端进行RTSP协商、以创建RTSP会话；接收端通过第一QUIC流与源端进行RTSP协商、以创建RTSP会话，第一QUIC流是源端创建的。
其中，RTSP协商的RTSP消息字段包括QUIC协议字段。
如图5所示，本申请实施例在标准的Miracast架构中，在传输层增加了QUIC协议103的模块。其中，RTP协商消息字段为由原Miracast标准中的(“RTP/AVP/UDP；unicast；”/“RTP/AVP/TCP；unicast；”)增加为(“RTP/AVP/UDP；unicast；”/“RTP/AVP/TCP；unicast；”/“RTP/AVP/QUIC；unicast；”)。
示例性的，源端创建第一QUIC流(QUIC stream1)，通过第一QUIC流完成如图6所示的进行RTSP协商、以创建RTSP会话的过程。在创建第一QUIC流之后，步骤202包括步骤2021至步骤2026。
步骤2021，源端和接收端传输RTSP M1Messages(RSTP M1信息)。
由源端发起一个RTSP OPTIONS M1指令，以确认接收端所支持的RTSP方法请求。M1指令的Request(请求)和Response(响应)如下所示：
Request(Source->Sink)
OPTIONS*RTSP/1.0\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:1\r\n
Require:org.wfa.wfd1.0\r\n
\r\n。
Response(Sink->Source)
RTSP/1.0 200OK\r\n
CSeq:1\r\n
Public:org.wfa.wfd1.0,GET_PARAMETER,SET_PARAMETER\r\n
\r\n。
步骤2022，源端和接收端传输RTSP M2Messages。
在接收端回复M1指令后，由接收端发起一个RTSP OPTIONS M2指令，以确认源端所支持的RTSP方法请求。M2指令的Request和Response如下所示：
Request(Sink->Source)
OPTIONS*RTSP/1.0\r\n
CSeq:0\r\n
User-Agent:wfdsinkemu\r\n
Require:org.wfa.wfd1.0\r\n
\r\n。
Response(Source->Sink)
RTSP/1.0 200OK\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:0\r\n
Public:org.wfa.wfd1.0,SETUP,TEARDOWN,PLAY,PAUSE,GET_PARAMETER,SET_PARAMETER\r\n
\r\n。
步骤2023，源端和接收端传输RTSP M3Messages。
在源端回复M2指令后，会由源端发起GET_PARAMETER M3(获得参数M3)指令，以查询接收端端的属性以及能力，所查询的属性列表在请求最后。M3指令的Request和Response如下所示：
Request(Source->Sink)
GET_PARAMETER rtsp://localhost/wfd1.0RTSP/1.0\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:2\r\n
Content-type:text/parameters
Content-length:83
\r\n。
Line-based text data:text/parameters(4lines)
wfd_content_protection\r\n
wfd_video_formats\r\n
wfd_audio_codecs\r\n
wfd_client_rtp_ports\r\n。
接收端回复M3指令，通知源端自身支持的属性及能力，比较重要的几个属性包括：用于传输流媒体的RTP端口号wfd_client_rtp_ports；所支持的audio(音频)及video(视频)编解码格式wfd_audio_codecs、wfd_video_formats等。
Response(Sink->Source)
RTSP/1.0 200OK\r\n
CSeq:2\r\n
Content-type:text/parameters
Content-length:848
\r\n。
Line-based text data:text/parameters(7lines)
wfd_client_rtp_ports:RTP/AVP/QUIC；unicast 20011 0mode＝play\r\n
wfd_audio_codecs:LPCM 00000002 00,AAC 00000001 00\r\n
wfd_video_formats:78 00 01 01 00008400 00000000 00000000 00 0000 0000 00none none\r\n
wfd_connector_type:07\r\n
wfd_uibc_capability:none\r\n
wfd_content_protection:none\r\n
wfd_idr_request_capability:1\r\n。
其中，“wfd_client_rtp_ports:RTP/AVP/QUIC；unicast 20011 0mode＝play\r\n”即为包括QUIC协议字段的RTSP消息字段，“wfd_client_rtp_ports:RTP/AVP/QUIC”可以理解为在wfd_client_rtp_ports设置RTP会话的传输层协议为QUIC协议。
步骤2024，源端和接收端传输RTSP M4Messages。
基于接收端回复的M3指令，将由源端发起SET_PARAMETER M4(设置参数M4)指令，以最终设置此次RTSP会话里的最佳参数集(收发双方都支持的编解码器类型等等)。M4指令的Request和Response如下所示：
Request(Source->Sink)
SET_PARAMETER rtsp://localhost/wfd1.0RTSP/1.0\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:3\r\n
Content-type:text/parameters
Content-length:247
\r\n。
Line-based text data:text/parameters(4lines)
wfd_video_formats:00 00 01 01 00000400 00000000 00000000 00 0000 0000 00none none\r\n
wfd_audio_codecs:AAC 00000001 00\r\n
wfd_presentation_URL:rtsp://192.168.49.5/wfd1.0/streamid＝0none\r\n
wfd_client_rtp_ports:RTP/AVP/QUIC；unicast 20011 0mode＝play\r\n。
Response(Sink->Source)
RTSP/1.0 200OK\r\n
CSeq:3\r\n
\r\n。
其中，“wfd_client_rtp_ports:RTP/AVP/QUIC；unicast 20011 0mode＝play\r\n”即为包括QUIC协议字段的RTSP消息字段，“wfd_client_rtp_ports:RTP/AVP/QUIC”可以理解为在wfd_client_rtp_ports设置RTP会话 的传输层协议为QUIC协议。
步骤2025，源端和接收端传输RTSP M5Messages。
由源端发起SET_PARAMETER M5(设置参数M5)请求，通过wfd_trigger_method参数触发接收端向源端发送SETUP(建立)、PLAY(播放)、PAUSE(暂停)、TEARDOWN(断开)等请求。如下M5Request中设置了SETUP触发请求。
Request(Source->Sink)
SET_PARAMETER rtsp://localhost/wfd1.0RTSP/1.0\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:4\r\n
Content-type:text/parameters
Content-length:27
\r\n。
Line-based text data:text/parameters(1lines)
wfd_trigger_method:SETUP\r\n
接收端则正常回复，表示自己已经收到SETUP触发请求即可。
Response(Sink->Source)
RTSP/1.0 200OK\r\n
CSeq:4\r\n
\r\n。
步骤2026，源端和接收端传输RTSP M6Messages。
前文提及了在M5Request中设置了SETUP触发请求，则此时应由接收端主动发送SETUP M6请求：
Request(Sink->Source)
SETUP rtsp://192.168.49.5/wfd1.0/streamid＝0RTSP/1.0\r\n
CSeq:1\r\n
Transport:RTP/AVP/QUIC；unicast；client_port＝20011
\r\n。
其中，“Transport:RTP/AVP/QUIC；unicast；client_port＝20011”即为包括QUIC协议字段的RTSP消息字段，“Transport:RTP/AVP/QUIC”可以理解为在Transport设置RTP会话的传输层协议为QUIC协议。
此时源端将完成RTSP会话的创建，并返回Session ID(会话标识)：
Response(Source->Sink)
RTSP/1.0 200OK\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:1\r\n
Session:1804289383；timeout＝30
Transport:RTP/AVP/QUIC；unicast；client_port＝20011；server_port＝26466
\r\n。
其中，“Transport:RTP/AVP/QUIC；unicast；client_port＝20011；server_port＝26466”即为包括QUIC协议字段的RTSP消息字段。
经过上述的M1至M6的指令交互后，完成RTSP协商，以及RTSP会话的创建。
步骤203，接收端通过RTSP会话向源端发送播放请求。
示例性的，如图6所示，步骤203包括步骤2031。在步骤202之后，执行步骤2031，接收端通过RTSP会话向源端发送播放请求。
步骤2031，源端和接收端传输RTSP M7Messages。
经过M6指令交互后，RTSP会话已经完成创建。此时将由接收端发送PLAY M7(播放M7)请求，通知源端开始发送流媒体数据。M7指令的Request和Response如下所示：
Request(Sink->Source)
PLAY rtsp://192.168.49.5/wfd1.0/streamid＝0RTSP/1.0\r\n
CSeq:2\r\n
Session:1804289383；timeout＝30
\r\n。
Response(Source->Sink)
RTSP/1.0 200OK\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:2\r\n
Session:1804289383；timeout＝30
Range:npt＝now-\r\n
\r\n。
步骤204，源端响应于通过RTSP会话接收到接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流；源端和接收端通过第二QUIC流传输无线投屏传输的音频数据和视频数据中的至少一种。
源端和接收端传输AV TS(音视频数据流)。
经过图6所示的M1至M7的指令交互，且成功创建RTSP会话后，源端与接收端的RTSP协商及RTSP会话的创建过程已完成。此时，源端创建quic stream 2(第二QUIC流)向接收端发送RTP数据包，RTP数据包包含音视频数据。
示例性的，源端将无线投屏传输的音频数据和视频数据中的至少一种打包为QUIC包；通过第二QUIC流向接收端发送QUIC包，QUIC包包括音频数据和视频数据中的至少一种。
如图7所示，源端将Video content(视频内容)501、Game content(游戏内容)502、UI Content(界面内容)503经过Compoistion(渲染)模块504到display surface(显示平面)505；然后分为2路：一路经过display controller(显示屏控制)模块506在LCD(主屏)507上进行显示；另外一路为Miracast数据通路，Display capture(抓取屏幕)模块508获取屏幕上的显示信息然后经过Encode(编码)模块509后输出视频编码后的bit(比特)流510到MPEG(Moving Picture Experts Group，动态图像专家组)-2TS(Transport Stream，传输流)mux(复用)模块513，PCM(Pulse Code Modulation，脉冲编码调制)audio(音频)511将MPEG-2打包512输入到MPEG-2TS mux模块513。音视频数据流在打包成TS流后进入RTP transport(RTP传输)模块514打包为RTP包，RTP包经过QUIC transport(QUIC传输)模块515打包为QUIC包，然后将QUIC包经过Wi-Fi发送给接收端。
示例性的，如图8所示，源端101和接收端102都集成QUIC协议103模块，其中QUIC协议103模块打包接收RTSP 402和RTP 403数据为quic包；RTSP 402和RTP 403数据通过UDP协议进行封装。
示例性的，源端切换与接收端的数据链路的连接方式；响应于切换成功，继续通过第二QUIC流向接收端发送无线投屏传输的音频数据和视频数据中的至少一种。
源端向接收端发起QUIC连接，包括初次连接和再次连接；接收端监听源端的连接请求并与其建立连接，并能够向源端发送数据；对已连接的源端会生成一个QUIC会话标识(ID)，源端在切换接入点时，能够在QUIC会话标识的保活超时时间内重新接入网络。
综上所述，本实施例提供的方法，通过在传输层增加QUIC协议，通过QUIC协议进行无线投屏传输的音视频数据传输，同时保证源端和接收端连接和传输的稳定性，减少掉线和卡顿，减少传输时间，提高传输效率。
在一种可选的实现方式中，图2所示的方法可以实现为图9所示的示例性实施例。
请参考图9，其示出了本申请一个实施例提供的用于无线投屏的数据传输方法的流程图，该方法可以应用于图1所示的系统架构中。
首先，用户发出无线投屏指令，源端和接收端响应于无线投屏指令，执行如图3所示的步骤2001至步骤2005，通过P2P或AP的方式，建立源端与接收端的数据链路的连接。
然后，源端和接收端执行如图4所示的步骤2011至步骤2016，建立源端与接收端之间的QUIC连接。
然后，源端和接收端通过第一QUIC流执行如图6所示的步骤2021至步骤2026，进行RSTP协商以创建RSTP会话。
然后，源端和接收端通过第一QUIC流执行如图6所示的步骤2031，触发音视频数据流的传输。
然后，执行步骤2041，源端通过第二QUIC流向接收端进行音视频数据流的传输。
在步骤2041之后，还可以执行步骤205，通过第一QUIC流，传输RSTP控制指令，进行无线投屏的控制。RSTP控制指令包括M5指令、M7指令、M8指令、M9指令、M10指令中的至少一种。
在miracast R2中部分支持动态的RTP传输在UDP和TCP之间进行切换，基于此，本申请实施例同样提供了在UDP、TCP、QUIC协议之间进行切换的方法。
1、切换为TCP(可以称为M8指令)。
如图10所示，示出了本申请一个实施例提供的用于无线投屏的数据传输方法的流程图，该方法可以应用于图1所示的系统架构中。步骤205包括步骤2051至步骤2054。
步骤2051，源端响应于接收到第一用户切换指令，向接收端发送第一RSTP参数设置指令。
第一用户切换指令用于将传输协议切换为TCP协议。
以从QUIC协议切换到TCP协议为例，如图11所示，在步骤2051之前包括步骤501，源端通过QUIC流传输无线投屏的音频数据和视频数据中的至少一种(音视频数据流)。
响应于接收到第一用户切换指令，执行步骤502至步骤503。
步骤502，源端向接收端发送RSTP M4指令的请求(第一RSTP参数设置指令)。
在使用QUIC协议进行无线投屏时，用户向源端发送第一用户切换指令，RTSP M4Messages由源端发起SET_PARAMETER M4指令，将传输协议切换到TCP。
Request(Source->Sink)
SET_PARAMETER rtsp://localhost/wfd2.0RTSP/1.0\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:3\r\n
Content-type:text/parameters
Content-length:247
\r\n
Line-based text data:text/parameters(1lines)
wfd2_transport_switch:RTP/AVP/TCP；unicast mode＝play,wfd2_buffer_length:3000\r\n
步骤503，接收端向源端发送RSTPM4指令的响应。
Response(Sink->Source)
RTSP/1.0 200OK\r\n
CSeq:3\r\n
\r\n。
步骤2052，接收端响应于接收到源端发送的第一RSTP参数设置指令，向源端发送第一创建请求。
第一创建请求用于请求将RSTP会话的传输协议修改为TCP协议。
示例性的，步骤2052包括步骤504。步骤504，接收端向源端发送RSTP M6指令的请求(第一创建请求)。
接收端主动发送SETUP M6请求：
Request(Sink->Source)
SETUP rtsp://192.168.49.5/wfd2.0/streamid＝0RTSP/1.0\r\n
CSeq:1\r\n
Transport:RTP/AVP/TCP；unicast；client_port＝19006-19007
\r\n。
步骤2053，源端响应于接收到接收端发送的第一创建请求，将传输协议切换为TCP协议。
示例性的，步骤2053包括步骤505。步骤505，源端向接收端发送RSTP M6指令的响应。
源端将完成TCP协议的切换，然后回应接收端的M6请求：
Response(Source->Sink)
SETUP rtsp://192.168.49.5/wfd2.0/streamid＝0RTSP/1.0\r\n
CSeq:1\r\n
Transport:RTP/AVP/TCP；client_port＝19006-19007；server_port＝203004-23005\r\n。
步骤2054，源端和接收端通过TCP协议传输无线投屏传输的音频数据和视频数据中的至少一种。
示例性的，步骤2054包括步骤506。步骤506，源端通过TCP流向接收端发送音视频数据流。此时，RTP传输完成TCP协议的切换。
2、切换为UDP(可以称为M9指令)。
如图12所示，示出了本申请一个实施例提供的用于无线投屏的数据传输方法的流程图，该方法可以应用于图1所示的系统架构中。步骤205包括步骤2055至步骤2058。
步骤2055，源端响应于接收到第二用户切换指令，向接收端发送第二RSTP参数设置指令。
第二用户切换指令用于将传输协议切换为UDP协议。
以从TCP协议切换到UDP协议为例，如图13所示，在步骤2055之前包括步骤601，源端通过TCP流传输无线投屏的音频数据和视频数据中的至少一种(音视频数据流)。
响应于接收到第二用户切换指令，执行步骤602至步骤603。
步骤602，源端向接收端发送RSTP M4指令的请求(第二RSTP参数设置指令)。
在使用TCP协议进行无线投屏时，用户向源端发送第二用户切换指令，RTSP M4Messages由源端发起SET_PARAMETER M4指令，将传输协议切换到UDP。
Request(Source->Sink)
SET_PARAMETER rtsp://localhost/wfd2.0RTSP/1.0\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:3\r\n
Content-type:text/parameters
Content-length:247
\r\n。
Line-based text data:text/parameters(1lines)
wfd2_transport_switch:RTP/AVP/UDP；unicast mode＝play,wfd2_buffer_length:150\r\n。
步骤603，接收端向源端发送RSTP M4指令的响应。
Response(Sink->Source)
RTSP/1.0 200OK\r\n
CSeq:3\r\n
\r\n。
步骤2056，接收端响应于接收到源端发送的第二RSTP参数设置指令，向源端发送第二创建请求。
第二创建请求用于请求将RSTP会话的传输协议修改为UDP协议。
示例性的，步骤2056包括步骤604。步骤604，接收端向源端发送RSTP M6指令的请求(第二创建请求)。
接收端主动发送SETUP M6请求：
Request(Sink->Source)
SETUP rtsp://192.168.49.5/wfd2.0/streamid＝0RTSP/1.0\r\n
CSeq:1\r\n
Transport:RTP/AVP/UDP；unicast；client_port＝1028-1029
\r\n。
步骤2057，源端响应于接收到接收端发送的第二创建请求，将传输协议切换为UDP协议。
示例性的，步骤2057包括步骤605。步骤605，源端向接收端发送RSTP M6指令的响应。
源端将完成UDP协议的切换，然后回应接收端的M6请求：
Response(Source->Sink)
SETUP rtsp://192.168.49.5/wfd2.0/streamid＝0RTSP/1.0\r\n
CSeq:1\r\n
Transport:RTP/AVP/UDP；unicast；client_port＝1028-1029；server_port＝5000-5001\r\n。
步骤2058，源端和接收端通过UDP协议传输无线投屏传输的音频数据和视频数据中的至少一种。
示例性的，步骤2058包括步骤606。步骤606，源端通过UDP流向接收端发送音视频数据流。此时，RTP传输完成UDP协议的切换。
3、切换为QUIC(可以称为M10指令)。
如图14所示，示出了本申请一个实施例提供的用于无线投屏的数据传输方法的流程图，该方法可以应用于图1所示的系统架构中。步骤205包括步骤2059至步骤2062。
步骤2059，源端响应于接收到第三用户切换指令，向接收端发送第三RSTP参数设置指令。
第三用户切换指令用于将传输协议切换为QUIC协议。
以从UDP协议切换到QUIC协议为例，如图15所示，在步骤2059之前包括步骤701，源端通过UDP流传输无线投屏的音频数据和视频数据中的至少一种(音视频数据流)。
响应于接收到第三用户切换指令，执行步骤702至步骤703。
步骤702，源端向接收端发送RSTP M4指令的请求(第三RSTP参数设置指令)。
在使用UDP协议进行无线投屏时，用户向源端发送第三用户切换指令，RTSP M4Messages由源端发起SET_PARAMETER M4指令，将传输协议切换到QUIC。
Request(Source->Sink)
SET_PARAMETER rtsp://localhost/wfd2.0RTSP/1.0\r\n
Date:星期*,*日*月*年*时:*分:*秒+0000\r\n
Server:stagefright/1.2(Linux；Android 8.1.0)\r\n
CSeq:3\r\n
Content-type:text/parameters
Content-length:247
\r\n。
Line-based text data:text/parameters(1lines)
wfd2_transport_switch:RTP/AVP/QUIC；unicast mode＝play,wfd2_buffer_length:150\r\n。
步骤703，接收端向源端发送RSTP M4指令的响应。
Response(Sink->Source)
RTSP/1.0 200OK\r\n
CSeq:3\r\n
\r\n。
步骤2060，接收端响应于接收到源端发送的第三RSTP参数设置指令，向源端发送第三创建请求。
第三创建请求用于请求将RSTP会话的传输协议修改为QUIC协议。
示例性的，步骤2060包括步骤704。步骤704，接收端向源端发送RSTP M6指令的请求(第三创建请求)。
接收端主动发送SETUP M6请求：
Request(Sink->Source)
SETUP rtsp://192.168.49.5/wfd2.0/streamid＝0RTSP/1.0\r\n
CSeq:1\r\n
Transport:RTP/AVP/QUIC；unicast；client_port＝1028-1029
\r\n。
步骤2061，源端响应于接收到接收端发送的第三创建请求，将传输协议切换为QUIC协议。
示例性的，步骤2061包括步骤705。步骤705，源端向接收端发送RSTP M6指令的响应。
源端将完成QUIC协议的切换，然后回应接收端的M6请求：
Response(Source->Sink)
SETUP rtsp://192.168.49.5/wfd2.0/streamid＝0RTSP/1.0\r\n
CSeq:1\r\n
Transport:RTP/AVP/QUIC；unicast；client_port＝1028-1029；server_port＝5000-5001\r\n。
步骤2062，源端和接收端通过QUIC协议传输无线投屏传输的音频数据和视频数据中的至少一种。
示例性的，步骤2062包括步骤706。步骤706，源端通过QUIC流向接收端发送音视频数据流。此时，RTP传输完成QUIC协议的切换。
示例性的，采用上述方法可以实现TCP、UDP、QUIC三者之间的任意切换。上述的图11、图13、图15所示出的实施例仅以从QUIC切换为TCP、从TCP切换为UDP、从UDP切换为QUIC进行举例说明，基于相同的方法还可以实现从UDP切换为TCP、从QUIC切换为UDP、从TCP切换为QUCI。
请参考图16，其示出了本申请一个实施例提供的用于无线投屏的数据传输方法的流程图，该方法可以应用于图1所示的系统架构中。该方法包括如下步骤。
步骤301，源端和接收端通过TCP协议进行RTSP协商、以创建RTSP会话。
在步骤301之前，源端与接收端通过P2P的方式建立数据链路的连接；或，源端与接收端通过AP的方式建立数据链路的连接。
示例性的，数据链路的连接方法可以参照上文中对图3所示示例性实施例的描述。
源端通过TCP协议与接收端进行RTSP协商、以创建RTSP会话；接收端通过TCP协议与源端进行RTSP协商、以创建RTSP会话。
其中，RTSP协商的RTSP消息字段包括QUIC协议字段。
如图5所示，本申请实施例在标准的Miracast架构中，在传输层增加了QUIC协议103的模块。其中，RTP协商消息字段为由原Miracast标准中的(“RTP/AVP/UDP；unicast；”/“RTP/AVP/TCP；unicast；”)增加为(“RTP/AVP/UDP；unicast；”/“RTP/AVP/TCP；unicast；”/“RTP/AVP/QUIC；unicast；”)。
示例性的，源端通过TCP协议完成如图6所示的进行RTSP协商、以创建RTSP会话的过程。步骤301包括：通过TCP协议执行步骤2021至步骤2026。步骤2021至步骤2026的解释可以参照上文。
经过上述的步骤2021至步骤2026的指令交互后，完成RTSP协商，以及RTSP会话的创建。
步骤302，源端与接收端建立QUIC连接。
示例性的，步骤302在步骤203之前执行，步骤302与步骤301的先后顺序可以是任意的，例如，可以先执行步骤302再执行步骤301。步骤302与步骤2021至步骤2026的先后顺序可以是任意的，例如，步骤302可以在步骤2021至步骤2026中任意一步之后执行。
示例性，如图4所示，步骤302包括步骤2011至步骤2016：步骤2011至步骤2016的解释可以参照上文。
步骤303，源端基于QUIC连接创建第三QUIC流。
示例性的，在建立QUIC连接后，源端创建用于传输RTP数据的第三QUIC流。
步骤304，接收端通过RTSP会话向源端发送播放请求。
示例性的，如图6所示，步骤304包括步骤2031。在步骤303之后，执行步骤2031，接收端通过RTSP会话向源端发送播放请求。
步骤2031，源端和接收端传输RTSP M7Messages。步骤2031的解释可以参照上文。
步骤305，源端响应于通过RTSP会话接收到接收端发送的播放请求，源端和接收端通过第三QUIC流传输无线投屏传输的音频数据和视频数据中的至少一种。
源端和接收端传输AV TS(音视频数据流)。
通过TCP协议执行图6所示的M1至M7的指令交互，且成功创建RTSP会话后，源端与接收端的RTSP协商及RTSP会话的创建过程已完成。源端与接收端进行QUIC连接，创建quic stream 3(第三QUIC流)，通过第三QUIC流向接收端发送RTP数据包，RTP数据包包含音视频数据。
示例性的，源端将无线投屏传输的音频数据和视频数据中的至少一种打包为QUIC包；通过第二QUIC流向接收端发送QUIC包，QUIC包包括音频数据和视频数据中的至少一种。
如图7所示，源端将Video content(视频内容)501、Game content(游戏内容)502、UI Content(界面内容)503经过Compoistion(渲染)模块504到display surface(显示平面)505；然后分为2路：一路经过display controller(显示屏控制)模块506在LCD(主屏)507上进行显示；另外一路为Miracast数据通路，Display capture(抓取屏幕)模块508获取屏幕上的显示信息然后经过Encode(编码)模块509后输出视频编码后的bit(比特)流510到MPEG(Moving Picture Experts Group，动态图像专家组)-2TS(Transport Stream，传输流)mux(复用)模块513，PCM(Pulse Code Modulation，脉冲编码调制)audio(音频)511将MPEG-2打包512输入到MPEG-2TS mux模块513。音视频数据流在打包成TS流后进入RTP transport(RTP传输)模块514打包为RTP包，RTP包经过QUIC transport(QUIC传输)模块515打包为QUIC包，然后将QUIC包经过Wi-Fi发送给接收端。
示例性的，如图8所示，源端101和接收端102都集成QUIC协议103模块，其中QUIC协议103模块打包接收RTSP 402和RTP 403数据为quic包；RTSP 402和RTP 403数据通过UDP协议进行封装。
示例性的，源端切换与接收端的数据链路的连接方式；响应于切换成功，继续通过第三QUIC流向接收端发送无线投屏传输的音频数据和视频数据中的至少一种。
源端向接收端发起QUIC连接，包括初次连接和再次连接；接收端监听源端的连接请求并与其建立连接，并能够向源端发送数据；对已连接的源端会生成一个QUIC会话标识(ID)，源端在切换接入点时，能够在QUIC会话标识的保活超时时间内重新接入网络。
综上所述，本实施例提供的方法，通过在传输层增加QUIC协议，通过QUIC协议进行无线投屏传输的音视频数据传输，同时保证源端和接收端连接和传输的稳定性，减少掉线和卡顿，减少传输时间，提高传输效率。
在一种可选的实现方式中，图16所示的方法可以实现为图17所示的示例性实施例。
请参考图17，其示出了本申请一个实施例提供的用于无线投屏的数据传输方法的流程图，该方法可以应用于图1所示的系统架构中。
首先，用户发出无线投屏指令，源端和接收端响应于无线投屏指令，执行如图3所示的步骤2001至步骤2005，通过P2P或AP的方式，建立源端与接收端的数据链路的连接。
然后，源端和接收端通过TCP协议如图6所示的步骤2021至步骤2026，进行RSTP协商以创建RSTP会话。
然后，源端和接收端执行如图4所示的步骤2011至步骤2016，建立源端与接收端之间的QUIC连接。
然后，源端和接收端通过TCP协议接收播放请求，执行如图6所示的步骤2031，触发音视频数据流的传输。
然后，执行步骤3041，源端通过第三QUIC流向接收端进行音视频数据流的传输。
在步骤3041之后，还可以执行步骤305，通过TCP协议，传输RSTP控制指令，进行无线投屏的控制。
在miracast R2中部分支持动态的RTP传输在UDP和TCP之间进行切换，基于此，本申请实施例同样提供了在UDP、TCP、QUIC协议之间进行切换的方法。
UDP、TCP、QUIC协议之间进行切换的方法，可以参照上文对图10至图15的说明，在此不再赘述。
综上所述，本申请实施例提供的方法，通过基于QUIC技术的Miracast投屏方式，同时确保连接和传输稳定，减少掉线和卡顿，此外还能够节省网络端口和连接数据量，提高数据安全性。
本实施例提供的方法，相比于UDP，可以很好的解决丢包情况的下马赛克现象；相比于TCP，在缓冲比、缓冲次数方面有明显的提升。
本实施例提供的方法，在接入节点切换方面，可以无缝进行端口的切换。
本实施例提供的方法，在安全方面，减少了使用的端口数量，减少了被攻击的可能，同时数据交换使用了QUIC的加密方式。
示例性的，本申请实施例提供的无线投屏的数据传输方法，同样适用于其他屏幕共享传输协议，例如，DLNA协议、Airplay协议以及私有投屏等协议，上述协议都可以使用本申请提供的无线投屏的数据传输方法在传输层进行QUIC协议的扩展。
图18示出了本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图，该装置用于实现无线投屏Miracast传输的无线保真显示WFD源端，所述装置包括：
第一QUIC模块803，用于与WFD接收端建立QUIC连接；
第一QUIC模块803，用于基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；
第一QUIC模块803，用于响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流，通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
在一种可选的实现方式中，所述装置还包括：
第一数据链路模块801，用于通过对等网络P2P方式与所述WFD接收端建立数据链路的连接；
或，
第一数据链路模块801，用于通过无线接入点AP方式与所述WFD接收端建立所述数据链路的连接。
在一种可选的实现方式中，所述装置还包括：
第一数据链路模块801，用于切换与所述WFD接收端的所述数据链路的连接方式；
第一QUIC模块803，用于响应于切换成功，继续通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一QUIC模块803，用于将所述无线投屏传输的所述音频数据和视频数据中的至少一种打包为QUIC包；
第一QUIC模块803，用于通过所述第二QUIC流向所述WFD接收端发送所述QUIC包，所述QUIC包包括所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一传输模块802，用于响应于接收到第一用户切换指令，向所述WFD接收端发送第一RSTP参数设置指令；
第一传输模块802，用于响应于接收到所述WFD接收端发送的第一创建请求，将传输协议切换为TCP协议，所述第一创建请求是所述WFD接收端响应所述第一RSTP参数设置指令之后发送的；
第一TCP模块804，用于通过所述TCP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一传输模块802，用于响应于接收到第二用户切换指令，向所述WFD接收端发送第二RSTP参数设置指令；
第一传输模块802，用于响应于接收到所述WFD接收端发送的第二创建请求，将传输协议切换为UDP协议，所述第二创建请求是所述WFD接收端响应所述第二RSTP参数设置指令之后发送的；
第一UDP模块805，用于通过所述UDP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一传输模块802，用于响应于接收到第三用户切换指令，向所述WFD接收端发送第三RSTP参数设置指令；
第一传输模块802，用于响应于接收到所述WFD接收端发送的第三创建请求，将传输协议切换为所述QUIC协议，所述第三创建请求是所述WFD接收端响应所述第三RSTP参数设置指令之后发送的；
第一QUIC模块803，用于通过所述QUIC协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
图19示出了本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图，该装置用于 实现无线投屏Miracast传输的无线保真显示WFD源端，所述装置包括：
第一TCP模块804，用于通过TCP协议与WFD接收端进行RTSP协商，以创建RTSP会话；
第一QUIC模块803，用于与所述WFD接收端建立QUIC连接，基于所述QUIC连接创建第三QUIC流；
第一QUIC模块803，用于响应于通过所述RSTP会话接收到所述WFD接收端发送的播放请求，通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
在一种可选的实现方式中，所述装置还包括：
第一数据链路模块801，用于通过对等网络P2P方式与所述WFD接收端建立数据链路的连接；
或，
第一数据链路模块801，用于通过无线接入点AP方式与所述WFD接收端建立所述数据链路的连接。
在一种可选的实现方式中，所述装置还包括：
第一数据链路模块801，用于切换与所述WFD接收端的所述数据链路的连接方式；
第一QUIC模块803，用于响应于切换成功，继续通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一QUIC模块803，用于将所述无线投屏传输的所述音频数据和视频数据中的至少一种打包为QUIC包；
第一QUIC模块803，用于通过所述第三QUIC流向所述WFD接收端发送所述QUIC包，所述QUIC包包括所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一传输模块802，用于响应于接收到第一用户切换指令，向所述WFD接收端发送第一RSTP参数设置指令；
第一传输模块802，用于响应于接收到所述WFD接收端发送的第一创建请求，将传输协议切换为TCP协议，所述第一创建请求是所述WFD接收端响应所述第一RSTP参数设置指令之后发送的；
第一TCP模块804，用于通过所述TCP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一传输模块802，用于响应于接收到第二用户切换指令，向所述WFD接收端发送第二RSTP参数设置指令；
第一传输模块802，用于响应于接收到所述WFD接收端发送的第二创建请求，将传输协议切换为UDP协议，所述第二创建请求是所述WFD接收端响应所述第二RSTP参数设置指令之后发送的；
第一UDP模块805，用于通过所述UDP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第一传输模块802，用于响应于接收到第三用户切换指令，向所述WFD接收端发送第三RSTP参数设置指令；
第一传输模块802，用于响应于接收到所述WFD接收端发送的第三创建请求，将传输协议切换为所述QUIC协议，所述第三创建请求是所述WFD接收端响应所述第三RSTP参数设置指令之后发送的；
第一QUIC模块803，用于通过所述QUIC协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
图20示出了本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图，该装置用于实现无线投屏Miracast传输的无线保真显示WFD接收端，所述装置包括：
第二QUIC模块903，用于与WFD源端建立QUIC连接；
第二QUIC模块903，用于通过第一QUIC流与所述WFD源端进行RTSP协商、以创建RTSP会话，所述第一QUIC流是所述WFD源端基于所述QUIC连接创建的；
第二QUIC模块903，用于通过所述RTSP会话向所述WFD源端发送播放请求；
第二QUIC模块903，用于通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的音频数据和视频数据中的至少一种，所述第二QUIC流是所述WFD源端基于所述QUIC连接创建的。
在一种可选的实现方式中，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
在一种可选的实现方式中，所述装置还包括：
第二数据链路模块901，用于通过对等网络P2P方式与所述WFD源端建立数据链路的连接；
或，
第二数据链路模块901，用于通过无线接入点AP方式与所述WFD源端建立所述数据链路的连接。
在一种可选的实现方式中，所述装置还包括：
第二数据链路模块901，用于切换与所述WFD源端的所述数据链路的连接方式；
第二QUIC模块903，用于响应于切换成功，继续通过所述第二QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，第二QUIC模块903，用于通过所述第二QUIC流接收所述WFD源端发送的QUIC包，所述QUIC包包括所述无线投屏传输的所述音频数据和视频数据中的至少一种；
第二QUIC模块903，用于将所述QUIC包拆包为所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第二传输模块902，用于响应于接收到所述WFD源端发送的第一RSTP参数设置指令，向所述WFD源端发送第一创建请求，所述第一RSTP参数设置指令是所述WFD源端响应于接收到第一用户切换指令发送的，所述第一创建请求用于请求所述WFD源端将传输协议切换为TCP协议；
第二TCP模块904，用于通过所述TCP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第二传输模块902，用于响应于接收到所述WFD源端发送的第二RSTP参数设置指令，向所述WFD源端发送第二创建请求，所述第二RSTP参数设置指令是所述WFD源端响应于接收到第二用户切换指令发送的，所述第二创建请求用于请求所述WFD源端将传输协议切换为UDP协议；
第二UDP模块905，用于通过所述UDP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第二传输模块902，用于响应于接收到所述WFD源端发送的第三RSTP参数设置指令，向所述WFD源端发送第三创建请求，所述第三RSTP参数设置指令是所述WFD源端响应于接收到第三用户切换指令发送的，所述第三创建请求用于请求所述WFD源端将传输协议切换为QUIC协议；
第二QUIC模块903，用于通过所述QUIC协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
图21示出了本申请一个示例性实施例提供的用于无线投屏的数据传输装置的结构框图，该装置用于实现无线投屏Miracast传输的无线保真显示WFD接收端，所述装置包括：
第二TCP模块904，用于通过TCP协议与WFD源端进行RTSP协商，以创建RTSP会话；
第二QUIC模块903，用于与所述WFD源端建立QUIC连接；
第二TCP模块904，用于通过所述RTSP会话向所述WFD源端发送播放请求；
第二QUIC模块903，用于通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，所述第三QUIC流是所述WFD源端基于所述QUIC连接创建的。
在一种可选的实现方式中，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
在一种可选的实现方式中，所述装置还包括：
第二数据链路模块901，用于通过对等网络P2P方式与所述WFD源端建立数据链路的连接；
或，
第二数据链路模块901，用于通过无线接入点AP方式与所述WFD源端建立所述数据链路的连接。
在一种可选的实现方式中，所述装置还包括：
第二数据链路模块901，用于切换与所述WFD源端的所述数据链路的连接方式；
第二QUIC模块903，用于响应于切换成功，继续通过所述第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，第二QUIC模块903，用于通过所述第三QUIC流接收所述WFD源端发送的QUIC包，所述QUIC包包括所述无线投屏传输的所述音频数据和视频数据中的至少一种；
第二QUIC模块903，用于将所述QUIC包拆包为所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第二传输模块902，用于响应于接收到所述WFD源端发送的第一RSTP参数设置指令，向所述WFD源端发送第一创建请求，所述第一RSTP参数设置指令是所述WFD源端响应于接收到第一用户切换指令发送的，所述第一创建请求用于请求所述WFD源端将传输协议切换为TCP协议；
第二TCP模块904，用于通过所述TCP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第二传输模块902，用于响应于接收到所述WFD源端发送的第二RSTP参数设置指令，向所述WFD源端发送第二创建请求，所述第二RSTP参数设置指令是所述WFD源端响应于接收到第二用户切换指令发送的，所述第二创建请求用于请求所述WFD源端将传输协议切换为UDP协议；
第二UDP模块905，用于通过所述UDP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
在一种可选的实现方式中，所述装置还包括：
第二传输模块902，用于响应于接收到所述WFD源端发送的第三RSTP参数设置指令，向所述WFD源端发送第三创建请求，所述第三RSTP参数设置指令是所述WFD源端响应于接收到第三用户切换指令发送的，所述第三创建请求用于请求所述WFD源端将传输协议切换为QUIC协议；
第二QUIC模块903，用于通过所述QUIC协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
图22示出了本申请一个示例性实施例提供的通信设备(终端设备或网络设备)的结构示意图，该通信设备包括：处理器1001、接收器1002、发射器1003、存储器1004和总线1005。
处理器1001包括一个或者一个以上处理核心，处理器101通过运行软件程序以及模块，从而执行各种功能应用以及信息处理。
接收器1002和发射器1003可以实现为一个通信组件，该通信组件可以是一块通信芯片。
存储器1004通过总线1005与处理器1001相连。
存储器1004可用于存储至少一个指令，处理器1001用于执行该至少一个指令，以实现上述方法实施例中的各个步骤。
此外，存储器1004可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，易失性或非易失性存储设备包括但不限于：磁盘或光盘，电可擦除可编程只读存储器(Electrically-Erasable Programmable Read Only Memory，EEPROM)，可擦除可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)，静态随时存取存储器(Static Random Access Memory，SRAM)，只读存储器(Read-Only Memory，ROM)，磁存储器，快闪存储器，可编程只读存储器(Programmable Read-Only Memory，PROM)。
其中，当通信设备实现为终端设备时，本申请实施例涉及的通信设备中的处理器和收发器，可以执行上述任一所示的方法中，由终端设备执行的步骤，此处不再赘述。
在一种可能的实现方式中，当通信设备实现为终端设备时，
所述处理器，用于在资源选择过程确定目标传输资源；使用基于部分监听的重新评估和/或抢占过程，对所述目标传输资源进行处理。
在示例性实施例中，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现上述各个方法实施例提供的由通信设备执行的用于无线投屏的数据传输方法。
在示例性实施例中，还提供了一种芯片，所述芯片包括可编程逻辑电路和/或程序指令，当所述芯片在计算机设备上运行时，用于实现上述方面所述的用于无线投屏的数据传输方法。
在示例性实施例中，还提供了一种计算机程序产品，该计算机程序产品在计算机设备的处理器上运行时，使得计算机设备执行上述方面所述的用于无线投屏的数据传输方法。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (70)

  1. 一种用于无线投屏的数据传输方法，其特征在于，应用于无线投屏Miracast传输的无线保真显示WFD源端中，所述方法包括：
    与WFD接收端建立QUIC连接；
    基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；
    响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流，通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
  2. 根据权利要求1所述的方法，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  3. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    通过对等网络P2P方式与所述WFD接收端建立数据链路的连接；
    或，
    通过无线接入点AP方式与所述WFD接收端建立所述数据链路的连接。
  4. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    切换与所述WFD接收端的所述数据链路的连接方式；
    响应于切换成功，继续通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  5. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    将所述无线投屏传输的所述音频数据和视频数据中的至少一种打包为QUIC包；
    所述通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种，包括：
    通过所述第二QUIC流向所述WFD接收端发送所述QUIC包，所述QUIC包包括所述音频数据和视频数据中的至少一种。
  6. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    响应于接收到第一用户切换指令，向所述WFD接收端发送第一RSTP参数设置指令；
    响应于接收到所述WFD接收端发送的第一创建请求，将传输协议切换为TCP协议，所述第一创建请求是所述WFD接收端响应所述第一RSTP参数设置指令之后发送的；
    通过所述TCP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  7. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    响应于接收到第二用户切换指令，向所述WFD接收端发送第二RSTP参数设置指令；
    响应于接收到所述WFD接收端发送的第二创建请求，将传输协议切换为UDP协议，所述第二创建请求是所述WFD接收端响应所述第二RSTP参数设置指令之后发送的；
    通过所述UDP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  8. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    响应于接收到第三用户切换指令，向所述WFD接收端发送第三RSTP参数设置指令；
    响应于接收到所述WFD接收端发送的第三创建请求，将传输协议切换为所述QUIC协议，所述第三创建请求是所述WFD接收端响应所述第三RSTP参数设置指令之后发送的；
    通过所述QUIC协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  9. 一种用于无线投屏的数据传输方法，其特征在于，应用于无线投屏Miracast传输的无线保真显示WFD源端中，所述方法包括：
    通过TCP协议与WFD接收端进行RTSP协商，以创建RTSP会话；
    与所述WFD接收端建立QUIC连接，基于所述QUIC连接创建第三QUIC流；
    响应于通过所述RSTP会话接收到所述WFD接收端发送的播放请求，通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
  10. 根据权利要求9所述的方法，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  11. 根据权利要求9或10所述的方法，其特征在于，所述方法还包括：
    通过对等网络P2P方式与所述WFD接收端建立数据链路的连接；
    或，
    通过无线接入点AP方式与所述WFD接收端建立所述数据链路的连接。
  12. 根据权利要求9或10所述的方法，其特征在于，所述方法还包括：
    切换与所述WFD接收端的所述数据链路的连接方式；
    响应于切换成功，继续通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  13. 根据权利要求9或10所述的方法，其特征在于，所述方法还包括：
    将所述无线投屏传输的所述音频数据和视频数据中的至少一种打包为QUIC包；
    所述通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种，包括：
    通过所述第三QUIC流向所述WFD接收端发送所述QUIC包，所述QUIC包包括所述音频数据和视频数据中的至少一种。
  14. 根据权利要求9或10所述的方法，其特征在于，所述方法还包括：
    响应于接收到第一用户切换指令，向所述WFD接收端发送第一RSTP参数设置指令；
    响应于接收到所述WFD接收端发送的第一创建请求，将传输协议切换为TCP协议，所述第一创建请求是所述WFD接收端响应所述第一RSTP参数设置指令之后发送的；
    通过所述TCP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  15. 根据权利要求9或10所述的方法，其特征在于，所述方法还包括：
    响应于接收到第二用户切换指令，向所述WFD接收端发送第二RSTP参数设置指令；
    响应于接收到所述WFD接收端发送的第二创建请求，将传输协议切换为UDP协议，所述第二创建请求是所述WFD接收端响应所述第二RSTP参数设置指令之后发送的；
    通过所述UDP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  16. 根据权利要求9或10所述的方法，其特征在于，所述方法还包括：
    响应于接收到第三用户切换指令，向所述WFD接收端发送第三RSTP参数设置指令；
    响应于接收到所述WFD接收端发送的第三创建请求，将传输协议切换为所述QUIC协议，所述第三创建请求是所述WFD接收端响应所述第三RSTP参数设置指令之后发送的；
    通过所述QUIC协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  17. 一种用于无线投屏的数据传输方法，其特征在于，应用于无线投屏Miracast传输的无线保真显示WFD接收端中，所述方法包括：
    与WFD源端建立QUIC连接；
    通过第一QUIC流与所述WFD源端进行RTSP协商、以创建RTSP会话，所述第一QUIC流是所述WFD源端基于所述QUIC连接创建的；
    通过所述RTSP会话向所述WFD源端发送播放请求；
    通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的音频数据和视频数据中的至少一种，所述第二QUIC流是所述WFD源端基于所述QUIC连接创建的。
  18. 根据权利要求17所述的方法，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  19. 根据权利要求17或18所述的方法，其特征在于，所述方法还包括：
    通过对等网络P2P方式与所述WFD源端建立数据链路的连接；
    或，
    通过无线接入点AP方式与所述WFD源端建立所述数据链路的连接。
  20. 根据权利要求17或18所述的方法，其特征在于，所述方法还包括：
    切换与所述WFD源端的所述数据链路的连接方式；
    响应于切换成功，继续通过所述第二QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  21. 根据权利要求17或18所述的方法，其特征在于，所述通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，包括：
    通过所述第二QUIC流接收所述WFD源端发送的QUIC包，所述QUIC包包括所述无线投屏传输的所述音频数据和视频数据中的至少一种；
    将所述QUIC包拆包为所述音频数据和视频数据中的至少一种。
  22. 根据权利要求17或18所述的方法，其特征在于，所述方法还包括：
    响应于接收到所述WFD源端发送的第一RSTP参数设置指令，向所述WFD源端发送第一创建请求，所述第一RSTP参数设置指令是所述WFD源端响应于接收到第一用户切换指令发送的，所述第一创建请求用于请求所述WFD源端将传输协议切换为TCP协议；
    通过所述TCP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  23. 根据权利要求17或18所述的方法，其特征在于，所述方法还包括：
    响应于接收到所述WFD源端发送的第二RSTP参数设置指令，向所述WFD源端发送第二创建请求，所述第二RSTP参数设置指令是所述WFD源端响应于接收到第二用户切换指令发送的，所述第二创建请求用于请求所述WFD源端将传输协议切换为UDP协议；
    通过所述UDP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  24. 根据权利要求17或18所述的方法，其特征在于，所述方法还包括：
    响应于接收到所述WFD源端发送的第三RSTP参数设置指令，向所述WFD源端发送第三创建请求，所述第三RSTP参数设置指令是所述WFD源端响应于接收到第三用户切换指令发送的，所述第三创建请求用于请求所述WFD源端将传输协议切换为QUIC协议；
    通过所述QUIC协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  25. 一种用于无线投屏的数据传输方法，其特征在于，应用于无线投屏Miracast传输的无线保真显示WFD接收端中，所述方法包括：
    通过TCP协议与WFD源端进行RTSP协商，以创建RTSP会话；
    与所述WFD源端建立QUIC连接；
    通过所述RTSP会话向所述WFD源端发送播放请求；
    通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，所述第三QUIC流是所述WFD源端基于所述QUIC连接创建的。
  26. 根据权利要求25所述的方法，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  27. 根据权利要求25或26所述的方法，其特征在于，所述方法还包括：
    通过对等网络P2P方式与所述WFD源端建立数据链路的连接；
    或，
    通过无线接入点AP方式与所述WFD源端建立所述数据链路的连接。
  28. 根据权利要求25或26所述的方法，其特征在于，所述方法还包括：
    切换与所述WFD源端的所述数据链路的连接方式；
    响应于切换成功，继续通过所述第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  29. 根据权利要求25或26所述的方法，其特征在于，所述通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，包括：
    通过所述第三QUIC流接收所述WFD源端发送的QUIC包，所述QUIC包包括所述无线投屏传输的所述音频数据和视频数据中的至少一种；
    将所述QUIC包拆包为所述音频数据和视频数据中的至少一种。
  30. 根据权利要求25或26所述的方法，其特征在于，所述方法还包括：
    响应于接收到所述WFD源端发送的第一RSTP参数设置指令，向所述WFD源端发送第一创建请求，所述第一RSTP参数设置指令是所述WFD源端响应于接收到第一用户切换指令发送的，所述第一创建请求用于请求所述WFD源端将传输协议切换为TCP协议；
    通过所述TCP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  31. 根据权利要求25或26所述的方法，其特征在于，所述方法还包括：
    响应于接收到所述WFD源端发送的第二RSTP参数设置指令，向所述WFD源端发送第二创建请求，所述第二RSTP参数设置指令是所述WFD源端响应于接收到第二用户切换指令发送的，所述第二创建请求用于请求所述WFD源端将传输协议切换为UDP协议；
    通过所述UDP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  32. 根据权利要求25或26所述的方法，其特征在于，所述方法还包括：
    响应于接收到所述WFD源端发送的第三RSTP参数设置指令，向所述WFD源端发送第三创建请求，所述第三RSTP参数设置指令是所述WFD源端响应于接收到第三用户切换指令发送的，所述第三创建请求用于请求所述WFD源端将传输协议切换为QUIC协议；
    通过所述QUIC协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  33. 一种用于无线投屏的数据传输装置，其特征在于，用于实现无线投屏Miracast传输的无线保真显示WFD源端，所述装置包括：
    第一QUIC模块，用于与WFD接收端建立QUIC连接；
    第一QUIC模块，用于基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；
    第一QUIC模块，用于响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流，通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
  34. 根据权利要求33所述的装置，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  35. 根据权利要求33或34所述的装置，其特征在于，所述装置还包括：
    第一数据链路模块，用于通过对等网络P2P方式与所述WFD接收端建立数据链路的连接；
    或，
    第一数据链路模块，用于通过无线接入点AP方式与所述WFD接收端建立所述数据链路的连接。
  36. 根据权利要求33或34所述的装置，其特征在于，所述装置还包括：
    第一数据链路模块，用于切换与所述WFD接收端的所述数据链路的连接方式；
    第一QUIC模块，用于响应于切换成功，继续通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  37. 根据权利要求33或34所述的装置，其特征在于，所述装置还包括：
    第一QUIC模块，用于将所述无线投屏传输的所述音频数据和视频数据中的至少一种打包为QUIC包；
    第一QUIC模块，用于通过所述第二QUIC流向所述WFD接收端发送所述QUIC包，所述QUIC包包括所述音频数据和视频数据中的至少一种。
  38. 根据权利要求33或34所述的装置，其特征在于，所述装置还包括：
    第一传输模块，用于响应于接收到第一用户切换指令，向所述WFD接收端发送第一RSTP参数设置指令；
    第一传输模块，用于响应于接收到所述WFD接收端发送的第一创建请求，将传输协议切换为TCP协议，所述第一创建请求是所述WFD接收端响应所述第一RSTP参数设置指令之后发送的；
    第一TCP模块，用于通过所述TCP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  39. 根据权利要求33或34所述的装置，其特征在于，所述装置还包括：
    第一传输模块，用于响应于接收到第二用户切换指令，向所述WFD接收端发送第二RSTP参数设置指令；
    第一传输模块，用于响应于接收到所述WFD接收端发送的第二创建请求，将传输协议切换为UDP协议，所述第二创建请求是所述WFD接收端响应所述第二RSTP参数设置指令之后发送的；
    第一UDP模块，用于通过所述UDP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  40. 根据权利要求33或34所述的装置，其特征在于，所述装置还包括：
    第一传输模块，用于响应于接收到第三用户切换指令，向所述WFD接收端发送第三RSTP参数设置指令；
    第一传输模块，用于响应于接收到所述WFD接收端发送的第三创建请求，将传输协议切换为所述QUIC协议，所述第三创建请求是所述WFD接收端响应所述第三RSTP参数设置指令之后发送的；
    第一QUIC模块，用于通过所述QUIC协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  41. 一种用于无线投屏的数据传输装置，其特征在于，用于实现无线投屏Miracast传输的无线保真显示WFD源端，所述装置包括：
    第一TCP模块，用于通过TCP协议与WFD接收端进行RTSP协商，以创建RTSP会话；
    第一QUIC模块，用于与所述WFD接收端建立QUIC连接，基于所述QUIC连接创建第三QUIC流；
    第一QUIC模块，用于响应于通过所述RSTP会话接收到所述WFD接收端发送的播放请求，通过所 述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
  42. 根据权利要求41所述的装置，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  43. 根据权利要求41或42所述的装置，其特征在于，所述装置还包括：
    第一数据链路模块，用于通过对等网络P2P方式与所述WFD接收端建立数据链路的连接；
    或，
    第一数据链路模块，用于通过无线接入点AP方式与所述WFD接收端建立所述数据链路的连接。
  44. 根据权利要求41或42所述的装置，其特征在于，所述装置还包括：
    第一数据链路模块，用于切换与所述WFD接收端的所述数据链路的连接方式；
    第一QUIC模块，用于响应于切换成功，继续通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  45. 根据权利要求41或42所述的装置，其特征在于，所述装置还包括：
    第一QUIC模块，用于将所述无线投屏传输的所述音频数据和视频数据中的至少一种打包为QUIC包；
    第一QUIC模块，用于通过所述第三QUIC流向所述WFD接收端发送所述QUIC包，所述QUIC包包括所述音频数据和视频数据中的至少一种。
  46. 根据权利要求41或42所述的装置，其特征在于，所述装置还包括：
    第一传输模块，用于响应于接收到第一用户切换指令，向所述WFD接收端发送第一RSTP参数设置指令；
    第一传输模块，用于响应于接收到所述WFD接收端发送的第一创建请求，将传输协议切换为TCP协议，所述第一创建请求是所述WFD接收端响应所述第一RSTP参数设置指令之后发送的；
    第一TCP模块，用于通过所述TCP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  47. 根据权利要求41或42所述的装置，其特征在于，所述装置还包括：
    第一传输模块，用于响应于接收到第二用户切换指令，向所述WFD接收端发送第二RSTP参数设置指令；
    第一传输模块，用于响应于接收到所述WFD接收端发送的第二创建请求，将传输协议切换为UDP协议，所述第二创建请求是所述WFD接收端响应所述第二RSTP参数设置指令之后发送的；
    第一UDP模块，用于通过所述UDP协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  48. 根据权利要求41或42所述的装置，其特征在于，所述装置还包括：
    第一传输模块，用于响应于接收到第三用户切换指令，向所述WFD接收端发送第三RSTP参数设置指令；
    第一传输模块，用于响应于接收到所述WFD接收端发送的第三创建请求，将传输协议切换为所述QUIC协议，所述第三创建请求是所述WFD接收端响应所述第三RSTP参数设置指令之后发送的；
    第一QUIC模块，用于通过所述QUIC协议向所述WFD接收端发送所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  49. 一种用于无线投屏的数据传输装置，其特征在于，用于实现无线投屏Miracast传输的无线保真显示WFD接收端，所述装置包括：
    第二QUIC模块，用于与WFD源端建立QUIC连接；
    第二QUIC模块，用于通过第一QUIC流与所述WFD源端进行RTSP协商、以创建RTSP会话，所述第一QUIC流是所述WFD源端基于所述QUIC连接创建的；
    第二QUIC模块，用于通过所述RTSP会话向所述WFD源端发送播放请求；
    第二QUIC模块，用于通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的音频数据和视频数据中的至少一种，所述第二QUIC流是所述WFD源端基于所述QUIC连接创建的。
  50. 根据权利要求49所述的装置，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  51. 根据权利要求49或50所述的装置，其特征在于，所述装置还包括：
    第二数据链路模块，用于通过对等网络P2P方式与所述WFD源端建立数据链路的连接；
    或，
    第二数据链路模块，用于通过无线接入点AP方式与所述WFD源端建立所述数据链路的连接。
  52. 根据权利要求49或50所述的装置，其特征在于，所述装置还包括：
    第二数据链路模块，用于切换与所述WFD源端的所述数据链路的连接方式；
    第二QUIC模块，用于响应于切换成功，继续通过所述第二QUIC流接收所述WFD源端发送的所述 无线投屏传输的所述音频数据和视频数据中的至少一种。
  53. 根据权利要求49或50所述的装置，其特征在于，第二QUIC模块，用于通过所述第二QUIC流接收所述WFD源端发送的QUIC包，所述QUIC包包括所述无线投屏传输的所述音频数据和视频数据中的至少一种；
    第二QUIC模块，用于将所述QUIC包拆包为所述音频数据和视频数据中的至少一种。
  54. 根据权利要求49或50所述的装置，其特征在于，所述装置还包括：
    第二传输模块，用于响应于接收到所述WFD源端发送的第一RSTP参数设置指令，向所述WFD源端发送第一创建请求，所述第一RSTP参数设置指令是所述WFD源端响应于接收到第一用户切换指令发送的，所述第一创建请求用于请求所述WFD源端将传输协议切换为TCP协议；
    第二TCP模块，用于通过所述TCP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  55. 根据权利要求49或50所述的装置，其特征在于，所述装置还包括：
    第二传输模块，用于响应于接收到所述WFD源端发送的第二RSTP参数设置指令，向所述WFD源端发送第二创建请求，所述第二RSTP参数设置指令是所述WFD源端响应于接收到第二用户切换指令发送的，所述第二创建请求用于请求所述WFD源端将传输协议切换为UDP协议；
    第二UDP模块，用于通过所述UDP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  56. 根据权利要求49或50所述的装置，其特征在于，所述装置还包括：
    第二传输模块，用于响应于接收到所述WFD源端发送的第三RSTP参数设置指令，向所述WFD源端发送第三创建请求，所述第三RSTP参数设置指令是所述WFD源端响应于接收到第三用户切换指令发送的，所述第三创建请求用于请求所述WFD源端将传输协议切换为QUIC协议；
    第二QUIC模块，用于通过所述QUIC协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  57. 一种用于无线投屏的数据传输装置，其特征在于，用于实现无线投屏Miracast传输的无线保真显示WFD接收端，所述装置包括：
    第二TCP模块，用于通过TCP协议与WFD源端进行RTSP协商，以创建RTSP会话；
    第二QUIC模块，用于与所述WFD源端建立QUIC连接；
    第二TCP模块，用于通过所述RTSP会话向所述WFD源端发送播放请求；
    第二QUIC模块，用于通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，所述第三QUIC流是所述WFD源端基于所述QUIC连接创建的。
  58. 根据权利要求57所述的装置，其特征在于，所述RTSP协商的RTSP消息字段包括QUIC协议字段。
  59. 根据权利要求57或58所述的装置，其特征在于，所述装置还包括：
    第二数据链路模块，用于通过对等网络P2P方式与所述WFD源端建立数据链路的连接；
    或，
    第二数据链路模块，用于通过无线接入点AP方式与所述WFD源端建立所述数据链路的连接。
  60. 根据权利要求57或58所述的装置，其特征在于，所述装置还包括：
    第二数据链路模块，用于切换与所述WFD源端的所述数据链路的连接方式；
    第二QUIC模块，用于响应于切换成功，继续通过所述第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  61. 根据权利要求57或58所述的装置，其特征在于，第二QUIC模块，用于通过所述第三QUIC流接收所述WFD源端发送的QUIC包，所述QUIC包包括所述无线投屏传输的所述音频数据和视频数据中的至少一种；
    第二QUIC模块，用于将所述QUIC包拆包为所述音频数据和视频数据中的至少一种。
  62. 根据权利要求57或58所述的装置，其特征在于，所述装置还包括：
    第二传输模块，用于响应于接收到所述WFD源端发送的第一RSTP参数设置指令，向所述WFD源端发送第一创建请求，所述第一RSTP参数设置指令是所述WFD源端响应于接收到第一用户切换指令发送的，所述第一创建请求用于请求所述WFD源端将传输协议切换为TCP协议；
    第二TCP模块，用于通过所述TCP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  63. 根据权利要求57或58所述的装置，其特征在于，所述装置还包括：
    第二传输模块，用于响应于接收到所述WFD源端发送的第二RSTP参数设置指令，向所述WFD源端发送第二创建请求，所述第二RSTP参数设置指令是所述WFD源端响应于接收到第二用户切换指令发送 的，所述第二创建请求用于请求所述WFD源端将传输协议切换为UDP协议；
    第二UDP模块，用于通过所述UDP协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  64. 根据权利要求57或58所述的装置，其特征在于，所述装置还包括：
    第二传输模块，用于响应于接收到所述WFD源端发送的第三RSTP参数设置指令，向所述WFD源端发送第三创建请求，所述第三RSTP参数设置指令是所述WFD源端响应于接收到第三用户切换指令发送的，所述第三创建请求用于请求所述WFD源端将传输协议切换为QUIC协议；
    第二QUIC模块，用于通过所述QUIC协议接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种。
  65. 一种终端设备，其特征在于，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
    所述收发器，用于与WFD接收端建立QUIC连接；
    所述处理器，用于基于所述QUIC连接创建第一QUIC流，通过所述第一QUIC流与所述WFD接收端进行RTSP协商、以创建RTSP会话；
    所述处理器器，用于响应于通过所述RTSP会话接收到所述WFD接收端发送的播放请求，基于所述QUIC连接创建第二QUIC流；
    所述收发器，用于通过所述第二QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
  66. 一种终端设备，其特征在于，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
    所述收发器，用于通过TCP协议与WFD接收端进行RTSP协商，以创建RTSP会话；
    所述收发器，用于与所述WFD接收端建立QUIC连接；
    所述处理器，用于基于所述QUIC连接创建第三QUIC流；
    所述收发器，用于响应于通过所述RSTP会话接收到所述WFD接收端发送的播放请求，通过所述第三QUIC流向所述WFD接收端发送所述无线投屏传输的音频数据和视频数据中的至少一种。
  67. 一种终端设备，其特征在于，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
    所述收发器，用于与WFD源端建立QUIC连接；
    所述收发器，用于通过第一QUIC流与所述WFD源端进行RTSP协商、以创建RTSP会话，所述第一QUIC流是所述WFD源端基于所述QUIC连接创建的；
    所述收发器，用于通过所述RTSP会话向所述WFD源端发送播放请求；
    所述收发器，用于通过第二QUIC流接收所述WFD源端发送的所述无线投屏传输的音频数据和视频数据中的至少一种，所述第二QUIC流是所述WFD源端基于所述QUIC连接创建的。
  68. 一种终端设备，其特征在于，所述终端设备包括：处理器和与所述处理器相连的收发器；其中，
    所述收发器，用于通过TCP协议与WFD源端进行RTSP协商，以创建RTSP会话；
    所述收发器，用于与所述WFD源端建立QUIC连接；
    所述收发器，用于通过所述RTSP会话向所述WFD源端发送播放请求；
    所述收发器，用于通过第三QUIC流接收所述WFD源端发送的所述无线投屏传输的所述音频数据和视频数据中的至少一种，所述第三QUIC流是所述WFD源端基于所述QUIC连接创建的。
  69. 一种计算机可读存储介质，其特征在于，所述可读存储介质中存储有可执行指令，所述可执行指令由处理器加载并执行以实现如权利要求1至32任一所述的用于无线投屏的数据传输方法。
  70. 一种芯片，其特征在于，所述芯片包括可编程逻辑电路或程序，所述芯片用于实现如权利要求1至32中任一所述的用于无线投屏的数据传输方法。
CN202180096103.0A 2021-07-01 2021-07-01 用于无线投屏的数据传输方法、装置、设备及存储介质 Pending CN117083867A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/104106 WO2023272702A1 (zh) 2021-07-01 2021-07-01 用于无线投屏的数据传输方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN117083867A true CN117083867A (zh) 2023-11-17

Family

ID=84692216

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180096103.0A Pending CN117083867A (zh) 2021-07-01 2021-07-01 用于无线投屏的数据传输方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN117083867A (zh)
WO (1) WO2023272702A1 (zh)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016093623A1 (ko) * 2014-12-11 2016-06-16 엘지전자 주식회사 Wfd에서 보조 컨텐츠를 출력하는 방법 및 장치
CN106453287A (zh) * 2016-09-28 2017-02-22 北京金山安全软件有限公司 一种多媒体数据的传输方法、客户端及服务器
CN110086578B (zh) * 2018-01-25 2021-06-01 华为技术有限公司 数据传输方法、装置和系统
CN109996097B (zh) * 2019-03-12 2022-01-04 广州虎牙信息科技有限公司 一种投屏方法、系统及存储装置
CN110740300B (zh) * 2019-11-01 2021-10-15 普联技术有限公司 多媒体数据的传输方法、系统、客户端及视频监控设备

Also Published As

Publication number Publication date
WO2023272702A1 (zh) 2023-01-05

Similar Documents

Publication Publication Date Title
US10354618B2 (en) Wireless communication system for offline participation in a display session
JP4648458B2 (ja) 通信システムにおけるサービス品質の制御
US7613147B2 (en) Packet-based conversational service for a multimedia session in a mobile communications system
US20110196973A1 (en) Method and apparatus for inter-device session continuity (idsc) of multi media streams
EP3078182B1 (en) Wireless media sharing from multiple sources to a single sink
US20100250678A1 (en) Peer-to-peer aided live video sharing system
JP4778048B2 (ja) サービス・エンドポイントに対して実質的に透過的な方法でネットワーク・サービスを利用するための方法および装置
WO2013178142A1 (zh) Dlna设备共享方法及装置
CN109417548B (zh) 封装媒体流量在基于数据报的传输层上的高效传输
US20170264929A1 (en) Video and audio transmission method and system thereof
CN101674228B (zh) 实现流媒体通信的方法、装置及系统
US20130290517A1 (en) Nat traversal under tcp for real time streaming protocol
WO2019184262A1 (zh) 多类型媒体数据网络地址转换穿越方法、终端及系统
Shacham et al. The virtual device: Expanding wireless communication services through service discovery and session mobility
WO2019129125A1 (zh) 智能眼镜与智能设备交互的方法、系统及存储介质
Takasugi et al. Seamless service platform for following a user's movement in a dynamic network environment
JP5243336B2 (ja) 通信システム、通信端末、通信方法、および通信プログラム
EP4391611A1 (en) Information transmission method and apparatus
CN117083867A (zh) 用于无线投屏的数据传输方法、装置、设备及存储介质
CN101179502A (zh) 一种流媒体数据的转发系统和转发方法
CN116708381B (zh) 跨网络的数据传输方法、装置和存储介质及电子设备
WO2010045830A1 (zh) 流媒体业务实现方法及装置
CN117411991A (zh) 基于无流量网络的视频通话方法
JP2005051680A (ja) マルチメディア通信装置またはマルチメディア通信方式またはビデオ配信システムおよびビデオ会議システム
CN112653925A (zh) 媒体播放的跨设备转移方法、系统、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination