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

Abstract

本申请公开了一种显示设备及投屏方法，包括：显示器；用于旋转显示器的固定组件；与显示器通讯连接的控制器，控制器被配置为：响应于接收到投屏信号，启动RTSP交互线程，以使显示设备与投屏设备进行数据交互；在进行视频格式协商时，向投屏设备发送包含屏幕状态标识的RTSP消息，屏幕状态标识用于指示显示器所处的状态；接收投屏设备根据屏幕状态标识编码的投屏数据，并控制显示器播放投屏数据。本申请中，显示设备通过屏幕状态标识来记录当前显示器的所处状态，投屏设备获取当前显示设备中显示器所处的状态，并对投屏数据进行匹配编码，使得投屏数据适配于显示器的所处状态，保证投屏数据的分辨率清晰度，提高了用户体验。

Description

显示设备及投屏方法

技术领域

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

背景技术

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

针对于投屏应用来说，Miracast投屏是显示设备之间一种重要的资源共享方式，其通过过RTSP(Real TimeStreaming Protocol，实时流传输协议)来实现媒资共享。例如，在利用Miracast投屏时，手机需要获取待分享媒资的视频帧，然后将视频帧进行压缩和编码，并传输至智能电视。智能电视对接收到的媒资数据进行解压，并将解压后的媒资进行展示。目前，在投屏过程中，由于手机屏幕的长宽比不适配于智能电视屏幕的长宽比，会导致智能电视在进行投屏时出现投屏画面被拉伸缩放的现象，使得用户体验效果不佳。

发明内容

本申请提供了一种显示设备及投屏方法，以解决现有技术中由于投屏过程中投屏画面被拉伸缩放使得用户体验效果不佳的技术问题。

为了解决上述技术问题，本申请实施例公开了如下技术方案：

第一方面，本申请实施例公开了一种显示设备，所述显示设备用于展示来自所述投屏设备的投屏数据，所述显示设备包括：

显示器；

固定组件，所述固定组件用于旋转所述显示器以使所述显示器处于横屏状态或竖屏状态；

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

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

向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述显示器所处的状态，所述RTSP消息用于协商所述显示设备与所述投屏设备之间的视频格式；

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

在一些实施例中，在所述向所述投屏设备发送包含屏幕状态标识的RTSP消息的步骤中，所述控制器还被配置为：

检测当前所述显示器所处的状态；

根据所述显示器所处的状态在视频格式协商字段中添加屏幕状态标识。

在一些实施例中，在所述根据所述显示器所处的状态在视频编码能力协商字段中添加屏幕状态标识的步骤中，所述控制器还被配置为：

在所述显示器处于所述横屏状态时，控制所述视频格式协商字段中的任一保留的数据位标识为0；

在所述显示器处于所述竖屏状态时，控制所述视频格式协商字段中的任一保留的数据位标识为1。

第二方面，本申请实施例公开了一种显示设备，所述显示设备用于向被投屏设备发送投屏数据，所述显示设备包括：

显示器；

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

向所述被投屏设备发送投屏信号，启动RTSP交互线程，以使所述显示设备与所述被投屏设备进行数据交互；

接收来自所述被投屏设备发送的包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述显示设备与所述被投屏设备之间的视频格式；

在所述显示器处于所述横屏状态时，将所述显示设备与所述被投屏设备所共同支持的最大屏幕分辨率按照横屏分辨率进行编码；在所述显示器处于所述竖屏状态时，将所述显示设备与所述被投屏设备所共同支持的最大屏幕分辨率按照竖屏分辨率进行编码；

将编码后的所述投屏数据反馈至所述被投屏设备，以使所述被投屏设备播放所述投屏数据。

第三方面，本申请实施例公开了一种投屏方法，所述投屏方法包括：

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

向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述被投屏设备与所述投屏设备之间的视频格式；

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

第四方面，本申请实施例公开了一种投屏方法，所述投屏方法包括：

向被投屏设备发送投屏信号，启动RTSP交互线程，以使投屏设备与所述被投屏设备进行数据交互；

接收来自所述被投屏设备发送的包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述投屏设备与所述被投屏设备之间的视频格式；

在所述被投屏设备中显示器处于所述横屏状态时，将所述投屏设备与所述被投屏设备所共同支持的最大屏幕分辨率按照横屏分辨率进行编码；在所述被投屏设备中显示器处于所述竖屏状态时，将所述投屏设备与所述被投屏设备所共同支持的最大屏幕分辨率按照竖屏分辨率进行编码；

将编码后的所述投屏数据反馈至所述被投屏设备，以使所述被投屏设备播放所述投屏数据。

与现有技术相比，本申请的有益效果为：

本申请提供了一种显示设备及投屏方法，当用户通过投屏设备向显示设备发送投屏信号时，显示设备响应于该投屏信号，投屏设备与显示设备均启动RTSP交互线程。显示设备根据固定组件所控制的显示器的状态设置屏幕状态标识，并在与投屏设备进行视频格式协商时间屏幕状态标识发送至投屏设备。投屏设备根据接收到的屏幕状态标识对投屏数据进行编码并发送至显示设备。显示设备在接收到投屏数据后于显示器上进行播放。本申请中，显示设备通过屏幕状态标识来记录当前显示器是处于横屏状态还是竖屏状态，投屏设备在RTSP交互过程获取当前显示设备中显示器所处的状态，并对投屏数据进行匹配编码，使得投屏数据适配于显示器的所处状态，保证投屏数据的分辨率清晰度，提高了用户体验。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

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

图2中示例性示出了根据一些实施例的控制装置100的硬件配置框图；

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

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

图5a中示例性示出了根据一些实施例的显示设备200横屏状态的效果示意图；

图5b中示例性示出了根据一些实施例的显示设备200竖屏状态的效果示意图；

图6中示例性示出了根据一些实施例的投屏数据被拉伸的显示效果示意图；

图7中示例性示出了根据一些实施例的投屏方法的流程示意图；

图8中示例性示出了根据一些实施例的另一投屏方法的流程示意图；

图9中示例性示出了根据一些实施例的投屏方法的时序图。

具体实施方式

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

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

本申请中说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”等是用于区别类似或同类的对象或实体，而不必然意味着限定特定的顺序或先后次序，除非另外注明。应该理解这样使用的用语在适当情况下可以互换。

术语“包括”和“具有”以及他们的任何变形，意图在于覆盖但不排他的包含，例如，包含了一系列组件的产品或设备不必限于清楚地列出的所有组件，而是可包括没有清楚地列出的或对于这些产品或设备固有的其它组件。

术语“模块”是指任何已知或后来开发的硬件、软件、固件、人工智能、模糊逻辑或硬件或/和软件代码的组合，能够执行与该元件相关的功能。

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

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

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

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

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

图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包括光接收器，用于采集环境光线强度的传感器；或者，检测器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 AccessMemory，RAM)，ROM(Read-Only Memory,ROM)，用于输入/输出的第一接口至第n接口，通信总线(Bus)等中的至少一种。

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

在一些实施例中，图形处理器，用于产生各种图形对象，如：图标、操作菜单、以及用户输入指令显示图形等。图形处理器包括运算器，通过接收用户输入各种交互指令进行运算，根据显示属性显示各种对象；还包括渲染器，对基于运算器得到的各种对象，进行渲染，上述渲染后的对象用于显示在显示器上。

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

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

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

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

在一些实施例中，“用户界面”，是应用程序或操作***与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面常用的表现形式是图形用户界面(Graphic User Interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的一个图标、窗口、控件等界面元素，其中控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

在一些实施例中，显示设备的***可以包括内核(Kernel)、命令解析器(shell)、文件***和应用程序。内核、shell和文件***一起组成了基本的操作***结构，它们让用户可以管理文件、运行程序并使用***。上电后，内核启动，激活内核空间，抽象硬件、初始化硬件参数等，运行并维护虚拟内存、调度器、信号及进程间通信(IPC)。内核启动后，再加载Shell和用户应用程序。应用程序在启动后被编译成机器码，形成一个进程。

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

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

框架层为应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层相当于一个处理中心，这个中心决定让应用层中的应用程序做出动作。应用程序通过API接口，可在执行中访问***中的资源和取得***的服务。

如图4所示，本申请实施例中应用程序框架层包括管理器(Managers)，内容提供者(Content Provider)等，其中管理器包括以下模块中的至少一个：活动管理器(ActivityManager)用与和***中正在运行的所有活动进行交互；位置管理器(Location Manager)用于给***服务或应用提供了***位置服务的访问；文件包管理器(Package Manager)用于检索当前安装在设备上的应用程序包相关的各种信息；通知管理器(NotificationManager)用于控制通知消息的显示和清除；窗口管理器(Window Manager)用于管理用户界面上的括图标、窗口、工具栏、壁纸和桌面部件。

在一些实施例中，活动管理器用于管理各个应用程序的生命周期以及通常的导航回退功能，比如控制应用程序的退出、打开、后退等。窗口管理器用于管理所有的窗口程序，比如获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕，控制显示窗口变化(例如将显示窗口缩小显示、抖动显示、扭曲变形显示等)等。

在一些实施例中，***运行库层为上层即框架层提供支撑，当框架层被使用时，安卓操作***会运行***运行库层中包含的C/C++库以实现框架层要实现的功能。

在一些实施例中，内核层是硬件和软件之间的层。如图4所示，内核层至少包含以下驱动中的至少一种：音频驱动、显示驱动、蓝牙驱动、摄像头驱动、WIFI驱动、USB驱动、HDMI驱动、传感器驱动(如指纹传感器，温度传感器，压力传感器等)、以及电源驱动等。

在一些实施例中的硬件或软件架构可以基于上述实施例中的介绍，在一些实施例中可以是基于相近的其他硬件或软件架构，可以实现本申请的技术方案即可。

在一些实施例中，显示设备200中的显示器260被配置显示用户界面、图像、文字、视频等，显示设备200中的控制器250用于向显示器260提供用户界面、图像、文字、视频等，控制器250可以控制固定组件，进而通过固定组件实现显示器260的旋转，以使显示设备200在横屏状态和竖屏状态之间转换。

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

基于上述显示设备200，用户可在显示设备200的应用程序中心内下载投屏应用，投屏应用可为基于Miracast(无线显示)功能的应用程序，Miracast利用WIFI点对点(Point2Point)网络传输功能把投屏设备的投屏数据传输到显示设备200进行播放，从而达到资源共享的目的，其中，投屏数据可以为音视频数据，投屏设备可为智能手机、平板电脑、计算机等终端设备。针对于上述显示器260可以旋转的显示设备200，在通过智能手机、平板电脑等竖屏投屏设备进行投屏时，若是投屏设备和显示设备200之间屏幕状态不一致，会导致显示设备200在进行投屏时出现投屏画面被拉伸缩放的现象，如图6所示，投屏数据被拉伸，使得用户体验效果不佳。

为解决上述问题，本申请在一些实施例中提供了一种显示设备及投屏方法。需要说明的是，本申请中的显示设备不仅指的是智能电视，还可以指的是计算机、平板电脑等。另外，上述显示设备200既可作为投屏端的投屏设备，又可作为被投屏端的展示设备。

下面结合附图，先通过被投屏端的显示设备来介绍本申请实施例提供的投屏过程。

图7中示例性示出了根据一些实施例的投屏方法的流程示意图。本申请在一些实施例中提供了一种显示设备，该显示设备为被投屏设备，用于展示来自投屏设备的投屏数据。该显示设备200包括显示器260和控制器250，所述控制器250与所述显示器260通信连接，所述控制器被配置为执行图7中的投屏过程。结合图7，该投屏过程如下：

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

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

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

在一些实施例中，Miracast在实现投屏功能时，需要利用WFD(Wi-Fi Display)交互协议来实现媒资共享。而WFD交互协议利用了RTSP(Real Time Streaming Protocol)协议来实现投屏设备和显示设备之间的能力协商。显示设备200和投屏设备在建立P2P网络连接后，各自启动RTSP交互线程，进行握手交互阶段，实现显示设备200与投屏设备之间的数据交互。

S702：向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述显示器所处的状态，所述RTSP消息用于协商所述显示设备与所述投屏设备之间的视频格式。

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

举例来说，视频格式的协商字段如下：

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

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

表1：

数据位	索引	说明
			0	0	640*480p60
1	1	720*480p60
			2	2	720*480i60
3	3	720*576p50
			4	4	720*576i50
5	5	1280*720p30
			6	6	1280*720p60
7	7	1920*1080p30
			8	8	1920*1080p60
9	9	1920*1080i60
			10	10	1280*720p25
11	11	1280*720p50
			12	12	1920*1080p25
13	13	1920*1080p50
			14	14	1920*1080i50
15	15	1280*720p24
			16	16	1920*1080p24
31:17	-	保留

在表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，此处也可以设置0代表竖屏状态，1代表横屏横屏状态，只要显示设备200和投屏设备两端协商定义统一即可，在此不做限定。

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

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

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

wfd_video_formats:00 01 01 02 800000A0 00000000 0000000 00 0000 000000none 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 000000none none。

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

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

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

为了进一步说明本申请中的投屏过程，本申请实施例还提供了一种显示设备，下面结合附图，通过投屏端显示设备来介绍本申请实施例提供的投屏过程。

图8中示例性示出了根据一些实施例的另一投屏方法的流程示意图。本申请在一些实施例中提供了一种显示设备，该显示设备为投屏设备，用于向被投屏设备发送投屏数据。该显示设备200包括显示器260和控制器250，所述控制器250与所述显示器260通信连接，所述控制器被配置为执行图8中的投屏过程。结合图8，该投屏过程如下：

S801：向所述被投屏设备发送投屏信号，启动RTSP交互线程，以使所述显示设备与所述被投屏设备进行数据交互。

在一些实施例中，显示设备200安装投屏应用，该投屏应用基于Miracast投屏功能。例如，在显示设备上设置有投屏控件，用户通过触控点击或者选中该投屏控件启动Miracast投屏功能。在启动Miracast投屏功能后，显示设备200向被投屏设备发送投屏信号，并启动自身的Miracast投屏功能，基于Miracast，两端设备各自启动RTSP交互线程，进行握手交互阶段，实现数据交互。

S802：接收来自所述被投屏设备发送的包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述显示设备与所述被投屏设备之间的视频格式。

在一些实施例中，被投屏设备在与显示设备200进行视频格式能力协商之前，先检查自身显示器所处的状态是横屏状态还是竖屏状态，并将显示器所处的状态通过屏幕状态标识标记于RTSP消息中。显示设备200在接收到该RTSP消息后，获取当前被投屏设备的显示器的状态，以及被投屏设备所支持的视频能力之后，择优选择分辨率及帧率。

S803：在所述显示器处于所述横屏状态时，将所述显示设备与所述被投屏设备所共同支持的最大屏幕分辨率按照横屏分辨率进行编码。

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

S804：在所述显示器处于所述竖屏状态时，将所述显示设备与所述被投屏设备所共同支持的最大屏幕分辨率按照竖屏分辨率进行编码。

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

S805：将编码后的所述投屏数据反馈至所述被投屏设备，以使所述被投屏设备播放所述投屏数据。

在一些实施例中，显示设备200将压缩后的投屏数据发送至被投屏设备，被投屏设备接收投屏数据，并控制显示器播放出该投屏数据。

下面通过附图进一步介绍上述投屏过程。

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

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

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

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

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

与上述投屏端显示设备相应的，本申请实施例还提供了一种投屏方法，所述方法包括：投屏设备向被投屏设备发送投屏信号，启动RTSP交互线程，以使投屏设备与所述被投屏设备进行数据交互。投屏设备接收来自所述被投屏设备发送的包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述投屏设备与所述被投屏设备之间的视频格式。在所述被投屏设备中显示器处于所述横屏状态时，投屏设备将所述投屏设备与所述被投屏设备所共同支持的最大屏幕分辨率按照横屏分辨率进行编码。在所述被投屏设备中显示器处于所述竖屏状态时，投屏设备将所述投屏设备与所述被投屏设备所共同支持的最大屏幕分辨率按照竖屏分辨率进行编码。投屏设备将编码后的所述投屏数据反馈至所述被投屏设备，以使所述被投屏设备播放所述投屏数据。

由于以上实施方式均是在其他方式之上引用结合进行说明，不同实施例之间均具有相同的部分，本说明书中各个实施例之间相同、相似的部分互相参见即可。在此不再详细阐述。

需要说明的是，在本说明书中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或暗示这些实体或操作之间存在任何这种实际的关系或顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的电路结构、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种电路结构、物品或者设备所固有的要素。在没有更多限制的情况下，有语句“包括一个……”限定的要素，并不排除在包括要素的电路结构、物品或者设备中还存在另外的相同要素。

本领域技术人员在考虑说明书及实践这里发明的公开后，将容易想到本申请的其他实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由权利要求的内容指出。

以上的本申请实施方式并不构成对本申请保护范围的限定。

Claims (10)

1.一种显示设备，所述显示设备用于展示来自所述投屏设备的投屏数据，其特征在于，所述显示设备包括：

显示器；

固定组件，所述固定组件用于旋转所述显示器以使所述显示器处于横屏状态或竖屏状态；

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

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

向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述显示器所处的状态，所述RTSP消息用于协商所述显示设备与所述投屏设备之间的视频格式；

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

2.根据权利要求1所述的显示设备，其特征在于，在所述向所述投屏设备发送包含屏幕状态标识的RTSP消息的步骤中，所述控制器还被配置为：

检测当前所述显示器所处的状态；

根据所述显示器所处的状态在视频格式协商字段中添加屏幕状态标识。

3.根据权利要求2所述的显示设备，其特征在于，在所述根据所述显示器所处的状态在视频编码能力协商字段中添加屏幕状态标识的步骤中，所述控制器还被配置为：

在所述显示器处于所述横屏状态时，控制所述视频格式协商字段中的任一保留的数据位标识为0；

在所述显示器处于所述竖屏状态时，控制所述视频格式协商字段中的任一保留的数据位标识为1。

4.根据权利要求3所述的显示设备，其特征在于，所述控制器还被配置为：

控制所述视频格式协商字段中最后一位数据位用于设置屏幕状态标识。

5.一种显示设备，所述显示设备用于向被投屏设备发送投屏数据，其特征在于，所述显示设备包括：

显示器；

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

向所述被投屏设备发送投屏信号，启动RTSP交互线程，以使所述显示设备与所述被投屏设备进行数据交互；

接收来自所述被投屏设备发送的包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述显示设备与所述被投屏设备之间的视频格式；

在所述显示器处于所述横屏状态时，将所述显示设备与所述被投屏设备所共同支持的最大屏幕分辨率按照横屏分辨率进行编码；在所述显示器处于所述竖屏状态时，将所述显示设备与所述被投屏设备所共同支持的最大屏幕分辨率按照竖屏分辨率进行编码；

将编码后的所述投屏数据反馈至所述被投屏设备，以使所述被投屏设备播放所述投屏数据。

6.根据权利要求5所述的显示设备，其特征在于，所述横屏分辨率为长乘宽分辨率；所述竖屏分辨率为宽乘长分辨率。

7.一种投屏方法，其特征在于，所述投屏方法包括：

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

向所述投屏设备发送包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述被投屏设备与所述投屏设备之间的视频格式；

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

8.根据权利要求7所述的投屏方法，其特征在于，在所述向所述投屏设备发送包含屏幕状态标识的RTSP消息中，所述方法还包括：

检测当前被投屏设备中显示器所处的状态；

根据显示器所处的状态在视频格式协商字段中添加屏幕状态标识。

9.根据权利要求8所述的投屏方法，其特征在于，在所述根据显示器所处的状态在视频编码能力协商字段中添加屏幕状态标识中，所述方法还包括：

在当前被投屏设备中显示器处于所述横屏状态时，控制所述视频格式协商字段中的任一保留的数据位标识为0；

在当前被投屏设备中显示器处于所述竖屏状态时，控制所述视频格式协商字段中的任一保留的数据位标识为1。

10.一种投屏方法，其特征在于，所述投屏方法包括：

向被投屏设备发送投屏信号，启动RTSP交互线程，以使投屏设备与所述被投屏设备进行数据交互；

接收来自所述被投屏设备发送的包含屏幕状态标识的RTSP消息，其中，所述屏幕状态标识用于指示所述被投屏设备中显示器所处的状态，所述被投屏设备中显示器处于横屏状态或竖屏状态，所述RTSP消息用于协商所述投屏设备与所述被投屏设备之间的视频格式；

在所述被投屏设备中显示器处于所述横屏状态时，将所述投屏设备与所述被投屏设备所共同支持的最大屏幕分辨率按照横屏分辨率进行编码；在所述被投屏设备中显示器处于所述竖屏状态时，将所述投屏设备与所述被投屏设备所共同支持的最大屏幕分辨率按照竖屏分辨率进行编码；

将编码后的所述投屏数据反馈至所述被投屏设备，以使所述被投屏设备播放所述投屏数据。

Images