CN114513677A - 一种直播方法、装置、服务器以及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种直播方法、装置、服务器以及计算机可读存储介质，用于在保证直播质量的前提下，显著减少对于主播侧UE系统资源的占用。本申请提供的直播方法，包括：服务器接收第一UE发起的直播请求，其中，直播请求用于请求直播的直播数据包括服务器向第一UE下发的目标应用的应用界面数据以及第一UE采集得到的语音数据，目标应用为运行在服务器上的应用；服务器在运行目标应用的过程中，提取目标应用的当前应用界面数据；服务器将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE根据当前应用界面数据以及语音数据向用户输出直播内容。

Description

一种直播方法、装置、服务器以及计算机可读存储介质

技术领域

本申请涉及直播领域，具体涉及一种直播方法、装置、服务器以及计算机可读存储介质。

背景技术

近几年，随着网络技术以及社交网络的发展，网络直播为一种新兴的“随走、随看、随播”的实时网络传播方式，相较于传统媒体的电视直播，低门槛、时效性、强互动性吸引了广大受众，典型的，例如游戏竞技类直播、泛生活类直播、秀场类直播等内容形式的直播，形成了庞大的直播生态以及产业链。

一般的，主播可通过现场架设的音视频采集设备采集现场的视频数据，再上传至直播服务器，由直播服务器推送至建立连接的播放设备，观众即可观看播放设备播放的直播内容。

而在现有的相关技术的研究过程中，发明人发现，主播侧通常是通过手机、平板电脑等终端设备进行的，这些终端设备会安装直播所需的应用程序，即主播专用的应用(Application，APP)，以便对采集到的音视频进行数据处理并上传至直播服务器进行直播，而对于直播行业常见的游戏直播或者其他需涉及到需要直播终端设备上显示画面的直播内容，例如电脑绘图、影评直播等，其直播内容中往往是离不开终端设备上所运行的应用的，而由于如今各类应用的应用大小愈加庞大，尤其是游戏类应用，其应用运行所需的系统资源以及数据处理量，为终端设备带来不小的负担，直播过程中若由于终端设备本地的网络异常、系统崩溃、应用卡顿、画面上传失败等问题，则会导致卡顿、黑屏、掉线等情况，显然，这影响了直播质量。

发明内容

本申请提供了一种直播方法、装置、服务器以及计算机可读存储介质，用于在保证直播质量的前提下，显著减少对于主播侧UE系统资源的占用。

第一方面，本申请提供了一种直播方法，方法包括：

服务器接收第一用户设备(User Equipment，UE)发起的直播请求，其中，直播请求用于请求直播的直播数据包括服务器向第一UE下发的目标应用的应用界面数据以及第一UE采集得到的语音数据，目标应用为运行在服务器上的应用；

服务器在运行目标应用的过程中，提取目标应用的当前应用界面数据；

服务器将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE根据当前应用界面数据以及语音数据向用户输出直播内容。

结合本申请第一方面，在本申请第一方面第一种可能的实现方式中，服务器在运行目标应用的过程中，提取目标应用的当前应用界面数据包括：

服务器在根据应用操作请求运行目标应用的过程中，提取目标应用进行目标操作行为时的当前应用界面数据，其中，应用操作请求是第一UE或者第二UE在用户操作的触发下发起的，应用操作请求用于请求对目标应用进行目标操作行为。

结合本申请第一方面，在本申请第一方面第二种可能的实现方式中，方法还包括：

服务器与多个第二UE上的Web浏览器之间，分别建立通信连接；

服务器将当前应用界面数据以及语音数据下发至多个第二UE包括：

服务器基于自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在Web浏览器中，根据当前应用界面数据以及语音数据向用户输出直播内容。

结合本申请第一方面，在本申请第一方面第三种可能的实现方式中，方法还包括：

服务器接收多个第二UE分别发送的直播观看请求，其中，直播观看请求是第二UE基于第一UE对应的小程序分享链接发起的；

服务器根据多个直播观看请求，分别与多个第二UE建立通信连接；

服务器将当前应用界面数据以及语音数据下发至多个第二UE包括：

服务器基于自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在小程序应用中，根据当前应用界面数据以及语音数据向用户输出直播内容。

结合本申请第一方面，在本申请第一方面第四种可能的实现方式中，方法还包括：

服务器向第一UE下发当前应用界面数据，以使得第一UE根据当前应用界面数据向用户展示所对应的应用界面。

结合本申请第一方面，在本申请第一方面第五种可能的实现方式中，应用界面数据包括指定应用在渲染应用界面时的帧像素数据以及音频数据。

结合本申请第一方面，在本申请第一方面第六种可能的实现方式中，目标应用为看房应用，目标应用用于以2D图像展示形式、3D图像展示形式或者全景图像展示形式的图像展示形式展示楼盘，当前应用界面数据用于展示看房应用在2D图像展示形式、3D图像展示形式或者全景图像展示形式下的当前应用界面。

第二方面，本申请提供一种直播装置，装置包括：

接收单元，用于接收第一UE发起的直播请求，其中，直播请求用于请求直播的直播数据包括服务器向第一UE下发的目标应用的应用界面数据以及第一UE采集得到的语音数据，目标应用为运行在服务器上的应用；

提取单元，用于在运行目标应用的过程中，提取目标应用的当前应用界面数据；

下发单元，用于将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE根据当前应用界面数据以及语音数据向用户输出直播内容。

结合本申请第二方面，在本申请第二方面第一种可能的实现方式中，提取单元，具体用于：

在根据应用操作请求运行目标应用的过程中，提取目标应用进行目标操作行为时的当前应用界面数据，其中，应用操作请求是第一UE或者第二UE在用户操作的触发下发起的，应用操作请求用于请求对目标应用进行目标操作行为。

结合本申请第二方面，在本申请第二方面第二种可能的实现方式中，装置还包括通信单元，用于：

与多个第二UE上的Web浏览器之间，分别建立通信连接；

下发单元，具体用于：

基于服务器自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在Web浏览器中，根据当前应用界面数据以及语音数据向用户输出直播内容。

结合本申请第二方面，在本申请第二方面第三种可能的实现方式中，接收单元，还用于：

接收多个第二UE分别发送的直播观看请求，其中，直播观看请求是第二UE基于第一UE对应的小程序分享链接发起的；

装置还包括通信单元，用于：

根据多个直播观看请求，分别与多个第二UE建立通信连接；

下发单元，具体用于：

基于服务器自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在小程序应用中，根据当前应用界面数据以及语音数据向用户输出直播内容。

结合本申请第二方面，在本申请第二方面第四种可能的实现方式中，下发单元，还用于：

向第一UE下发当前应用界面数据，以使得第一UE根据当前应用界面数据向用户展示所对应的应用界面。

结合本申请第二方面，在本申请第二方面第五种可能的实现方式中，应用界面数据包括指定应用在渲染应用界面时的帧像素数据以及音频数据。

结合本申请第二方面，在本申请第二方面第六种可能的实现方式中，目标应用为看房应用，目标应用用于以2D图像展示形式、3D图像展示形式或者全景图像展示形式的图像展示形式展示楼盘，当前应用界面数据用于展示看房应用在2D图像展示形式、3D图像展示形式或者全景图像展示形式下的当前应用界面。

第三方面，本申请还提供了一种服务器，包括处理器和存储器，存储器中存储有计算机程序，处理器调用存储器中的计算机程序时执行本申请第一方面或者本申请第一方面任一种可能的实现方式提供的方法。

第四方面，本申请还提供了一种计算机可读存储介质，计算机可读存储介质存储有多条指令，指令适于处理器进行加载，以执行本申请第一方面或者本申请第一方面任一种可能的实现方式提供的方法。

从以上内容可得出，本申请具有以下的有益效果：

在直播场景下，本申请针对于直播涉及的应用，构建了一新的应用加载方式，将应用的运行托管至服务器，主播侧第一UE负责采集并上报主播的语音数据，而服务器将应用的运行画面(应用界面数据)及直播语音(语音数据)分发到本地观众侧的第二UE处，如此本地的第二UE只需负责输出服务器同步过来的运行画面及直播语音，则可实现正常的直播内容，可大大降低对于主播侧第一UE的系统资源的占用需求，如此不仅减少了UE的硬件性能要求，且还可进一步扩大了主播侧的UE应用范围，例如原本未能正常运行应用的、数据处理能力较低的个人数字助理PDA、平板电脑等终端设备，现在可结合服务器在本申请所提供的直播机制下正常完成直播，使得直播的应用场景可更加地灵活。

附图说明

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

图1为本申请直播方法的一种场景示意图；

图2为本申请直播方法的一种流程示意图；

图3为本申请建立通信连接的一种流程示意图；

图4为本申请直播装置的一种结构示意图；

图5为本申请服务器的一种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在以下的说明中，本申请的具体实施例将参考由一部或多部计算机所执行的步骤及符号来说明，除非另有述明。因此，这些步骤及操作将有数次提到由计算机执行，本文所指的计算机执行包括了由代表了以一结构化型式中的数据的电子信号的计算机处理单元的操作。此操作转换该数据或将其维持在该计算机的内存系统中的位置处，其可重新配置或另外以本领域测试人员所熟知的方式来改变该计算机的运作。该数据所维持的数据结构为该内存的实体位置，其具有由该数据格式所定义的特定特性。但是，本申请原理以上述文字来说明，其并不代表为一种限制，本领域测试人员将可了解到以下所述的多种步骤及操作亦可实施在硬件当中。

本申请的原理使用许多其它泛用性或特定目的运算、通信环境或组态来进行操作。所熟知的适合用于本申请的运算系统、环境与组态的范例可包括(但不限于)手持电话、个人计算机、服务器、多处理器系统、微电脑为主的系统、主架构型计算机、及分布式运算环境，其中包括了任何的上述系统或装置。

本申请中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。

首先，在介绍本申请之前，先介绍下本申请关于应用背景的相关内容。

本申请提供的直播方法、装置以及计算机可读存储介质，可应用于服务器上，用于在保证直播质量的前提下，显著减少对于主播侧UE系统资源的占用。

本申请提及的直播方法，其执行主体可以为直播装置，或者集成了该装置的服务器，其中，直播装置可以采用硬件或者软件的方式实现，服务器具体还可以为服务器集群的形式存在。

以图1所示的本申请直播方法的一种场景示意图为例，主播侧可针对于本次直播涉及的应用进行讲解，主播侧的第一UE可采集主播的的语音(语音数据)，上传至服务器，并通过直播请求触发服务器进行直播内容的转发，服务器将运行在自身上的直播涉及应用的应用界面(应用界面数据)以及直播语音(语音数据)下发至观众侧的第二UE，以向观众输出本次直播的直播内容。

以全景看房的应用场景为例，工作人员侧的售楼终端(第一UE)侧发起目标楼盘的直播讲解请求，服务器接收到该直播讲解请求后，可运行楼盘应用，加载目标楼盘的全景图像，并将全景图像在应用界面中的显示内容提取出应用界面数据以及售楼终端(第一UE)上报的工作人员的讲解语音的语音数据，下发至看房终端(第二UE)进行直播内容的输出，如此在工作人员的讲解下，多个客户可分别在不同的看房终端(第二UE)处以全景浏览的方式查看目标楼盘，享受高质量的直播看房服务。

当然，当目标应用为看房应用时，不仅可对应的全景看房场景，也可以对应的2D看房场景、3D看房场景，此时，运行在服务器上的目标应用，则是可以用于以2D图像展示形式、3D图像展示形式或者全景图像展示形式的图像展示形式展示楼盘，而服务器下发的当前应用界面数据则是用于展示看房应用在2D图像展示形式、3D图像展示形式或者全景图像展示形式下的当前应用界面。

其中，在本申请中，所提及的UE，具体可以为智能手机、平板电脑、笔记本电脑、掌上电脑、台式电脑或者个人数字助理(Personal Digital Assistant，PDA)等终端设备。

下面，在图1所示应用场景的基础上，参阅图2示出了本申请应用的运行方法的一种流程示意图，如图2示出的，本申请直播方法，具体可包括如下步骤：

步骤S201，服务器接收第一UE发起的直播请求，其中，直播请求用于请求直播的直播数据包括服务器向第一UE下发的目标应用的应用界面数据以及第一UE采集得到的语音数据，目标应用为运行在服务器上的应用；

步骤S202，服务器在运行目标应用的过程中，提取目标应用的当前应用界面数据；

步骤S203，服务器将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE根据当前应用界面数据以及语音数据向用户输出直播内容。

从图2所示实施例可看出，在直播场景下，本申请针对于直播涉及的应用，构建了一新的应用加载方式，将应用的运行托管至服务器，主播侧第一UE负责采集并上报主播的语音数据，而服务器将应用的运行画面(应用界面数据)及直播语音(语音数据)分发到本地观众侧的第二UE处，如此本地的第二UE只需负责输出服务器同步过来的运行画面及直播语音，则可实现正常的直播内容，可大大降低对于主播侧第一UE的系统资源的占用需求，如此不仅减少了UE的硬件性能要求，且还可进一步扩大主播侧的UE应用范围，例如原本未能正常运行应用的、数据处理能力较低的个人数字助理PDA、平板电脑等终端设备，现在可结合服务器在本申请所提供的直播机制下正常完成直播，使得直播的应用场景可更加地灵活。

下面，则开始对图2所示实施例中的各个步骤及其在实际应用中可能的实现方式进行详细介绍。

在本申请中，直播请求可以是当主播准备开始进行直播时，通过第一UE向服务器发起的，后面第一UE则可采集主播录入的语音，转化为语音数据上报至服务器，由服务器进行转发，促进直播内容所涉及主播语音的输出。

而直播涉及的应用，原本可运行在服务器上，或者服务器随着直播请求的触发运行该应用。服务器在应用的运行过程中，可提取其应用运行画面，得到当前应用界面数据，下发至第二UE，完成直播内容所涉及应用画面的输出。

当然，直播请求在实际应用中，也可以是在直播过程中，主播侧的第一UE持续性不断发起的请求。

进一步的，该直播请求，具体还可以第一UE向服务器发起的任意数据，这些数据中携带直播请求的内容即可实现直播请求的功能。

其中，可以理解的是，在主播侧，主播除了可脱离直播涉及应用的应用画面进行直播讲解，也可以是在观看到直播涉及应用的应用画面的基础上进行讲解的。

换句话说，直播应用的当前应用界面数据，除了下发至第二UE，也可以是下发至直播侧。

具体的，服务器还可将该当前应用界面数据，下发至第一UE，第一UE侧的主播在观看当前应用界面(由第一UE根据当前应用界面数据进行输出)时，进行直播讲解，生成语音数据并上报服务器，由服务器下发至第二UE。

对应的，本申请所提出的直播方法，还可包括如下步骤：

服务器向第一UE下发当前应用界面数据，以使得第一UE根据当前应用界面数据向用户展示所对应的应用界面。

或者，主播侧也可配置两个UE，一个UE作为第一UE，一个UE作为第二UE，如此，主播可基于第二UE输出的直播内容，在第一UE进行直播讲解，生成语音数据并上报服务器，由服务器下发至第二UE(主播侧的第二UE可选择关闭音频输出，不影响直播讲解)。

可以理解的是，语音数据的数据量非常小，因此在第一UE-服务器-第二UE传输路径上的传输时长非常的短，可忽略不计，在“实时讲解”的感知范围内，观众感知不到应用画面对应时间和主播语音对应时间之间的差异性，并且不同第二UE所处网络环境的不同，客观上所收看的直播内容在时间上也会有些许的差异性，因此，不会影响直播质量。

此外，应当理解的是，向观众输出的直播内容，在声音方面，不仅可包括主播的语音，还可包括应用本身的声音，对应的，当前应用界面数据中，具体可以包括应用在渲染应用界面时的帧像素数据以及音频数据。

进一步的，在一种示例性的实现方式中，托管至服务器进行运行的直播所涉及应用，还可以由主播进行应用的控制。

具体的，第一UE侧，可通过与主播之间的人机交互，例如在触摸屏上的点击、滑动或者触摸等用户操作，接收主播录入的控制指令。当然，人机交互不仅可以通过触摸屏实现，也可以通过物理按键的按压、语音控制等方式实现，具体在此不做限定。

第一UE在主播的用户操作下，可生成对应的应用操作指令，并基于该应用操作指令向服务器发起应用操作请求，以指示服务器对自身运行的应用进行该应用操作指令对应的目标操作行为。

继续以看房应用为例，工作人员(主播)在进行直播看房时，可在售楼终端(第一UE)上调整画面的视角，以在工作人员(主播)的讲解下更清楚地反应楼盘情况，例如室内装修、房间采光等。

此时，服务器向第二UE下发的当前应用界面数据，具体则是服务器在根据应用操作请求运行应用的过程中，提取应用进行对应操作行为时的当前应用界面数据。

当然，在实际应用中，对于部分的应用场景，例如直播看房等商用场景，观众侧也可能具有控制应用的需求，因此，应用操作请求也可能是直播观众在第二UE侧发起的。

例如，看房顾客可在看房终端(第二UE)上进行直播看房时，可调整画面的视角，以便自身可更清楚地了解楼盘情况，例如室内装修、房间采光等。

而在实际应用中，考虑到应用的控制场景，则可引入权限机制，不同的用户具有对应的控制权限，该权限可默认设置或者根据实际需要调整，对应的，发起的应用操作请求可携带用户权限标识，以标识当前识图进行应用控制的用户的控制权限，若低于预设权限等级或者其标识的权限范围未包含应用控制权限，则服务器即使接收到应用操作请求，也可不用根据应用操作请求所请求的应用控制处理进行相应的应用控制。

进一步的，在上文已提及，本申请提出的直播机制，是将应用的运行托管至服务器，主播侧的第一UE用于采集主播内容涉及的主播语音，或者在部分场景下可向主播输出应用界面(由服务器下发应用界面数据实现)，甚至还可通过人机交互采集主播对于应用的应用操作指令，如此大大降低了运行应用本身对第一UE系统资源的占用。

而在该情况下，第一UE还可无需安装应用相关的应用程序(例如用于实现以下功能的应用程序：根据服务器下发的应用界面数据输出对应的应用界面、通过人机交互功能发起应用操作请求)，仅通过Web浏览器来完成语音数据的采集或者上报、或者在部分场景下可向主播输出应用界面(由服务器下发应用界面数据实现)，甚至还可通过人机交互采集主播对于应用的应用操作指令，如此，可更便捷地实现应用的应用功能，进一步减少对第一UE系统资源的占用。

其中，该Web浏览器，可以为常用的浏览器应用、内置于其他应用中的Web浏览器或者其他应用中可调用的小程序。如此，对于主播，无需在第一UE上安装或下载任何内容，直播方式更加的灵活。

又或者，本申请直播机制中，第一UE也可配置直播涉及应用配置用于安装在主播侧的应用程序，该应用程序中包含有Web浏览器的应用程序，可显示于第一UE的桌面界面中，供主播选定启动，还可配置为当启动时，与服务器自动建立通信连接甚至自动触发应用直播涉及应用、开始同步直播涉及应用的应用界面。

类似的，第二UE也可通过自身与Web浏览器与服务器之间分别建立的通信连接，接收服务器下发的当前应用界面数据以及语音数据，进而向观众输出直播内容。

如此，本申请提供的直播方法，还可包括：

服务器与多个第二UE上的Web浏览器之间，分别建立通信连接；

而当前应用界面数据以及语音数据的下发，则可包括：

服务器基于自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在Web浏览器中，根据当前应用界面数据以及语音数据向用户输出直播内容。

在实际应用中，在建立通信连接的过程中，为确保信令和Web服务器能够在运行服务器和UE的Web浏览器间交涉直接连接，双方需互相发送各自的IP地址，如此，在进行通信时，Web浏览器需要访问服务器发送的IP地址，服务器需要访问Web浏览器发送的IP地址。

其中，UE的Web浏览器以及服务器，双方可通过查询实现NAT会话穿越应用程序(Session Traversal Utilities for NAT，STUN)协议的服务器，即STUN服务器(STUN服务器可以理解为一种网络地址转换(Network Address Translation，NAT)会话遍历工具)，以找出自身公开可见的IP地址，STUN服务器告知UE以及服务器其自身的公开可见IP地址后，信令和Web服务器可继续中继各自的直接连接。

或者，也可使用TURN服务器在UE的Web浏览器以及服务器之间中继数据流，TURN服务器可用于进行网页即时通信(Web Real-Time Communication，WebRTC)时，可用于数据的转发。启动TURN协议后，TURN服务器一方面与服务器连接，另一方面则与UE的Web浏览器连接。服务器将自身需要流送的数据(如应用界面数据、语音数据)发送给TURN服务器，TURN服务器又将该数据传送至浏览器。在此情况下，UE的Web浏览器以及服务器之间并无直接连接。典型的，如要在无线运营商网络中支持移动设备，只能使用TURN服务器，移动网络通常不支持客户端通过WebRTC协议进行连接。

在该背景下，UE的Web浏览器可先与服务器先进行配对，服务器再指定对应的Web服务器、STUN服务器或者TURN服务器，完成通信连接的构建。

进一步的，在实际应用中，为便于实际应用，UE的Web浏览器以及运行指定应用的服务器之间的通信连接，优选的为UE触发建立的，如此，在具有直播需求或者观看直播需求时，再进行通信连接的建立。

除了Web浏览器，在实际应用中，UE还可通过小程序来建立与服务器之间的通信连接，以实现如第一UE侧语音数据的采集或者上报、或者在部分场景下可向主播输出应用界面(由服务器下发应用界面数据实现)，甚至还可通过人机交互采集主播对于应用的应用操作指令，或者实现第二UE侧向观众输出直播内容(由服务器下发应用界面数据以及语音数据实现)。

其中，对于第二UE，其具体可通过小程序向服务器发起直播观看请求，来建立第二UE与服务器之间的通信连接。

参阅图3示出的本申请建立通信连接的一种流程示意图，第二UE与服务器之间通信连接的建立，具体可包括：

步骤S301，服务器接收多个第二UE分别发送的直播观看请求，其中，直播观看请求是第二UE基于第一UE对应的小程序分享链接发起的；

可以看出，在本申请中，第二UE通过小程序向服务器发起直播观看请求，以建立通信连接，具体还可以是基于第一UE对应的小程序分享链接发起的。

对于直播，尤其是看房等商用场景，为进一步提高进入直播间、观看直播内容的效率，观众侧还可以直接点击主播所分享出的小程序分享链接，促使UE根据该链接访问服务器，发起直播观看请求，以建立通信连接，成为本申请直播机制中的第二UE，观看直播内容。

继续以直播看房应用场景为例，具有看房需求的客户可通过手中的智能手机(第二UE)扫描工作人员提供的小程序二维码(可识别出小程序分享链接)或者工作人员发送过来的小程序分享链接，进而与服务器建立通信连接，此时服务器可将客户手中建立连接的手机默认为第二UE，可进行直播看房内容的输出，完成直播看房场景。

步骤S302，服务器根据多个直播观看请求，分别与多个第二UE建立通信连接；

对应的，服务器接收到UE上报的直播观看请求后，则可建立两者之间的通信连接，并将另一侧的UE识别为本申请直播机制中的第二UE，后续则可下发应用界面数据以及语音数据，进行直播内容的输出。

对应的，应用界面数据以及语音数据下发至多个第二UE包括：

服务器基于自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在小程序应用中，根据当前应用界面数据以及语音数据向用户输出直播内容。

以上是本申请直播方法的介绍，为便于更好的实施本申请提供的直播方法，本申请还提供了直播装置。

参阅图4，图4为本申请直播装置的一种结构示意图，在本申请中，直播装置400具体可包括如下结构：

接收单元401，用于接收第一UE发起的直播请求，其中，直播请求用于请求直播的直播数据包括服务器向第一UE下发的目标应用的应用界面数据以及第一UE采集得到的语音数据，目标应用为运行在服务器上的应用；

提取单元402，用于在运行目标应用的过程中，提取目标应用的当前应用界面数据；

下发单元403，用于将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE根据当前应用界面数据以及语音数据向用户输出直播内容。

在一种示例性的实现方式中，提取单元402，具体用于：

在根据应用操作请求运行目标应用的过程中，提取目标应用进行目标操作行为时的当前应用界面数据，其中，应用操作请求是第一UE或者第二UE在用户操作的触发下发起的，应用操作请求用于请求对目标应用进行目标操作行为。

在又一种示例性的实现方式中，装置还包括通信单元404，用于：

与多个第二UE上的Web浏览器之间，分别建立通信连接；

下发单元403，具体用于：

基于服务器自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在Web浏览器中，根据当前应用界面数据以及语音数据向用户输出直播内容。

在又一种示例性的实现方式中，接收单元401，还用于：

接收多个第二UE分别发送的直播观看请求，其中，直播观看请求是第二UE基于第一UE对应的小程序分享链接发起的；

装置还包括通信单元404，用于：

根据多个直播观看请求，分别与多个第二UE建立通信连接；

下发单元403，具体用于：

基于服务器自身分别与多个第二UE建立的通信连接，将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE在小程序应用中，根据当前应用界面数据以及语音数据向用户输出直播内容。

在又一种示例性的实现方式中，下发单元403，还用于：

向第一UE下发当前应用界面数据，以使得第一UE根据当前应用界面数据向用户展示所对应的应用界面。

在又一种示例性的实现方式中，应用界面数据包括指定应用在渲染应用界面时的帧像素数据以及音频数据。

在又一种示例性的实现方式中，目标应用为看房应用，目标应用用于以2D图像展示形式、3D图像展示形式或者全景图像展示形式的图像展示形式展示楼盘，当前应用界面数据用于展示看房应用在2D图像展示形式、3D图像展示形式或者全景图像展示形式下的当前应用界面。

本申请还提供了服务器，参阅图5，图5示出了本申请服务器的一种结构示意图，具体的，本申请服务器包括处理器501、存储器502以及输入输出设备503，处理器501用于执行存储器502中存储的计算机程序时实现如图1至图3对应任意实施例中直播方法的各步骤；或者，处理器501用于执行存储器502中存储的计算机程序时实现如图4对应实施例中各单元的功能，存储器502用于存储处理器501执行上述图1至图3对应任意实施例中直播方法所需的计算机程序。

示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器502中，并由处理器501执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机装置中的执行过程。

服务器可包括，但不仅限于处理器501、存储器502、输入输出设备503。本领域技术人员可以理解，示意仅仅是服务器的示例，并不构成对服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如服务器还可以包括网络接入设备、总线等，处理器501、存储器502、输入输出设备503以及网络接入设备等通过总线相连。

处理器501可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是服务器的控制中心，利用各种接口和线路连接整个服务器的各个部分。

存储器502可用于存储计算机程序和/或模块，处理器501通过运行或执行存储在存储器502内的计算机程序和/或模块，以及调用存储在存储器502内的数据，实现计算机装置的各种功能。存储器502可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等；存储数据区可存储根据服务器的使用所创建的数据(比如语音数据、视频数据等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器501用于执行存储器502中存储的计算机程序时，具体可实现以下功能：

接收第一UE发起的直播请求，其中，直播请求用于请求直播的直播数据包括服务器向第一UE下发的目标应用的应用界面数据以及第一UE采集得到的语音数据，目标应用为运行在服务器上的应用；

在运行目标应用的过程中，提取目标应用的当前应用界面数据；

将当前应用界面数据以及语音数据下发至多个第二UE，以使得多个第二UE根据当前应用界面数据以及语音数据向用户输出直播内容。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的直播装置、服务器及其相应单元的具体工作过程，可以参考如图1至图3对应任意实施例中直播方法的说明，具体在此不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请如图1至图3对应任意实施例中直播方法中的步骤，具体操作可参考如图1至图3对应任意实施例中直播方法的说明，在此不再赘述。

其中，该计算机可读存储介质可以包括：只读存储器(Read Only Memory，ROM)、随机存取记忆体(Random Access Memory，RAM)、磁盘或光盘等。

由于该计算机可读存储介质中所存储的指令，可以执行本申请如图1至图3对应任意实施例中直播方法中的步骤，因此，可以实现本申请如图1至图3对应任意实施例中直播方法所能实现的有益效果，详见前面的说明，在此不再赘述。

以上对本申请提供的直播方法、装置、服务器以及计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种直播方法，其特征在于，所述方法包括：

服务器接收第一用户设备UE发起的直播请求，其中，所述直播请求用于请求直播的直播数据包括所述服务器向所述第一UE下发的目标应用的应用界面数据以及所述第一UE采集得到的语音数据，所述目标应用为运行在所述服务器上的应用；

所述服务器在运行所述目标应用的过程中，提取所述目标应用的当前应用界面数据；

所述服务器将所述当前应用界面数据以及所述语音数据下发至多个第二UE，以使得多个所述第二UE根据所述当前应用界面数据以及所述语音数据向用户输出直播内容。

2.根据权利要求1所述的方法，其特征在于，所述服务器在运行所述目标应用的过程中，提取所述目标应用的当前应用界面数据包括：

所述服务器在根据应用操作请求运行所述目标应用的过程中，提取所述目标应用进行所述目标操作行为时的当前应用界面数据，其中，所述应用操作请求是所述第一UE或者所述第二UE在用户操作的触发下发起的，所述应用操作请求用于请求对所述目标应用进行目标操作行为。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述服务器与多个所述第二UE上的Web浏览器之间，分别建立通信连接；

所述服务器将所述当前应用界面数据以及所述语音数据下发至多个第二UE包括：

所述服务器基于自身分别与多个所述第二UE建立的通信连接，将所述当前应用界面数据以及所述语音数据下发至多个所述第二UE，以使得多个所述第二UE在所述Web浏览器中，根据所述当前应用界面数据以及所述语音数据向用户输出直播内容。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述服务器接收多个所述第二UE分别发送的直播观看请求，其中，所述直播观看请求是所述第二UE基于所述第一UE对应的小程序分享链接发起的；

所述服务器根据多个所述直播观看请求，分别与多个所述第二UE建立通信连接；

所述服务器将所述当前应用界面数据以及所述语音数据下发至多个第二UE包括：

所述服务器基于自身分别与多个所述第二UE建立的通信连接，将所述当前应用界面数据以及所述语音数据下发至多个所述第二UE，以使得多个所述第二UE在小程序应用中，根据所述当前应用界面数据以及所述语音数据向用户输出直播内容。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述服务器向所述第一UE下发所述当前应用界面数据，以使得所述第一UE根据所述当前应用界面数据向用户展示所对应的应用界面。

6.根据权利要求1所述的方法，其特征在于，所述应用界面数据包括所述指定应用在渲染应用界面时的帧像素数据以及音频数据。

7.根据权利要求1所述的方法，其特征在于，所述目标应用为看房应用，所述目标应用用于以2D图像展示形式、3D图像展示形式或者全景图像展示形式的图像展示形式展示楼盘，所述当前应用界面数据用于展示所述看房应用在所述2D图像展示形式、所述3D图像展示形式或者所述全景图像展示形式下的当前应用界面。

8.一种直播装置，其特征在于，所述装置包括：

接收单元，用于接收第一用户设备UE发起的直播请求，其中，所述直播请求用于请求直播的直播数据包括所述服务器向所述第一UE下发的目标应用的应用界面数据以及所述第一UE采集得到的语音数据，所述目标应用为运行在所述服务器上的应用；

提取单元，用于在运行所述目标应用的过程中，提取所述目标应用的当前应用界面数据；

下发单元，用于将所述当前应用界面数据以及所述语音数据下发至多个第二UE，以使得多个所述第二UE根据所述当前应用界面数据以及所述语音数据向用户输出直播内容。

9.一种服务器，其特征在于，包括处理器和存储器，所述存储器中存储有计算机程序，所述处理器调用所述存储器中的计算机程序时执行如权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有多条指令，所述指令适于处理器进行加载，以执行权利要求1至7任一项所述的方法。

Images