CN117441155A - 显示设备以及投屏方法 - Google Patents

Abstract

一种显示设备，包括：显示器；以及控制器，控制器与显示器通信连接，控制器被配置为：响应于接收到投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；接收投屏设备发送的投屏数据，其中，投屏数据包含多个视频帧，视频帧包含多个RTP数据包；检测RTP数据包是否连续；以及基于检测结果来控制显示器播放投屏数据。还提供一种投屏方法。

Description

显示设备以及投屏方法

相关申请的交叉引用

本申请要求于2021年7月7日提交的申请号为202110766329.9、于2021年7月13日提交的申请号为202110789158.1的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及显示设备技术领域，尤其涉及显示设备以及投屏方法。

背景技术

显示设备是一种可实现双向人机交互功能，集影音、娱乐、数据等多种功能于一体的设备。为满足用户多样化的需求，显示设备安装有投屏、影音、娱乐等多种应用，通过用户界面与用户进行交互和信息交换。

针对于投屏应用来说，Miracast投屏是显示设备之间一种重要的资源共享方式，其通过过RTSP(Real TimeStreaming Protoco，实时流传输协议)来实现媒体共享。例如，在利用Miracast投屏时，投屏设备(例如，手机和平板设备等)需要获取待分享媒资的视频帧，然后将视频帧进行压缩和编码，并传输至显示设备。显示设备对接收到的媒体数据进行解压、解码后进行展示。由于部分手机在进行数据压缩时采用不同版本的压缩算法，使得发送到显示设备的数据量太大，显示设备来不及处理，从而导致媒体播放延迟或者出现花屏问题，使用户体验效果不佳。

此外，在投屏过程中，由于手机屏幕的长宽比不适配于显示设备的屏幕的长宽比，会导致显示设备在进行投屏时出现投屏画面被拉伸缩放的现象，也使得用户体验效果不佳。

发明内容

本申请提供了一种显示设备，包括：显示器；以及控制器，控制器与显示器通信连接，控制器被配置为：响应于接收到的投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；接收投屏设备发送的投屏数据，其中，投屏数据包含多个视频帧，视频帧包含多个RTP数据包；检测RTP数据包是否连续；以及基于检测结果来控制显示器播放投屏数据。

本申请还提供了一种投屏方法，包括：响应于接收到的投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；接收所述投屏设备发送的投屏数据，其中，投屏数据包含多个视频帧，视频帧包含多个RTP数据包；检测RTP数据包是否连续；以及基于检测结果来控制显示设备的显示器播放投屏数据。

本申请还提供了一种计算机可读非易失性存储介质，其上存储有计算机指令，当在处理器上被运行时执行：响应于接收到投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；收所述投屏设备发送的投屏数据，其中，所述投屏数据包含多个视频帧，所述视频帧包含多个RTP数据包；检测所述RTP数据包是否连续；以及基于检测结果来控制所述显示器播放所述投屏数据。

附图说明

图1为根据一些实施例的显示设备与控制装置之间操作场景的示意图；

图2为根据一些实施例的控制装置100的硬件配置框图；

图3为根据一些实施例的显示设备200的硬件配置框图；

图4为根据一些实施例的显示设备200中软件配置示意图；

图5为根据一些实施例的投屏方法的流程示意图；

图6为根据一些实施例的投屏方法的另一流程示意图；

图7为根据一些实施例的投屏方法的时序图；

图8a为根据一些实施例的显示设备200横屏状态的效果示意图；

图8b为根据一些实施例的显示设备200竖屏状态的效果示意图；

图9为根据一些实施例的投屏数据被拉伸的显示效果示意图；

图10为根据一些实施例的投屏方法的流程示意图；以及

图11为根据一些实施例的投屏方法的时序图。

具体实施方式

为使本申请的目的和实施方式更加清楚，下面将结合本申请示例性实施例中的附图，对本申请实施方式进行描述，显然，描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。

需要说明的是，本申请中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。

本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。

图1为根据实施例的显示设备与控制装置之间操作场景的示意图。如图1所示，用户可通过智能设备300或控制装置100操作显示设备200。

在一些实施例中，控制装置100可以是遥控器，遥控器和显示设备的通信包括红外协议通信或蓝牙协议通信，及其他短距离通信方式，通过无线或有线方式来控制显示设备200。用户可以通过遥控器上按键、语音输入、控制面板输入等输入用户指令，来控制显示设备200。

在一些实施例中，也可以使用智能设备300(如移动终端、平板电脑、计算机、笔记本电脑等)以控制显示设备200。例如，使用在智能设备上运行的应用程序控制显示设备200。

在一些实施例中，还可以对显示设备200采用除了控制装置100和智能设备300之外的方式进行控制，例如，可以通过显示设备200设备内部配置的获取语音指令的模块直接接收用户的语音指令来进行控制，也可以通过显示设备200设备外部设置的语音控制设备来接收用户的语音指令来进行控制。

在一些实施例中，显示设备200还与服务器400进行数据通信。可允许显示设备200通过局域网(LAN)、无线局域网(WLAN)和其他网络进行通信连接。服务器400可以向显示设备200提供各种内容和互动。

图2为根据示例性实施例的控制装置100的配置框图。如图2所示，控制装置100包括控制器110、通信接口130、用户输入/输出接口140、存储器、供电电源。控制装置100可接收用户的输入操作指令，并将操作指令转换为显示设备200可识别和响应的指令，使得用户与显示设备200之间进行交互。

图3示出了根据示例性实施例的显示设备200的硬件配置框图。

在一些实施例中，显示设备200包括调谐解调器210、通信器220、检测器230、外部装置接口240、控制器250、显示器260、音频输出接口270、存储器、供电电源、用户接口中的至少一种。

在一些实施例中，控制器包括处理器、视频处理器、音频处理器、图形处理器、RAM、ROM和用于输入/输出的第一接口至第n接口。

在一些实施例中，显示器260包括用于呈现画面的显示屏组件、用于驱动图像显示的驱动组件、用于接收源自控制器输出的图像信号并进行显示视频内容、图像内容以及菜单操控界面的组件以及用户操控UI界面。

在一些实施例中，显示器260可为液晶显示器、OLED显示器、以及投影显示器，还可以为一种投影装置和投影屏幕。

在一些实施例中，通信器220是用于根据各种通信协议类型与外部设备或服务器进行通信的组件。例如：通信器可以包括Wifi模块、蓝牙模块、有线以太网模块等其他网络通信协议芯片或近场通信协议芯片、以及红外接收器中的至少一种。显示设备200可以通过通信器220与外部控制设备100或服务器400建立控制信号和数据信号的发送和接收。

在一些实施例中，用户输入接口，可用于接收控制装置100(如：红外遥控器等)的控制信号。

在一些实施例中，检测器230用于采集外部环境或与外部交互的信号。例如，检测器230包括光接收器、图像采集器或声音收集器等。

在一些实施例中，外部装置接口240可以包括但不限于如下：高清多媒体接口接口(HDMI)、模拟或数据高清分量输入接口(分量)、复合视频输入接口(CVBS)、USB输入接口(USB)、RGB端口等任一个或多个接口。也可以是上述多个接口形成的复合性的输入/输出接口。

在一些实施例中，调谐解调器210可以通过有线或无线接收方式来接收广播电视信号，以及从多个无线或有线广播电视信号中解调出音视频信号，如EPG数据信号。

在一些实施例中，控制器250和调谐解调器210可以位于不同的分体设备中，即调谐解调器210也可在控制器250所在的主体设备的外置设备中，如外置机顶盒等。

在一些实施例中，控制器250，通过存储在存储器上的各种软件控制程序，来控制显示设备的工作和响应用户的操作。控制器250控制显示设备200的整体操作。例如：响应于接收到用于选择在显示器260上显示UI对象的用户命令，控制器250可以执行与由用户命令选择的对象有关的操作。

在一些实施例中控制器包括中央处理器(Central Processing Unit，CPU)、视频处理器、音频处理器、图形处理器(Graphics Processing Unit，GPU)、RAM(Random Access Memory，RAM)、ROM(Read-Only Memory,ROM)、用于输入/输出的第一接口至第n接口、通信总线(Bus)等中的至少一种。

CPU处理器，用于执行存储在存储器中操作系统和应用程序指令，以及根据接收外部输入的各种交互指令，来执行各种应用程序、数据和内容，以便最终显示和播放各种音视频内容。CPU处理器，可以包括多个处理器。如，包括一个主处理器以及一个或多个子处理器。

在一些实施例中，视频处理器，用于将接收外部视频信号，根据输入信号的标准编解码协议，进行解压缩、解码、缩放、降噪、帧率转换、分辨率转换、图像合成等视频处理，可得到直接可显示设备200上显示或播放的信号。

在一些实施例中，视频处理器，包括解复用模块、视频解码模块、图像合成模块、帧率转换模 块、显示格式化模块等。其中，解复用模块，用于对输入音视频数据流进行解复用处理。视频解码模块，用于对解复用后的视频信号进行处理，包括解码和缩放处理等。图像合成模块，如图像合成器，其用于将图形生成器根据用户输入或自身生成的GUI信号，与缩放处理后视频图像进行叠加混合处理，以生成可供显示的图像信号。

在一些实施例中，音频处理器，用于接收外部的音频信号，根据输入信号的标准编解码协议，进行解压缩和解码，以及降噪、数模转换、和放大处理等处理，得到可以在扬声器中播放的声音信号。

在一些实施例中，用户可在显示器260上显示的图形用户界面(GUI)输入用户命令，则用户输入接口通过图形用户界面(GUI)接收用户输入命令。或者，用户可通过输入特定的声音或手势进行输入用户命令，则用户输入接口通过传感器识别出声音或手势，来接收用户输入命令。

图4为根据一些实施例的显示设备200中软件配置示意图。

在一些实施例中，显示设备的系统可以包括内核(Kernel)、命令解析器(shell)、文件系统和应用程序。

参见图4，在一些实施例中，将系统分为四层，从上至下分别为应用程序(Applications)层(简称“应用层”)，应用程序框架(Application Framework)层(简称“框架层”)，安卓运行时(Android runtime)和系统库层(简称“系统运行库层”)，以及内核层。

在一些实施例中，应用程序层中运行有至少一个应用程序，这些应用程序可以是操作系统自带的窗口(Window)程序、系统设置程序或时钟程序等；也可以是第三方开发者所开发的应用程序。

基于上述显示设备200，用户可在显示设备200的应用程序中心内下载投屏应用，投屏应用可为基于Miracast(无线显示)功能的应用程序，Miracast利用WIFI点对点(peer-to-peer)网络传输功能把投屏设备的投屏数据传输到显示设备200进行播放，从而达到资源共享的目的，其中，投屏数据可以为音视频数据，投屏设备可为智能手机、平板电脑、计算机等终端设备。

Miracast在实现投屏功能时，需要利用WFD(Wi-Fi Display)交互协议来实现媒资共享。而WFD交互协议利用了RTSP(Real Time Streaming Protocol)协议来实现投屏设备和显示设备之间的能力协商。根据RTSP，投屏设备和显示设备在M3阶段(在该阶段，投屏设备询问显示设备的音视频解码能力参数(例如格式，分辨率等等)，然后显示设备答复支持的参数列表)和M4阶段(在该阶段，投屏设备告知显示设备最终采用的参数参数，然后显示设备答复确认)，规定了设备两端需要协商的一些能力参数，其中一项就是视频能力协商，两端协商好要播放的投屏数据的分辨率、刷新率以及压缩算法等。显示设备200通常希望投屏设备采用更高的压缩算法，通过压缩尽可能的减少数据量，但由于部分投屏设备比较老旧或者比较低端，仍然用旧版的压缩算法，比如，H.264 Level 3.2或者更早的压缩算法。这样使得从投屏设备发过来的投屏数据量非常大，导致显示设备200来不及处理，从而出现媒资延迟或者由于丢包导致的花屏问题。考虑上述问题，本申请在一些实施例中提供了一种显示设备及投屏方法。需要说明的是，本申请中的显示设备不仅包括智能电视，还可以指的是计算机、平板电脑等。

下面结合附图，描述本申请实施例提供的投屏过程。

如图3所示，根据本申请的实施例的显示设备200包括显示器260和控制器250，控制器250与显示器260通信连接，控制器250被配置为执行图5中的投屏过程。

图5为根据一些实施例的投屏方法的流程示意图。如图5所示，该投屏过程可包括：

S501：响应于接收到的用于投屏的信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互。

在一些实施例中，用户可在投屏设备输入投屏信号，其中，该投屏设备具备投屏应用，该投屏应用可以基于Miracast投屏功能。例如，在投屏设备上设置有投屏控件，用户通过触控点击或者选中该投屏控件启动Miracast投屏功能。在启动Miracast投屏功能后，投屏设备向显示设备200发送用于投屏的信号，显示设备200响应于该用于投屏的信号，启动自身的Miracast投屏功能，基于Miracast以使显示设备与投屏设备进行数据交互。

在一些实施例中，显示设备200启动Miracast投屏功能时，启动自身的P2P网络。当然，投屏设备在启动Miracast投屏功能时，也启动自身的P2P网络。基于P2P网络，显示设备200与投屏设备建立连接，两端进行网络部分的交互，获取彼此的IP地址。

在一些实施例中，显示设备200和投屏设备在建立P2P网络连接后，各自启动RTSP交互线程，进行握手交互阶段，实现显示设备200与投屏设备之间的数据交互。

S502：接收所述投屏设备发送的投屏数据，其中，所述投屏数据包含多个视频帧，所述视频帧包含多个RTP数据包。

在一些实施例中，在显示设备200和投屏设备的RTSP交互线程中，投屏设备200将投屏数据解析为多个视频帧，每一视频帧由多个RTP数据包组成，每一RTP数据包都标记有sequcence number(封包序号)，该封包序号指示了RTP数据包的先后连续性。投屏设备将多个RTP数据包向显示设备200发送，显示设备200接收来自投屏设备的包括RTP数据包的投屏数据。

S503：检测所述RTP数据包。

在一些实施例中，显示设备200在接收到投屏数据后，可开通守包线程。通过守包线程检测RTP数据包。在此，守包线程主要是检测RTP数据包的连续性。

接下来，基于检测结果来控制显示设备200的显示器的对投屏数据的播放。

在本申请的实施例中，该过程可以分为两种情况来操作。

当检测结果为连续时，继续执行S504：当RTP数据包为连续时，控制所述显示器播放所述投屏数据。

在本申请的实施例中，可以在当前RTP数据包与上一个接收到的RTP数据包为连续时，来播放该投屏数据。

在一些实施例中，若显示设备200可以及时处理所接收到的投屏数据，即及时将所述投屏数据进行解码时，守包线程可检测出RTP数据包一直为连续状态，则显示设备200将RTP数据包去掉包头，发送至播放器进行播放并于显示器进行展示。

而在检测结果为不连续时，则执行S505：在RTP数据包为不连续时，向所述投屏设备发送RTSP消息，以使所述投屏设备根据所述RTSP消息来降低投屏数据的分辨率。

在一些实施例中，守包线程在检测当前RTP数据包时，发现当前RTP数据包与上一个接收到的RTP数据包不连续时，也就是说，显示设备200检测出RTP数据包存在丢失情况，则向所述投屏设备发送RTSP消息。投屏设备在接收到该RTSP消息后，降低投屏数据的分辨率，并重新进行投屏数据的组包。

在一些实施例中，基于RTP数据包中所标记的封包序号，显示设备200可以通过检测当前RTP数据包的封包序号与上一个接收到的RTP数据包的封包序号是否连续来判断RTP数据包是否为连续。在所述封包序号不连续时，向所述投屏设备发送RTSP消息。

若是RTP数据包丢失的数量在一定范围内，基本不会影响到整个投屏数据播放的流畅度。因此，在一些实施例中，所述控制器250还被配置为：在所述封包序号不连续时，计算丢失的RTP数据包的数量。丢包数在预定范围内则RTP数据包仍视为是连续的。仅在丢失的所述RTP数据包的数量大于预设值时，才向所述投屏设备发送RTSP消息。在实施例中，控制器250可将预设值设置为5，该预设值的具体数值可根据设备相关参数设置。

在一些实施例中，显示设备200中的守包线程在检测出当前RTP数据包的封包序号与上一个接收到的RTP数据包的封包序号不连续时，可进一步计算丢失的RTP数据包的数量。在本申请的实施例中，通过将当前RTP数据包的封装序号与上一个接收到的RTP数据包的封包序号做差，得到丢失的所述RTP数据包的数量。

例如，在本申请的示例中，显示设备200中的守包线程在检测出当前RTP数据包的封包序号为6，上一个接收到的RTP数据包的封包序号为3，则两个封包序号是不连续的。通过对两个封包序号做差得出当前丢失的RTP数据包的数量为3。而该差值3小于预设值5，则可视为RTP数据包是连续的，可不发送RTSP消息。若检测出当前RTP数据包的封包序号“9”与上一个接收到的RTP数据包的封包序号“3”两者之间差6，并且丢失的RTP数据包的数量已超过预设值5，则检测结果为RTP数据包是不连续的。基于该检测结果显示设备200向投屏设备发送RTSP消息。

在一些实施例中，在显示设备200和投屏设备的RTSP交互线程中，显示设备200检测出RTP数据包丢失后，添加一新的RTSP消息，该RTSP消息用于协商所述显示设备与所述投屏设备之间的视频格式。该消息通过SET_PARAMETER(设置参数)来修改分辨率。

在一些实施例中，投屏设备和显示设备在基于RTSP的数据交互过程中，两端在M3/M4阶段时，规定了设备两端需要协商的一些能力参数，其中一项就是视频格式的能力协商(wfd_video_formats)，在协商过程中确定出要播放的投屏数据中每一帧图像的分辨率、帧率等。视频格式(video format)的协商字段为连续不同长度的16进制字符串，其中以空格分割不同的参数。

例如，显示设备200在一开始的RTSP交互线程中，在M3/M4阶段视频流协商过程中，投屏设备告诉显示设备200的视频协商参数如下：

wfd_video_formats:00 01 01 02 00000080 00000000 0000000 00 0000 0000 00 none none。根据Wi-Fi_Display_Specification Section6.1.3(Wi-Fi标准协议规格第6.1.3节)，该RTSP消息中0080表示按1920*1080P30(分辨率1920*1080,刷新率30fps)播放。

在显示设备200检测出RTP数据包丢失后，向投屏设备发送RTSP消息M17，该消息内容如下：

wfd_video_formats:00 01 01 02 00000020 00000000 0000000 00 0000 0000 00 none none。该RTSP消息中0020表示按1280*720P30(分辨率1280*720，刷新率30fps)播放。

在显示设备200发送了RTSP消息之后，显示设备200还需要进一步判断投屏设备是否根据该消息修改了分辨率。图6为根据一些实施例的投屏方法的另一流程示意图。结合图6，控制器250还需被配置为执行以下过程：

S601：记录所述投屏数据的当前播放进度。

在一些实施例中，在显示设备200发送了RTSP消息之后，显示设备200记录投屏数据的当前播放进度。例如，显示设备200记录当前投屏数据播放了48％，又如，显示设备200记录当前投屏数据播放至第20分钟35秒。

S602：判断是否接收到修改分辨率成功的反馈消息。

在一些实施例中，在投屏设备接收到RTSP消息之后，基于RTSP消息中的指示，降低投屏数据的播放分辨率。投屏设备在修改成功后会向显示设备200发送修改成功的反馈消息，以使显示设备200得知投屏设备已将分辨率修改成功。当然，若是投屏设备没有修改成功，则不会发送修改分辨率成功的反馈消息。

S603：接收所述投屏设备发送的处于降低的分辨率的投屏数据。

在一些实施例中，在投屏设备在降低投屏数据的播放分辨率之后，会重新对投屏数据进行组包封装，将处于降低的分辨率的投屏数据打包为多个RTP数据包，并将重新组包后的投屏数据发送至显示设备200。显示设备200接收投屏设备所发送的低分辨率的投屏数据。

S604：基于所述播放进度，控制所述显示器按照降低的分辨率继续播放所述投屏数据。

在一些实施例中，显示设备200在接收到处于降低的分辨率的投屏数据之后，查找之前记录的投屏数据的播放进度，基于记录播放进度对投屏数据进行续播。

S605：停止所述RTSP交互线程，控制所述显示器退出所述投屏数据的播放过程。

在一些实施例中，当显示设备200未接收到所述投屏设备发送的分辨率修改成功的反馈消息，也就是说，投屏设备没有进行降低分辨率的操作，由于此时用户在观看投屏数据时已经出现延迟或者花屏等问题，导致观感不佳，显示设备200可停止所述RTSP交互线程，退出Miracast投屏功能，也就是退出所述投屏数据的播放过程。

下面结合附图，进一步描述投屏的过程。

图7为根据一些实施例的投屏方法的时序图。如图7所示，用户通过显示设备200上所安装的具有投屏的应用程序触发投屏功能，例如，一些流媒体应用程序的播放界面包括投屏控件，用户选择该控件，可以启动对应的投屏功能。显示设备200启动Miracast投屏功能后，向投屏设备发送投屏信号，显示设备200与投屏设备均启动各自的P2P网络，两者之间建立P2P网络连接。随后，显示设备200与投屏设备均启动各自的RTSP交互线程。投屏设备200将投屏数据组包为RTP数据包并发送至显示设备200，显示设备200检测接收到的RTP数据包。在RTP数据包丢失的数量大于预设值时，显示设备200向投屏设备发送RTSP消息。投屏设备接收RTSP消息，并根据该RTSP消息降低投屏数据的分辨率。投屏设备将分辨率修改成功的消息反馈至显示设备200，并将处于降低的分辨率的投屏数据反馈至显示设备200。显示设备200基于之前的播放进度，续播处于降低的分辨率的投屏数据，以实现投屏数据的流畅播放。

在本申请的实施例中，显示设备通过发送用于指示投屏设备降低分辨率的RTSP消息，使投屏设备降低投屏数据播放的分辨率，从而降低数据量，显示设备在接收到投屏设备发送的处于降低的分辨率的投屏数据后达到流畅播放的效果，使得用户可以流畅的观看完投屏数据，提高了用户体验。

本申请实施例还提供了一种投屏方法，所述投屏方法包括：显示设备200响应于接收到投屏信号，启动RTSP交互线程，以使显示设备200与投屏设备进行数据交互。显示设备200接收所述投屏设备发送的投屏数据，其中，所述投屏数据包含多个视频帧，所述视频帧包含多个RTP数据包。在接收到投屏数据后，显示设备200需要检测所述RTP数据包是否连续。以及基于检测结果显示设备200控制显示器来播放投屏数据。当RTP数据包是连续时，显示器播放投屏数据。而在RTP数据包不连续时，向所述投屏设备发送RTSP消息，以使所述投屏设备根据所述RTSP消息来降低分辨率。

在一些实施例中，所述RTP包中标记有封包序号，显示设备200可以通过检测当前RTP数据包的封包序号与上一个接收到的RTP数据包的封包序号是否连续来判断RTP数据包是否为连续。在所述封包序号不连续时，显示设备200向所述投屏设备发送RTSP消息。

在一些实施例中，在所述封包序号不连续时，显示设备200进一步计算丢失的RTP数据包的数量。在丢失的所述RTP数据包的数量达到预设值时，显示设备200向所述投屏设备发送RTSP消息。

在一些实施例中，显示设备200中的控制器250还可以控制固定组件，以实现显示器260的旋转，从而使得显示设备200在横屏状态和竖屏状态之间转换。

在一些实施例中，该固定组件固定在显示器260的背面，固定组件用于和墙面固定，固定组件可以被控制器250控制，以使显示器260在竖直的平面内进行旋转，从而显示器260处于不同的屏幕状态。屏幕状态包括横屏状态和竖屏状态，图8a示例性示出了根据一些实施例的显示设备200横屏状态的效果示意图。参照图8a，所述横屏状态是指，从显示器260正面观看时，所述显示器260水平方向上的长度大于竖直方向上的长度的状态。图8b示例性示出了根据一些实施例的显示设备200竖屏状态的效果示意图。由图5b所示，所述竖屏状态是指，从显示器260正面观看时，所述显示器260水平方向上的长度小于竖直方向上的长度的状态。在本申请的实施例中，竖直可以是大致竖直。

如图9所示，针对上述显示器260可以旋转的显示设备200，在通过智能手机、平板电脑等竖屏投屏设备进行投屏时，若是投屏设备和显示设备200之间屏幕状态不一致，会导致显示设备200在进行投屏时出现投屏画面被拉伸缩放的现象。而投屏数据被拉伸，则使得用户体验效果不佳。

图10为根据一些实施例的投屏方法的流程示意图。在本申请的实施例中，以图3所示的显示设备为例来详细描述该投屏方法的实施。参照图10，该投屏过程如下：

S1001：响应于接收到投屏信号，启动RTSP交互线程，以使所述显示设备与所述投屏设备进行数据交互。

在一些实施例中，S1001可以参考如图5的S501的相关描述。

S1002：向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述显示器所处的状态。

在本申请的实施例中，视频格式的协商字段可以如下设置：

00 01 01 08 00000001 00000000 00000003 00 0000 0000 13 none none

其中，通过部分参数来协商投屏数据的分辨率及帧率，例如，参数00000001为CEA(Consumer Electronics Association,美国消费电子协会)所支持的图像压缩和编码需要遵循的标准，又如，00000000为VESA(Video Electronics Standards Association，视频电子标准协会)所支持的图 像压缩和编码需要遵循的标准。CEA，VESA等国际视频编码标准参数协商了两端对于图像的压缩分辨率和视频帧率。CEA，VESA都是4个字节，32位，用16进制表示，每一位数据位都有具体的标准含义，0代表不支持，1代表支持。如表1所示，为CEA所支持的每一数据位所代表的分辨率和帧率。

表1：

在表1中，如第6位数据位代表1280*720分辨率，帧率是60。如果该数据位所对应的为1，则代表该显示设备支持1280*720分辨率，帧率60，如果该数据位所对应的为0，则代表该显示设备不支持1280*720分辨率，帧率60。其他标准同理，在此不再赘述。需要说明的是，若是多个参数所支持的分辨率和帧率不同时，则选择其中最高的分辨率和帧率。

在一些实施例中，显示设备200和投屏设备在进行M3阶段交互过程中，显示设备200会将所有可以支持的分辨率和帧率以RTSP消息的形式告知投屏设备，投屏设备收到显示设备200的能力参数后，会选择一个最大最优值进行编码压缩。例如显示设备200可以支持CEA标准是1920*1080、60帧/s，根据向下兼容的特性，对应的CEA标准低分辨率也是支持的，如1920*1080、30帧/s，1280x720、60帧/s和1280x720、30帧/s也是支持的。当投屏设备收到显示设备200的能力参数后，会选择其中一项，然后将结果告知显示设备200，显示设备200收到后会进行确认。

在一些实施例中，显示设备200在发送用于协商所述显示设备与所述投屏设备之间的视频格式的RTSP消息时，先检测当前显示器260所处的状态，即判断当前显示器260的状态是横屏状态还是竖屏状态。根据当前的显示器260的状态确定出屏幕状态标识，并在视频格式协商字段中添加屏幕状态标识，通过屏幕状态标识指示出显示器所处的状态。

在一些实施例中，在所述显示器260处于所述横屏状态时，控制器250控制所述视频格式协商字段中的任一保留的数据位标识为0。在所述显示器260处于所述竖屏状态时，控制器250控制所述视频格式协商字段中的任一保留的数据位标识为1。在视频格式的协商字段中，每一个国际视频编码标准参数均有32位数据位，确在32位数据位中均有暂时没有开发利用的数据位，即保留数据位，本申请可任意选择其中一个数据位当作屏幕状态标识，第一数值(例如，1)代表竖屏状态，与第一数值不同的第二数值(例如，0)代表横屏横屏状态。需要说明的是，在另一种实现方式中，由于一个数据位存在两种状态，即第一数值或第二数值，例如0或1，此处也可以设置第二数值代表竖屏状态，第一数值代表横屏横屏状态，只要显示设备200和投屏设备两端协商定义统一即可，在此不做限定。

在一些实施例中，由于后续视频分辨率等不断升级，国际视频编码标准参数中的数据位也会逐渐被设定所支持的新的分辨率等。因此，可控制所述视频格式协商字段中最后一位数据位用于设置屏幕状态标识。

在一些实施例中，投屏设备在接收到RTSP消息后，只需在原有分析确认分辨率的代码程序中加入一个判断语句，判断视频格式协商字段中最后一位数据是1还是0，若是1，则可得知显示设备的显示器为竖屏状态，若是0，则可得知显示设备的显示器为横屏状态。

例如，显示设备200在检测到当前显示器状态为竖屏状态时，向投屏设备发送的RTSP消息如下：

wfd_video_formats:00 01 01 02 800000A0 00000000 0000000 00 0000 0000 00 none none。

在该消息中，800000A0为CEA所支持的图像压缩和编码需要遵循的标准，将800000A0转换为二进制为1000 0000 0000 0000 0000 1010 0000。由右往左数，第6位、第8位以及第32位为1，其他均为0。参见表1，第6位、第8位分别代表1280*720、p60和1920*1080、p60，第32位代表当 前显示器的状态为竖屏。投屏设备在接收到该消息后，向显示设备回复消息如下：

wfd_video_formats:00 01 01 02 00000080 00000000 0000000 00 0000 0000 00 none none。

从投屏设备回复的消息中可以得知，投屏设备准备选择第8位所代表的1920*1080、p60对投屏数据进行编码压缩。

S1003：接收来自所述投屏设备根据所述屏幕状态标识编码的投屏数据，并控制显示器播放所述投屏数据。

在一些实施例中，投屏设备在根据RTSP消息得知当前显示设备端显示器的状态，以及显示设备200所支持的视频能力之后，择优选择分辨率及帧率，并根据所述屏幕状态标识进行投屏数据的编码压缩。

在一些实施例中，在所述显示器处于所述横屏状态时，将投屏设备与所述显示设备所共同支持的最大屏幕分辨率作为横屏分辨率对投屏数据进行编码。

在一些实施例中，在投屏设备接收到该RTSP消息后，根据消息中的屏幕状态标识判断显示设备的显示器的所处状态，并选择出两者所共同支持的最大屏幕分辨率。在显示设备认同该最大分辨率之后，若是显示设备的显示器处于所述横屏状态，则将按照横屏分辨率对投屏数据进行编码。在本申请的实施例中，所述横屏分辨率可以为长乘宽分辨率，例如，两端所支持的最大分辨率为1920*1080，则按照1920*1080对投屏数据进行编码压缩。

在本申请的实施例中，在所述显示器处于所述竖屏状态时，将投屏设备与所述显示设备所共同支持的最大屏幕分辨率作为竖屏分辨率对投屏数据进行编码。

将压缩后的投屏数据发送至显示设备200，显示设备200接收投屏数据，并控制显示器播放出该投屏数据。

图9为根据一些实施例的投屏方法的时序图。如图9所示，用户启动投屏设备上所安装的投屏应用，触发投屏功能，投屏设备向被投屏设备(也可称为“显示设备”，例如图3中的200)发送投屏信号，并与被投屏设备建立TCP连接。投屏设备与被投屏设备各自开启RTSP线程，进行能力协商。被投屏设备检测当前显示器的所处状态，并通过屏幕状态标识记录于两端的视频格式的协商字段中。被投屏设备将含有屏幕状态标识的RTSP消息发送至投屏设备，投屏设备根据RTSP消息择优选择自身所支持的最大分辨率和帧率，并获取被投屏设备的认同。在被投屏设备确认该分辨率和帧率合适后，投屏设备根据屏幕状态标识，若是指示横屏，则按照横屏分辨率对投屏数据进行编码，若是指示竖屏，则按照竖屏分辨率进行编码。投屏设备将编码后的投屏数据发送至被投屏设备。被投屏设备接收投屏数据并进行解码，将解码后的投屏数据展示于显示器上。

本申请中，被投屏设备通过屏幕状态标识来记录当前显示器是处于横屏状态还是竖屏状态，投屏设备在RTSP交互过程获取当前被投屏设备中显示器所处的状态，并对投屏数据进行匹配编码，使得投屏数据适配于显示器的所处状态，保证投屏数据的分辨率清晰度，提高了用户体验。

本申请实施例还提供了一种投屏方法，所述方法包括：被投屏设备响应于接收到投屏信号，启动RTSP交互线程，以使被投屏设备与投屏设备进行数据交互。被投屏设备向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述被投屏设备与所述投屏设备之间的视频格式。被投屏设备接收来自所述投屏设备根据所述屏幕状态标识编码的投屏数据，并控制所述被投屏设备中的显示器播放所述投屏数据。

在一些实施例中，在所述向所述投屏设备发送包含屏幕状态标识的RTSP消息中，所述方法还包括：被投屏设备检测当前被投屏设备中显示器所处的状态，根据显示器所处的状态在视频格式协商字段中添加屏幕状态标识。

在一些实施例中，所述方法还包括：在当前被投屏设备中显示器处于所述横屏状态时，被投屏设备控制所述视频格式协商字段中的任一保留的数据位标识为第一数值(例如，0)。在当前被投屏设备中显示器处于所述竖屏状态时，被投屏设备控制所述视频格式协商字段中的任一保留的数据位标识为第二数值(例如，1)。

本申请实施例还提供了一种计算机可读非易失性存储介质，其上存储有计算机指令，当在处理器上被运行时执行：响应于接收到的投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；接收所述投屏设备发送的投屏数据，其中，所述投屏数据包含多个视频帧，所述视频帧包含多个RTP数据包；检测所述RTP数据包是否连续；以及基于检测结果来控制所述显示器播放所述投屏数据。

为了方便解释，已经结合具体的实施方式进行了上述说明。但是，上述示例性的讨论不是意图穷尽或者将实施方式限定到上述公开的具体形式。根据上述的教导，可以得到多种修改和变形。上述实施方式的选择和描述是为了更好的解释原理以及实际的应用，从而使得本领域技术人员更好的使用所述实施方式以及适于具体使用考虑的各种不同的变形的实施方式。

Claims (16)

1. 一种显示设备，包括：

   显示器；以及

   控制器，所述控制器与所述显示器通信连接，所述控制器被配置为：

   响应于接收到的投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；

   接收所述投屏设备发送的投屏数据，其中，所述投屏数据包含多个视频帧，所述视频帧包含多个RTP数据包；

   检测所述RTP数据包是否连续；以及

   基于检测结果来控制所述显示器播放所述投屏数据。
2. 根据权利要求1所述的显示设备，其中，所述控制器进一步被配置为：

   在所述RTP数据包不连续时，向所述投屏设备发送RTSP消息，以使所述投屏设备根据所述RTSP消息降低所述投屏数据的分辨率。
3. 根据权利要求1所述的显示设备，其中，所述RTP包标记有封包序号，所述控制器进一步被配置为：

   检测所述RTP数据包的所述封包序号是否连续；

   在所述封包序号不连续时，向所述投屏设备发送所述RTSP消息。
4. 根据权利要求3所述的显示设备，其中，所述控制器进一步被配置为：

   在所述封包序号不连续时，计算丢失的RTP数据包的数量；

   在丢失的所述RTP数据包的数量大于预设值时，向所述投屏设备发送所述RTSP消息。
5. 根据权利要求4所述的显示设备，其中，所述控制器进一步被配置为：

   通过将当前RTP数据包的封装序号与上一个接收到的RTP数据包的封包序号做差，得到丢失的所述RTP数据包的数量。
6. 根据权利要求1所述的显示设备，其中，所述控制器进一步被配置为：

   在向所述投屏设备发送所述RTSP消息之后，记录所述投屏数据的当前播放进度；

   接收所述投屏设备发送的分辨率修改成功的反馈消息和处于降低的分辨率的投屏数据；以及

   基于所述播放进度，控制所述显示器以降低的分辨率继续播放所述投屏数据。
7. 根据权利要求1所述的显示设备，其中，所述控制器进一步被配置为：

   在向所述投屏设备发送所述RTSP消息之后，未接收到所述投屏设备发送的分辨率修改成功的反馈消息；以及

   停止所述RTSP交互线程，并控制所述显示器退出所述投屏数据的播放过程。
8. 根据权利要求1所述的显示设备，其中，所述显示设备还包括固定组件，所述固定组件用于旋转所述显示器以使所述显示器处于横屏状态或竖屏状态；以及

   其中，所述控制器进一步被配置为：

   向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述显示器所处的状态；以及

   接收来自所述投屏设备的根据所述屏幕状态标识编码的所述投屏数据，并控制所述显示器播放所述投屏数据。
9. 根据权利要求8所述的显示设备，其中，所述控制器进一步被配置为：

   检测所述显示器所处的状态；以及

   根据所述显示器所处的状态将所述屏幕状态标识添加在所述RTSP消息包括的视频格式协商字段中。
10. 一种投屏方法，包括：

    响应于接收到的投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；

    接收所述投屏设备发送的投屏数据，其中，所述投屏数据包含多个视频帧，所述视频帧包含多个RTP数据包；

    检测所述RTP数据包是否连续；以及

    基于检测结果来控制所述显示设备的显示器播放所述投屏数据。
11. 根据权利要求10所述的投屏方法，其中，基于检测结果控制所述显示设备的显示器播放所述投屏数据包括：

    在所述RTP数据包不连续时，向所述投屏设备发送RTSP消息，以使所述投屏设备根据所述RTSP消息降低所述投屏数据的分辨率。
12. 根据权利要求10所述的投屏方法，其中，所述RTP包标记有封包序号，以及向所述投屏设备发送所述RTSP消息的步骤进一步包括：

    检测所述RTP数据包的所述封包序号是否连续；

    在所述封包序号不连续时，向所述投屏设备发送所述RTSP消息。
13. 根据权利要求12所述的投屏方法，其中，所述封包序号不连续时，向所述投屏设备发送RTSP消息的步骤进一步包括：

    在所述封包序号不连续时，计算丢失的RTP数据包的数量；

    在丢失的所述RTP数据包的数量达到预设值时，向所述投屏设备发送所述RTSP消息。
14. 根据权利要求10所述的投屏方法，其中，所述投屏方法还包括：

    向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述显示设备包括的显示器处于横屏状态或竖屏状态；

    接收来自所述投屏设备的根据所述屏幕状态标识编码的所述投屏数据，并控制所述显示设备中的显示器播放所述投屏数据。
15. 根据权利要求14所述的投屏方法，其中，所述方法还包括：

    检测所述显示设备包括的显示器处于横屏状态或竖屏状态；

    根据所述显示器所处的状态将所述屏幕状态标识添加在所述RTSP消息包括的视频格式协商字段中。
16. 一种计算机可读非易失性存储介质，其上存储有计算机指令，当在处理器上被运行时执行：

    响应于接收到的投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；

    接收所述投屏设备发送的投屏数据，其中，所述投屏数据包含多个视频帧，所述视频帧包含多个RTP数据包；

    检测所述RTP数据包是否连续；以及

    基于检测结果来控制所述显示器播放所述投屏数据。