CN113992963A - 一种显示设备及投屏方法 - Google Patents

Abstract

本申请提供了一种显示设备及投屏方法，当第一移动终端向显示设备发送第一投屏请求时，通过第一投屏协议应用对该投屏请求进行响应及处理，并建立投屏连接，在接收到第一待投屏内容时，不通过第一投屏协议应用创建播放窗口进行播放，而是通过第一投屏协议应用将第一待投屏内容发送给播放应用，由播放应用创建第一播放窗口进行播放。当存在通过另一投屏协议发送过来的投屏请求时，对应的协议应用对该投屏请求进行响应，这种情况下播放应用仍会继续运行，不会影响第一播放窗口对第一待投屏内容的播放。如此，可以在显示设备上实现同时播放通过多个投屏协议发送过来的待投屏内容。

Description

一种显示设备及投屏方法

技术领域

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

背景技术

投屏能够将移动终端上播放的画面同步到另一个显示设备上播放，待投屏的内容一般分为两类，一类是移动终端上第三方媒体资源的媒体数据，另一类是移动终端的屏幕实时画面。针对不同类型的待投屏内容，移动终端需要依据不同的投屏协议向显示设备发送投屏请求以及传输待投屏内容。

针对每种投屏协议，显示设备中都对应有独立的协议应用，当接收到移动终端利用某一投屏协议发送过来的投屏请求时，对应的协议应用响应该投屏请求，并进行命令协商，协商完成后，移动终端传输待投屏内容，协议应用基于收到的待投屏内容进行播放。

当显示设备正在播放一个移动终端的投屏内容时，若接收到另一移动终端利用别的投屏协议发送过来的投屏请求，那么另一种协议应用则会响应该请求，当前的投屏应用将停止播放。

发明内容

本申请提供了一种显示设备及投屏方法，以解决现有的投屏方法无法在一个显示设备上同时对通过多个投屏协议发送过来的内容进行投屏播放的问题。

第一方面，本申请提供了一种显示设备，包括：

显示器，被配置为显示用户界面；

控制器，可运行一个播放应用和至少一个投屏协议应用，所述至少一个投屏协议应用均可连接至所述播放应用，被配置为：

在接收到第一移动终端发送的第一投屏请求时，通过与所述第一投屏请求相对应的第一投屏协议应用，建立与所述第一移动终端之间的投屏连接，以及将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用；

通过所述播放应用，在所述用户界面上创建第一播放窗口，所述第一播放窗口用于播放所述第一待投屏内容。

本申请一些实施例中，所述控制器还被配置为：

在接收到第二移动终端发送的第二投屏请求时，通过与所述第二投屏请求相对应的第二投屏协议应用，建立与所述第二移动终端之间的投屏连接，以及将所述第二移动终端通过投屏连接传输过来的第二待投屏内容发送至播放应用；其中，所述第一投屏协议应用和所述第二投屏协议应用为同一个投屏协议应用，或者为两个不同的投屏协议应用；

通过所述播放应用，在所述用户界面上创建第二播放窗口，所述第二播放窗口用于播放所述第二待投屏内容，所述第二播放窗口与所述第一播放窗口为互相独立的播放窗口。

第二方面，本申请还提供了一种投屏方法，应用于显示设备，所述方法包括：

在接收到第一移动终端发送的第一投屏请求时，通过与所述第一投屏请求相对应的第一投屏协议应用，建立与所述第一移动终端之间的投屏连接，以及将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用；

通过所述播放应用，在显示器显示的用户界面上创建第一播放窗口，所述第一播放窗口用于播放所述第一待投屏内容。

本申请一些实施例中，所述方法还包括：

在接收到第二移动终端发送的第二投屏请求时，通过与所述第二投屏请求相对应的第二投屏协议应用，建立与所述第二移动终端之间的投屏连接，以及将所述第二移动终端通过投屏连接传输过来的第二待投屏内容发送至播放应用；其中，所述第一投屏协议应用和所述第二投屏协议应用为同一个投屏协议应用，或者为两个不同的投屏协议应用；

通过所述播放应用，在所述用户界面上创建第二播放窗口，所述第二播放窗口用于播放所述第二待投屏内容，所述第二播放窗口与所述第一播放窗口为互相独立的播放窗口。

由以上技术方案可知，本申请提供的一种显示设备及投屏方法，在控制器中独立开发了一个播放应用，当第一移动终端向显示设备发送第一投屏请求时，由控制器接收该投屏请求。通过与所述第一投屏请求相对应的第一投屏协议应用，对该投屏请求进行响应及处理，并建立投屏连接，在接收到第一移动终端通过投屏连接传输过来的第一待投屏内容，将第一待投屏内容发送给播放应用，由播放应用创建第一播放窗口进行播放。当存在通过另一投屏协议发送过来的投屏请求时，对应的投屏协议应用进行响应，此时播放应用仍会继续运行，因而第一播放窗口不会受到影响，将继续对第一待投屏内容进行播放。如此，可以在显示设备上实现同时播放通过多个投屏协议发送过来的待投屏内容。

附图说明

图1为本申请实施例中提供的一种投屏系统的架构示意图；

图2示出了根据一些实施例的移动终端100的硬件配置框图；

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

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

图5示出了根据一些实施例的显示设备200中应用程序的图标控件界面显示图；

图6示出了根据一些实施例的显示设备中控制器的配置图；

图7示出了根据一些实施例的显示设备中控制器执行投屏方法的一种流程示意图；

图8示出了根据一些实施例的显示设备中控制器执行投屏方法的另一种流程示意图；

图9示出了根据一些实施例的显示设备中显示器上播放窗口的示意图；

图10示出了根据一些实施例的多个移动终端与显示设备之间投屏交互的结构示意图；

图11示出了根据一些实施例的第一移动终端与显示设备之间投屏交互的时序图。

具体实施方式

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

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

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

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

本申请实施方式提供的显示设备可以具有多种实施形式，例如，可以是电视、智能电视、激光投影设备、显示器(monitor)、电子白板(electronic bulletin board)、电子桌面(electronic table)等。

参照图1，图1为本申请实施例中提供的一种投屏系统的架构示意图。该投屏系统包括移动终端100与显示设备200。移动终端100与显示设备200均连接于同一局域网内。

可以理解，图1中所示的硬件设备，仅仅是与本申请方案应用环境相关的部分硬件设备，并不构成对本申请方案所应用于的环境的限定，具体的硬件设备可以包括比图1中所示更多或更少的硬件设备。比如，当移动终端100与显示设备200接入相同的无线局域网时，图1中还包括该无线局域网中的路由设备等。

移动终端100，可以是台式终端或移动终端，例如手机、平板电脑、笔记本电脑、游戏机等中的至少一种。

显示设备200，可以液晶显示器、OLED显示器、投影显示设备等。具体显示设备类型，尺寸大小和分辨率等不作限定，本领技术人员可以理解的是，显示设备200可以根据需要做性能和配置上一些改变。

在一些实施例中，移动终端100可与显示设备200安装软件应用，通过网络通信协议实现连接通信，实现一对一控制操作的和数据通信的目的。如：可以实现用移动终端100与显示设备200建立控制指令协议，将移动终端100上显示音视频内容传输到显示设备200上，实现投屏功能。例如，显示设备200可以通过局域网(LAN)、无线局域网(WLAN)等与移动终端100进行通信。

显示设备200除了提供广播接收电视功能之外，还可以附加提供计算机支持功能的智能网络电视功能，包括但不限于，网络电视、智能电视、互联网协议电视(IPTV)等。

图2示出了根据一些实施例的移动终端100的硬件配置框图。如图2所示，移动终端100包括控制器110、通信接口130、用户输入/输出接口140、存储器、供电电源。移动终端100可接收用户的输入操作指令，且将操作指令转换为显示设备200可识别和响应的指令，起到用户与显示设备200之间交互中介作用。如：用户可以将移动终端100显示的内容投屏到显示设备200上显示。

控制器110用于控制移动终端100的运行和操作，以及内部各部件之间通信协作以及外部和内部的数据处理功能。

在一些实施例中，通信接口130用于和外部通信，包含WIFI芯片，蓝牙模块，NFC或可替代模块中的至少一种。通信接口130在控制器110的控制下，实现与显示设备200之间控制信号和数据信号的通信。如：将接收到的用户输入信号发送至显示设备200上。

在一些实施例中，用户输入/输出接口140包含麦克风，触摸板，传感器，按键或可替代模块中的至少一种。用户可以通过语音、触摸、手势、按压等动作实现用户指令输入功能，输入接口通过将接收的模拟信号转换为数字信号，以及数字信号转换为相应指令信号，发送至显示设备200。输出接口包括将接收的用户指令发送至显示设备200的接口，在一些实施例中，可以为红外接口，也可以是射频接口。如：红外信号接口时，需要将用户输入指令按照红外控制协议转化为红外控制信号，经红外发送模块进行发送至显示设备200。如：射频信号接口时，需将用户输入指令转化为数字信号，然后按照射频控制信号调制协议进行调制后，由射频发送端子发送至显示设备200。

存储器，用于在控制器110的控制下存储驱动和控制移动终端100的各种运行程序、数据和应用。存储器可以存储用户输入的各类控制信号指令。

供电电源，用于在控制器110的控制下为移动终端100各元件提供运行电力支持。可以为电池及相关控制电路。

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

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

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

显示器260可为液晶显示器、OLED显示器、以及投影显示器中的至少一种，还可以为一种投影装置和投影屏幕。

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

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

检测器230用于采集外部环境或与外部交互的信号。例如，检测器230包括光接收器，用于采集环境光线强度的传感器；或者，检测器230包括图像采集器，如摄像头，可以用于采集外部环境场景、用户的属性或用户交互手势，再或者，检测器230包括声音采集器，如麦克风等，用于接收外部声音。

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

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

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

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

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

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

在一些实施例中，用户接口，为可用于接收控制输入的接口(如：显示设备本体上的实体按键，或其他等)。

图4示出了根据一些实施例的显示设备200中软件配置图。参见图4，在一些实施例中，将系统分为四层，从上至下分别为应用程序(Applications)层(简称“应用层”)，应用程序框架(Application Framework)层(简称“框架层”)，安卓运行时(Android runtime)和系统库层(简称“系统运行库层”)，以及内核层。

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

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

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

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

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

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

图5示出了根据一些实施例的显示设备200中应用程序的图标控件界面显示图。在一些实施例中，显示设备启动后可以直接进入预置的视频点播程序的界面，视频点播程序的界面可以如图5中所示，至少包括导航栏510和位于导航栏510下方的内容显示区，内容显示区中显示的内容会随导航栏中被选中控件的变化而变化。应用程序层中的程序可以被集成在视频点播程序中通过导航栏的一个控件进行展示，也可以在导航栏中的应用控件被选中后进行进一步显示。

在一些实施例中，显示设备启动后可以直接进入上次选择的信号源的显示界面，或者信号源选择界面，其中信号源可以是预置的视频点播程序，还可以是HDMI接口，直播电视接口等中的至少一种，用户选择不同的信号源后，显示器可以显示从不同信号源获得的内容。

随着移动互联网技术的发展，手机、平板电脑等移动终端的功能越来越丰富，越来越多的用户使用移动终端观看视频、浏览文件等。但是，由于手机、平板电脑等移动终端的屏幕尺寸较小，而电视机、台式显示器等显示设备的屏幕尺寸较大，很多用户还是喜欢在这类显示设备上观看视频、浏览文件。

以电视机为例，当用户希望在电视机上观看移动终端中播放的视频时，可以使用移动终端的投屏功能，与电视机建立投屏连接，从而实现在移动终端和电视机上同步观看该视频。一些实施例中，在进行投屏时，先开启移动终端中的投屏应用，移动终端中的投屏应用在启动之后，在移动终端当前接入的局域网内自动搜索可以进行投屏的显示设备，然后在移动终端的显示界面以列表的方式展示各个可以投屏的显示设备的设备名称。用户根据实际投屏需要，在移动终端的显示界面中选择点击需要投屏的显示设备的设备名称后，移动终端即可与用户点击选择的显示设备建立投屏连接。

在移动终端与显示设备连接投屏连接之后，移动终端便可以将移动终端上显示的数据发送到该显示设备上，实现在该显示设备上观看移动终端中的视频。但是，相关技术中的投屏方法，无法在一个显示设备上同时对通过多个投屏协议发送过来的内容进行投屏播放。

为了解决这一技术问题，本申请实施例提供的一种显示设备，包括：显示器及控制器，其中，显示器被配置为显示用户界面。控制器中可运行一个播放应用和至少一个投屏协议应用，所述至少一个投屏协议应用均可连接至所述播放应用，每个投屏协议应用均能够独立与播放应用进行数据通信。

每个投屏协议应用均采用不同的投屏协议，作为示例，现有的投屏协议包括：DLNA投屏协议、Miracast投屏协议、Airplay投屏协议以及其它投屏协议。基于移动终端待投屏内容的两种类型(一类是移动终端上第三方媒体资源的媒体数据，另一类是移动终端的屏幕实时画面)，DLNA投屏协议能够支持移动终端上第三方媒体资源的媒体数据的推送投屏；Miracast投屏协议能够支持移动终端的屏幕实时画面的镜像投屏；Airplay投屏协议既能够支持移动终端上第三方媒体资源的媒体数据的推送投屏，也能够支持移动终端的屏幕实时画面的镜像投屏；其它投屏协议可以是各显示设备生产厂家自开发的协议。

一些实施例中，可以针对现有的每一种投屏协议，在控制器中独立开发一个投屏协议应用。示例性的，参见图6，针对DLNA投屏协议，开发一个DLNA投屏协议应用；针对Miracast投屏协议，开发一个Miracast投屏协议应用；针对Airplay投屏协议，开发一个Airplay投屏协议应用；针对其它投屏协议，开发相应的其它投屏协议应用。

每种投屏协议应用均以后台服务形式存在，且都可以独立与播放应用之间进行数据通信。播放应用为一个独立的播放器应用，不负责与移动终端之间的协议交互，只负责接收并播放各种投屏协议的媒体数据。

参见图7所示的工作流程示意图，为了解决相关技术中投屏方法无法在一个显示设备上同时对多个移动终端上的显示数据进行投屏播放的问题，本实施例中的控制器被配置为执行下述步骤：

步骤701，在接收到第一移动终端发送的第一投屏请求时，通过与所述第一投屏请求相对应的第一投屏协议应用，建立与所述第一移动终端之间的投屏连接，以及将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用。

步骤702，通过所述播放应用，在所述用户界面上创建第一播放窗口，所述第一播放窗口用于播放所述第一待投屏内容。

第一移动终端可以是唯一一个与显示设备进行投屏连接的移动终端，也可以是多个与显示设备进行投屏连接的移动终端中的任一个。第一投屏请求可以是第一移动终端通过任意投屏协议发送至显示设备的投屏请求。第一投屏协议应用为与所述第一投屏请求采用相同投屏协议的投屏协议应用，第一播放窗口可以是播放应用创建的唯一一个播放窗口，也可以是播放应用创建的多个播放窗口中的任一个。

当第一移动终端向显示设备发送第一投屏请求时，由控制器接收该投屏请求。通过第一投屏协议应用，对该投屏请求进行响应及处理，并建立投屏连接，在接收到第一移动终端通过投屏连接传输过来的第一待投屏内容，不通过第一投屏协议应用创建播放窗口进行播放，而是通过第一投屏协议应用将第一待投屏内容发送给播放应用，由播放应用创建一个播放窗口(即第一播放窗口)进行播放。当存在通过另一投屏协议发送过来的投屏请求时，对应的投屏协议应用对该投屏请求进行响应，此时播放应用仍会继续运行，因而第一播放窗口不会受到影响，将继续对第一待投屏内容进行播放。

投屏协议应用只负责与移动终端的协议交互，不负责投屏内容的播放，播放应用只负责创建相应的播放窗口对接收到的投屏内容进行播放，不负责与移动终端的协议交互。当存在多个移动终端通过多种投屏协议向显示设备发送多个投屏请求时，控制器可以通过多个投屏协议应用各自独立与多个移动终端进行协议交互，建立投屏连接，然后向播放应用转发待投屏内容，播放应用只要接收到一个待投屏内容，便创建一个播放窗口进行播放，若同时或陆续接收到多个待投屏内容，便相应创建多个独立的播放窗口进行播放，如此，便可实现在同一显示设备上同时对通过多种投屏协议发送过来的待投屏内容进行播放。

结合图8，进一步对上述方案如何在一个显示设备上同时播放通过多个投屏协议发送过来的内容进行解释说明。当显示设备正在播放第一移动终端的投屏内容时，若又接收到一个投屏请求，为了防止当前投屏内容的播放被终止，控制器被进一步配置为执行下述步骤：

步骤801，在接收到第二移动终端发送的第二投屏请求时，通过与所述第二投屏请求相对应的第二投屏协议应用，建立与所述第二移动终端之间的投屏连接，以及将所述第二移动终端通过投屏连接传输过来的第二待投屏内容发送至播放应用。

需要说明的是，第二移动终端与第一移动终端可以为同一个移动终端，也可以为两个不同的移动终端，第二投屏协议应用为与所述第二投屏请求采用相同投屏协议的投屏协议应用，第一投屏请求和第二投屏请求是用户基于两种不同的待投屏内容所发出的两个不同投屏请求，这两个投屏请求可以采用同一种投屏协议发出，也可以采用不同的投屏协议发出。如果这两个投屏请求采用同一种投屏协议发出，那么第一投屏协议应用和第二投屏协议应用为同一个投屏协议应用，如果这两个投屏请求采用不同的投屏协议发出，那么第一投屏协议应用和第二投屏协议应用为两个不同的投屏协议应用。

步骤802，通过所述播放应用，在所述用户界面上创建第二播放窗口，所述第二播放窗口用于播放所述第二待投屏内容。

参见图9，所述第二播放窗口与所述第一播放窗口为互相独立的播放窗口，能够同时存在于显示器上，且这两个播放窗口可以存在部分重叠，或者不存在任何重叠。

在一些实施例中，播放应用可以适应性的设置第一播放窗口和第二播放窗口的大小和位置，使得这两个播放窗口均能完整的显示在显示器上。或者，播放应用可以根据用户的偏好设置，调整第一播放窗口和第二播放窗口的大小及位置。

基于上述流程，本领域技术人员可以毫无疑义的获知，当显示设备接收到更多的投屏请求时，如何对多个待投屏内容同时进行播放，在此不再赘述。

移动终端待投屏内容通常分为两种类型：一类是移动终端上第三方媒体资源的媒体数据，另一类是移动终端的屏幕实时画面。

基于这两种类型，控制器中的投屏协议应用需要通过不同的方法，将待投屏内容转发至播放应用，接下来将详细说明。为了便于理解，下述内容仅针对第一移动终端进行说明，但毫无疑义的是，针对任何发出投屏请求的移动终端，都可以使用同样的原理实现。

在一些实施例中，在将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用之前，所述控制器还被配置为：

通过所述第一投屏协议应用，获取所述第一待投屏内容；其中，若所述第一待投屏内容属于第三方媒体资源的媒体数据，则所述第一待投屏内容为目标网页链接地址，若所述第一待投屏内容属于屏幕实时画面，则所述第一待投屏内容为所述第一移动终端的屏幕视频流。

在接收到第一投屏请求时，第一投屏协议应用响应，与发出第一投屏请求的投屏投屏应用进行协议的命令协商，协商完成后，第一投屏协议应用获取第一移动终端发送过来的第一待投屏内容。

针对第三方媒体资源的媒体数据，第一移动终端发送给第一投屏协议应用的是一个第三方媒体资源的网页链接地址，该网页链接地址为第一待投屏内容对应的URL(Uniform Resource Locator,统一资源定位器)地址，本实施例称为目标网页链接地址，通常情况下是一个http类型的片源地址。针对屏幕实时画面，第一移动终端发送给第一投屏协议应用的是屏幕实时画面的视频流。

在一些实施例中，若第一投屏协议应用接收到的第一待投屏内容为目标网页链接地址，可以通过Android的广播方式或者其余进程间的通信方式，将目标网页链接地址发送至播放应用。

播放应用在接收到目标网页链接地址之后，创建第一播放窗口，并连接目标链接地址，然后在所述第一播放窗口中播放从所述目标链接地址获取的视频内容。

作为示例，若第一移动终端中的投屏应用通过DLNA投屏协议向显示设备发送第一投屏请求，显示设备控制器中的DLNA投屏协议应用进行响应，与投屏应用进行协议的命令协商，协商完成后建立投屏连接，若投屏应用通过投屏连接发送过来的待投屏内容为某个第三方视频软件中某个片源的URL地址，则DLNA投屏协议应用将接收到的URL地址通过android的广播或其它进程间通信方式，通知给播放应用，播放应用在接收到URL地址后，创建一个播放窗口(或播放控件)对该URL地址对应的片源进行播放。

在一些实施例中，若第一投屏协议应用接收到的第一待投屏内容为第一移动终端的屏幕视频流，可以通过共享内存的方式，将第一待投屏内容发送至播放应用。具体的，所述控制器被配置为：

通过所述第一投屏协议应用，创建第一共享内存，所述第一共享内存具有唯一的索引名称。

通过所述第一投屏协议应用，将所述第一移动终端的屏幕视频流实时存入所述第一共享内存中，并向所述播放应用发出第一读取指令，所述第一读取指令包括所述第一共享内存的索引名称。

在接收到第一读取指令时，基于唯一的索引名称，播放应用能够从第一共享内存中实时读取屏幕视频流，并在所述第一播放窗口中播放从所述第一共享内存中实时读取的屏幕视频流。

作为示例，若第一移动终端中的投屏应用通过Miracast投屏协议向显示设备发送第一投屏请求，显示设备控制器中的Miracast投屏协议应用进行响应，与投屏应用进行协议的命令协商，协商完成后，Miracast投屏协议应用创建一个共享内存，即第一共享内存，并为第一共享内存进行命名，然后把第一共享内存的名字通过android的广播或其它进程间的通信方式，通知给播放应用，同时，Miracast投屏协议应用接收从第一移动终端中通过其它数据传输协议实时传输过来的屏幕视频流，写入到第一共享内存中，播放应用创建一个播放窗口，从第一共享内存中读取实时的屏幕视频流进行播放。

在一些实施例中，若第一投屏协议应用接收到的第一待投屏内容为第一移动终端的屏幕视频流，除了共享内存的方式，也可以通过其余的进程间通信方式，将第一待投屏内容发送至播放应用。进程间通信方式可以为命名管道或者套接字socket等通信方式。

当第一移动终端中的投屏应用停止投屏操作时，通过投屏协议，通知显示设备控制器中的第一投屏协议应用，第一投屏协议应用再通知播放应用停止播放。

在一些实施例中，如果第一待投屏内容是第一移动终端的屏幕实时画面，则在停止播放后，第一投屏协议应用可以删除创建的第一共享内存。

以下结合具体示例，对本申请提供的投屏方法进行说明。假设存在四个移动终端向显示设备发出了投屏请求，假设第一个移动终端通过DLNA投屏协议向显示设备推送视频软件A的某个片源，第二个移动终端通过DLNA投屏协议向显示设备推送视频软件B的某个片源，第三个移动终端通过miracast投屏协议向显示设备推送自身的屏幕画面，第四个移动终端通过airplay投屏协议向显示设备推送自身的屏幕画面。显示设备控制器中各协议应用：DLNA协议应用，miracast协议应用，airplay协议应用分别对这四个投屏请求进行响应。结合图10，这四个移动终端分别与显示设备之间的交互过程见如下：

(1)第一个移动终端通过DLNA投屏协议向显示设备推送视频软件A的某个片源，DLNA投屏协议应用接收到投屏请求，与第一个移动终端进行标准DLNA协议的交互，交互完成后，接收到视频软件A某个片源的URL地址，DLNA投屏协议应用启动播放应用，并把该URL地址通过进程通信方式传输给播放应用，播放应用创建播放控件player1(在显示器用户界面上的表现形式为一个播放窗口)，并连接该URL地址进行视频播放。

(2)第二个移动终端通过DLNA投屏协议向显示设备推送视频软件B的某个片源，DLNA投屏协议应用接收到投屏请求，与第二个移动终端进行标准DLNA协议的交互，交互完成后，接收到视频软件B某个片源的URL地址，DLNA投屏协议应用启动播放应用，并把该URL地址通过进程通信方式传输给播放应用，播放应用创建播放窗口player2(在显示器用户界面上的表现形式为第二个播放窗口)，并连接该URL地址进行视频播放。

(2)第三个移动终端通过miracast投屏协议向显示设备推送自身的屏幕画面，miracast投屏协议应用接收到该投屏请求，进行miracast连接的命令协商，协商完成后进行屏幕画面数据的传输，miracast投屏协议应用创建一个共享内存，命名为miracast_sharememry1，同时通知播放应用从共享内存miracast_sharememry1中实时读取视频流，同时播放应用在显示器界面的合适位置创建播放窗口player3(在显示器用户界面上的表现形式为第三个播放窗口)对视频流进行播放。

(4)第四个移动终端通过airplay投屏协议向显示设备推送自身的屏幕画面，airplay投屏协议应用接收到该投屏请求，进行airplay连接的命令协商，协商完成后进行屏幕画面数据的传输，airplay投屏协议应用创建一个共享内存，命名为airplay_sharememry1，同时通知播放应用从共享内存airplay_sharememry1中实时读取视频流，同时播放应用在显示器界面的合适位置创建播放窗口player4(在显示器用户界面上的表现形式为第四个播放窗口)对视频流进行播放。

本申请实施例提供的显示设备，控制器中独立开发了一个播放应用，当存在多个移动终端通过多种投屏协议向显示设备发送多个投屏请求时，控制器可以通过多个投屏协议应用各自独立与多个移动终端进行协议交互，建立投屏连接，然后向播放应用转发待投屏内容，播放应用只要接收到一个待投屏内容，便创建一个播放窗口进行播放，若同时或陆续接收到多个待投屏内容，便相应创建多个独立的播放窗口进行播放，如此，便可实现在同一显示设备上同时对通过多种投屏协议发送过来的待投屏内容进行播放。

在一些实施例中，本申请公开了一种投屏方法，图11为移动终端与显示设备之间的多端交互流程图，结合图11，该投屏方法包括：

步骤1101，第一移动终端发送第一投屏请求。

步骤1102，第一投屏协议应用响应第一投屏请求，并建立与所述第一移动终端之间的投屏连接，所述第一投屏协议应用为与所述第一投屏请求采用相同投屏协议的协议应用。

步骤1103，第一移动终端通过所述投屏连接向所述第一投屏协议应用发送第一待投屏内容。

步骤1104，第一投屏协议应用将所述第一待投屏内容发送至播放应用。

步骤1105，播放应用在显示器显示的用户界面上创建第一播放窗口，所述第一播放窗口用于播放所述第一待投屏内容。

上述投屏方法，当第一移动终端向显示设备发送第一投屏请求时，由控制器接收该投屏请求。通过第一投屏协议应用，对该投屏请求进行响应及处理，并建立投屏连接，在接收到第一移动终端通过投屏连接传输过来的第一待投屏内容，不通过第一投屏协议应用创建播放窗口进行播放，而是通过第一投屏协议应用将第一待投屏内容发送给播放应用，由播放应用创建一个播放窗口(即第一播放窗口)进行播放。当存在通过另一投屏协议发送过来的投屏请求时，对应的投屏协议应用对该投屏请求进行响应，此时播放应用仍会继续运行，因而第一播放窗口不会受到影响，将继续对第一待投屏内容进行播放。如此，可以在显示设备上实现同时播放通过多个投屏协议发送过来的待投屏内容。

在一些实施例中，本申请还公开了一种投屏方法，该投屏方法应用于显示设备，所述方法包括：

在接收到第一移动终端发送的第一投屏请求时，通过与所述第一投屏请求相对应的第一投屏协议应用，建立与所述第一移动终端之间的投屏连接，以及将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用；

通过所述播放应用，在显示器显示的用户界面上创建第一播放窗口，所述第一播放窗口用于播放所述第一待投屏内容。

当存在通过另一投屏协议发送过来的投屏请求时，所述投屏方法还包括：

在接收到第二移动终端发送的第二投屏请求时，通过与所述第二投屏请求相对应的第二投屏协议应用，建立与所述第二移动终端之间的投屏连接，以及将所述第二移动终端通过投屏连接传输过来的第二待投屏内容发送至播放应用；其中，所述第一投屏协议应用和所述第二投屏协议应用为同一个投屏协议应用，或者为两个不同的投屏协议应用；通过所述播放应用，在所述用户界面上创建第二播放窗口，所述第二播放窗口用于播放所述第二待投屏内容，所述第二播放窗口与所述第一播放窗口为互相独立的播放窗口。

其中，在将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用之前，所述投屏方法还包括：通过所述第一投屏协议应用，获取所述第一待投屏内容；其中，若所述第一待投屏内容属于第三方媒体资源的媒体数据，则所述第一待投屏内容为目标网页链接地址，若所述第一待投屏内容属于屏幕实时画面，则所述第一待投屏内容为所述第一移动终端的屏幕视频流。

若所述第一待投屏内容为目标网页链接地址，则在所述用户界面上创建第一播放窗口之后，所述投屏方法还包括：通过所述播放应用，在所述第一播放窗口中播放从所述目标链接地址获取的视频内容。

若所述第一待投屏内容为所述第一移动终端的屏幕视频流，则在将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用时，所述投屏方法还包括：通过所述第一投屏协议应用，创建第一共享内存，所述第一共享内存具有唯一的索引名称；通过第一投屏协议应用，将所述第一移动终端的屏幕视频流实时存入所述第一共享内存中，并向所述播放应用发出第一读取指令，所述第一读取指令包括所述第一共享内存的索引名称。

若所述第一待投屏内容为所述第一移动终端的屏幕视频流，则在所述用户界面上创建第一播放窗口之后，所述投屏方法还包括：通过所述播放应用，在所述第一播放窗口中播放从所述第一共享内存中实时读取的屏幕视频流。

以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

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

Claims (12)

1.一种显示设备，其特征在于，包括：

显示器，被配置为显示用户界面；

控制器，可运行一个播放应用和至少一个投屏协议应用，所述至少一个投屏协议应用均可连接至所述播放应用，被配置为：

在接收到第一移动终端发送的第一投屏请求时，通过与所述第一投屏请求相对应的第一投屏协议应用，建立与所述第一移动终端之间的投屏连接，以及将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用；

通过所述播放应用，在所述用户界面上创建第一播放窗口，所述第一播放窗口用于播放所述第一待投屏内容。

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

在接收到第二移动终端发送的第二投屏请求时，通过与所述第二投屏请求相对应的第二投屏协议应用，建立与所述第二移动终端之间的投屏连接，以及将所述第二移动终端通过投屏连接传输过来的第二待投屏内容发送至播放应用；其中，所述第一投屏协议应用和所述第二投屏协议应用为同一个投屏协议应用，或者为两个不同的投屏协议应用；

通过所述播放应用，在所述用户界面上创建第二播放窗口，所述第二播放窗口用于播放所述第二待投屏内容，所述第二播放窗口与所述第一播放窗口为互相独立的播放窗口。

3.根据权利要求1所述的显示设备，其特征在于，在将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用之前，所述控制器还被配置为：

通过所述第一投屏协议应用，获取所述第一待投屏内容；其中，若所述第一待投屏内容属于第三方媒体资源的媒体数据，则所述第一待投屏内容为目标网页链接地址，若所述第一待投屏内容属于屏幕实时画面，则所述第一待投屏内容为所述第一移动终端的屏幕视频流。

4.根据权利要求3所述的显示设备，其特征在于，若所述第一待投屏内容为目标网页链接地址，则在所述用户界面上创建第一播放窗口之后，所述控制器还被配置为：

通过所述播放应用，在所述第一播放窗口中播放从所述目标链接地址获取的视频内容。

5.根据权利要求3所述的显示设备，其特征在于，若所述第一待投屏内容为所述第一移动终端的屏幕视频流，则在将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用时，所述控制器还被配置为：

通过所述第一投屏协议应用，创建第一共享内存，所述第一共享内存具有唯一的索引名称；

通过所述第一投屏协议应用，将所述第一移动终端的屏幕视频流实时存入所述第一共享内存中，并向所述播放应用发出第一读取指令，所述第一读取指令包括所述第一共享内存的索引名称。

6.根据权利要求5所述的显示设备，其特征在于，若所述第一待投屏内容为所述第一移动终端的屏幕视频流，则在所述用户界面上创建第一播放窗口之后，所述控制器还被配置为：

通过所述播放应用，在所述第一播放窗口中播放从所述第一共享内存中实时读取的屏幕视频流。

7.一种投屏方法，其特征在于，应用于显示设备，所述方法包括：

在接收到第一移动终端发送的第一投屏请求时，通过与所述第一投屏请求相对应的第一投屏协议应用，建立与所述第一移动终端之间的投屏连接，以及将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用；

通过所述播放应用，在显示器显示的用户界面上创建第一播放窗口，所述第一播放窗口用于播放所述第一待投屏内容。

8.根据权利要求7所述的投屏方法，其特征在于，所述方法还包括：

在接收到第二移动终端发送的第二投屏请求时，通过与所述第二投屏请求相对应的第二投屏协议应用，建立与所述第二移动终端之间的投屏连接，以及将所述第二移动终端通过投屏连接传输过来的第二待投屏内容发送至播放应用；其中，所述第一投屏协议应用和所述第二投屏协议应用为同一个投屏协议应用，或者为两个不同的投屏协议应用；

通过所述播放应用，在所述用户界面上创建第二播放窗口，所述第二播放窗口用于播放所述第二待投屏内容，所述第二播放窗口与所述第一播放窗口为互相独立的播放窗口。

9.根据权利要求7所述的投屏方法，其特征在于，在将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用之前，所述方法还包括：

通过所述第一投屏协议应用，获取所述第一待投屏内容；其中，若所述第一待投屏内容属于第三方媒体资源的媒体数据，则所述第一待投屏内容为目标网页链接地址，若所述第一待投屏内容属于屏幕实时画面，则所述第一待投屏内容为所述第一移动终端的屏幕视频流。

10.根据权利要求9所述的投屏方法，其特征在于，若所述第一待投屏内容为目标网页链接地址，则在所述用户界面上创建第一播放窗口之后，所述方法还包括：

通过所述播放应用，在所述第一播放窗口中播放从所述目标链接地址获取的视频内容。

11.根据权利要求9所述的投屏方法，其特征在于，若所述第一待投屏内容为所述第一移动终端的屏幕视频流，则在将所述第一移动终端通过投屏连接传输过来的第一待投屏内容发送至播放应用时，所述方法还包括：

通过所述第一投屏协议应用，创建第一共享内存，所述第一共享内存具有唯一的索引名称；

通过所述第一投屏协议应用，将所述第一移动终端的屏幕视频流实时存入所述第一共享内存中，并向所述播放应用发出第一读取指令，所述第一读取指令包括所述第一共享内存的索引名称。

12.根据权利要求11所述的投屏方法，其特征在于，若所述第一待投屏内容为所述第一移动终端的屏幕视频流，则在所述用户界面上创建第一播放窗口之后，所述方法还包括：

通过所述播放应用，在所述第一播放窗口中播放从所述第一共享内存中实时读取的屏幕视频流。

Images