CN113347450B - 一种多应用共享音视频设备的方法、装置和系统 - Google Patents

Abstract

本发明公开了一种多应用共享音视频设备的方法、装置和系统。所述方法包括：响应于应用对音视频设备的操作请求，若根据操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给应用。能够实现多个应用对同一音视频设备的共享，避免了共享引发的状态混乱。

Description

一种多应用共享音视频设备的方法、装置和系统

技术领域

本发明涉及多媒体技术领域，特别涉及一种多应用共享音视频设备的方法、装置和系统。

背景技术

安卓系统往往可以安装有多款相机应用，这些相机应用均可调用框架层提供的接口，发送对相机的各种操作请求(如打开相机、设置相机参数、预览、拍照、录像或关闭相机等)。但为了避免多个相机应用同时操作相机引起的状态混乱，往往同一时间只允许一个相机应用使用相机，例如相机应用A正在使用相机录像的过程中，若要同时运行相机应用B，相机应用B是无法正常打开相机的，会提示相机已被占用。这在部分应用场景下却带来了阻碍，比如，虚拟现实(Virtual Reality，VR)或增强现实(Augmented Reality，AR)设备的部分应用场景，需要一个后台进程一直获取相机数据做算法，而要求不影响其他应用使用相机。

现有技术往往是修改框架层的Camera Service，把限制条件放松，但也只能实现当一个应用使用一个相机时，别的应用还可以打开其他相机，而无法让同一相机被多个应用同时使用，无法真正实现同一时间同一相机的共享。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种多应用共享音视频设备的方法、装置和系统。

第一方面，本发明实施例提供一种多应用共享音视频设备的方法，包括：

响应于应用对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给所述应用。

第二方面，本发明实施例提供一种多路直播方法，包括：

根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；

将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。

第三方面，本发明实施例提供一种多应用共享音视频设备的装置，包括确定模块、截取模块和通信模块；

所述确定模块，用于响应于所述通信模块获取到的应用对音视频设备的操作请求，根据所述操作请求确定是否需要获取音视频数据；

所述截取模块，用于当所述确定模块确定为是时，从音视频设备的预览数据流中截取所请求的音视频数据；

通信模块，用于将所述截取模块截取的音视频数据提供给所述应用。

第四方面，本发明实施例提供一种多应用共享音视频设备的系统，包括代理模块和多个应用；

所述代理模块，用于响应于应用对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给所述应用。

第五方面，本发明实施例提供一种多应用共享音视频设备的系统，包括操作系统和安装于所述操作系统上的多个应用；

所述操作系统，用于响应于应用对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给所述应用。

第六方面，本发明实施例提供一种终端，包括代理模块和多个应用；

所述代理模块，用于响应于应用对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给所述应用。

第七方面，本发明实施例提供一种多路直播装置，包括截取模块和通信模块；

所述截取模块，用于根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据；

通信模块，用于将所述截取模块截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。

第八方面，本发明实施例提供一种多路直播系统，包括代理模块、播放装置和多个直播应用；

所述代理模块，用于根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；

所述播放装置，用于同屏播放所述代理模块发送的各直播应用返回的处理后音视频数据。

第九方面，本发明实施例提供一种多路直播系统，包括操作系统和安装于所述操作系统上的播放装置和多个直播应用；

所述操作系统，用于根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；

所述播放装置，用于同屏播放所述操作系统发送的各直播应用返回的处理后音视频数据。

第十方面，本发明实施例提供一种多路直播终端，包括代理模块、播放装置和多个直播应用；

所述代理模块，用于根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；

所述播放装置，用于同屏播放所述代理模块发送的各直播应用返回的处理后音视频数据。

第十一方面，本发明实施例提供一种非临时性计算机可读存储介质，其上存储有计算机指令，当该指令被处理器执行时实现上述多应用共享音视频设备的方法，或实现上述多路直播方法。

第十二方面，本发明实施例提供一种计算机设备，包括存储器、处理器及存储于存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述多应用共享音视频设备的方法，或实现上述多路直播方法。

本发明实施例提供的上述技术方案的有益效果至少包括：

(1)本发明实施例提供的多应用共享音视频设备的方法，响应于应用对音视频设备的操作请求，若根据操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给应用。各个应用直接对接的不是音视频设备，而是通过中间的模块，对多个应用的音视频设备操作请求进行统一管理，为需要获取音视频数据的操作请求从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给相应的应用，对于同一终端的各个应用而言，实现了可以共享音视频设备的效果，且避免了音视频设备共享所引发的冲突；同时，无需设置多个音视频设备，节约了成本。

(2)本发明实施例提供的多路直播方法，根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用，接收直播应用返回的处理后音视频数据；将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。各个直播应用直接对接的不是音视频设备，而是通过中间的模块，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给各个请求音视频数据的直播应用进行处理；接收各个直播应用返回的处理后音视频数据并发送给播放装置进行同屏播放，在同一直播端实现了多路直播的功能，使得只需一台直播端便可实现多路直播，无需同时打开多台直播端，节省了直播成本，且使得直播操作更加便捷；直播端不需要设置多个音视频设备，进一步节省了成本；同时，只使用一台直播端易于移动直播。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明实施例一所述的多应用共享音视频设备的方法流程图；

图2为现有技术中应用调用音视频设备的架构图；

图3为本发明实施例一中应用调用音视频设备的架构图；

图4为本发明实施例一的实现原理示意图；

图5为本发明实施例二所述多路直播方法的流程图；

图6为本发明实施例中多应用共享音视频设备的装置的结构示意图；

图7为本发明实施例中多应用共享音视频设备的系统的结构示意图；

图8为本发明实施例中另一多应用共享音视频设备的系统的结构示意图；

图9为本发明实施例中一种终端的结构示意图；

图10为本发明实施例中多路直播装置的结构示意图；

图11为本发明实施例中多路直播系统的结构示意图；

图12为本发明实施例中另一多路直播系统的结构示意图；

图13为本发明实施例中一种多路直播终端的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

为了解决现有技术中存在的无法实现多个相机应用共享相机的问题，本发明实施例提供一种多应用共享音视频设备的方法、装置和系统，能够实现多个应用对同一音视频设备的共享，且避免了共享引发的状态混乱。

实施例一

本发明实施例一提供一种多应用共享音视频设备的方法，其流程如图1所示，包括如下步骤：

步骤S11：响应于应用对音视频设备的操作请求，若根据操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据。

现有技术中为了避免多个应用同时共享音视频设备引发状态混乱的问题，往往对访问音视频设备的应用数量进行限制，同一时间只允许一个应用访问音视频设备，即音视频设备处于被占用状态时，其他的应用无法再使用音视频设备。这为多个应用需要共享音视频设备的场景带来了实现阻碍。

鉴于此，本发明实施例一对音视频设备所在终端设置了中间代理模块，由代理模块拦截本地各应用对音视频设备的操作请求，并对操作请求进行统一管理，对有冲突的操作请求按照预设的优先级规则进行取舍；由代理模块将应用的操作请求发送给音视频设备；代理模块从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给相应的应用。从而模拟出各个应用均能访问音视频设备的效果。

在一个实施例中，可以包括，代理模块从系统的框架层获取应用对音视频设备的操作请求。

参照图2所示，以Android系统为例，现有技术中应用对音视频设备的操作请求的发送流程为，依次经过所在终端的操作系统的：

①应用层(Application，App)

即Android系统里的应用程序。

②框架层Frameworks

Android系统上层服务，向上提供接口给APP使用，向下调用HAL层接口。

③硬件抽象层HAL

为了适配各个厂商的硬件而抽象出通用的接口，由该层把接口对接到Frameworks层。

④内核层Kernel

为最接近硬件(音视频设备)的一层。

音视频设备反馈的相关信息经由上述途径相反的途径返回给应用App。

Frameworks层里的其中一个服务为Camera Service，负责接收APP发送的camera请求，下发指令依次到HAL、Kernel直至camera模组，从而完成camera的各个功能。故代理模块从操作系统的框架层获取应用对音视频设备的操作请求。框架层包括应用框架层AppFramework和本机框架层Navive Framework，本机框架层设置有Camera Service服务，所以更具体的，代理模块从本机框架层获取应用对音视频设备的操作请求。

参照图3所示，由于在现有技术的基础上，在应用层APP与框架层Frameworks之间设置了代理层Proxy APP(代理模块)，各个APP之间通过代理层与音视频设备对接，实现了多个APP可以共享音视频设备的效果。

本发明实施例一提供的方案，没有对系统的HAL和Kernel层进行修改，而是在APP层及Fameworks层之间加入新的代理层(代理模块)，不依赖原有代码，可轻松拓展和移植到各版本的操作系统中，故拓展性高、移植性强。

代理层截获所有APP发出的请求，统一处理后发送给camera；而对Frameworks层的Camera Service而言，始终只有一个应用(代理层)发出对camera的请求，从而巧妙地绕开了Frameworks层原有的限制。

在一个实施例中，若当前需要获取音视频数据的操作请求有多个，即有多个应用请求音视频数据，且请求的音视频数据类型不同时，从音视频设备的预览数据流中截取所请求的音视频数据，可以包括，按预设的优先级规则确定请求的音视频数据类型的处理顺序；按处理顺序依次从音视频设备的预览数据流中截取相应类型的音视频数据。

具体的，请求的音视频数据的类型可以为图片或视频，若同一时间段内既有应用请求图片数据，又有应用请求视频数据，按预设的优先级规则确定请求图片数据的至少一个应用中优先级最高的为应用A，确定请求视频数据的至少一个应用中优先级最高的为应用B，若应用A的优先级高于应用B，则先从音视频设备的预览数据流中截取请求的图片数据，确定请求图片数据的应用的个数，将截取的图片数据按照应用的个数进行复制，将复制的图片数据发送给请求的应用，可以是并行发送；再从音视频设备的预览数据流中截取请求的视频数据，确定请求视频数据的应用的个数，将截取的视频数据按照应用的个数进行复制，将复制的视频数据发送给请求的应用，可以是并行发送。若应用B的优先级高于应用A，则先从音视频设备的预览数据流中截取请求的视频数据，确定请求视频数据的应用的个数，将截取的视频数据按照应用的个数进行复制，将复制的视频数据发送给请求的应用，可以是并行发送；再从音视频设备的预览数据流中截取请求的图片数据，确定请求图片数据的应用的个数，将截取的图片数据按照应用的个数进行复制，将复制的图片数据发送给请求的应用，可以是并行发送。

可选的，上述依据的优先级规则也可以是其他的优先级规则，也可以是确定请求图片数据的各应用的优先级平均值，和请求视频数据的各应用优先级平均值，再比较两个平均值的大小，若前者大，先截取图片数据，若后者大，先截取视频数据；也可以是不考虑请求的应用的优先级，只设定图片数据的优先级高，或者视频数据的优先级高；可选的，也可以选用别的优先级规则，这里不做具体限定。

若当前需要获取音视频数据的操作请求有多个，即有多个应用请求音视频数据，且请求的音视频数据类型相同，则直接从音视频设备的预览数据流中截取请求类型的音视频数据，再按请求的应用个数进行复制，并行发送给各应用。

步骤S12：将截取的音视频数据提供给应用。

具体的，若根据操作请求确定需要获取图像数据时，从音视频设备的预览数据流中截取与操作请求的请求时间相匹配帧的图像数据，将截取的图像数据发送给应用；或，若根据操作请求确定需要获取视频数据时，从音视频设备的预览数据流中截取与操作请求的请求时间相匹配帧的视频数据，将截取的视频数据发送给应用。

本发明实施例一提供的多应用共享音视频设备的方法，响应于应用对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给应用。各个应用直接对接的不是音视频设备，而是通过中间的模块，对多个应用的音视频设备操作请求进行统一管理，为需要获取音视频数据的操作请求从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给相应的应用，对于同一终端的各个应用而言，实现了可以共享音视频设备的效果，且避免了音视频设备共享所引发的冲突；同时，无需设置多个音视频设备，节约了成本。

在一个实施例中，响应于应用对音视频设备的操作请求，若根据操作请求、音视频设备当前的运行状态和预设的优先级规则，确定需要音视频设备执行操作指令时，或根据操作请求和音视频设备当前的运行状态确定需要音视频设备执行操作指令时，向音视频设备发送相应的操作指令。具体的，根据操作请求包含的操作指令的不同，在不同的实施例中可能包含下述情况：

(1)操作请求包含设置音视频设备的第一配置参数

具体的，上述第一配置参数指不一致的设置可兼容的配置参数，例如预览数据流的数据格式和/或每帧图像的预览尺寸等，以数据格式为例，可根据任一种数据格式转换成同类型的其他的数据格式。数据格式或预览尺寸可以按照请求的应用的优先级来设置，按照优先级的顺序为其他请求不同的第一配置参数的应用进行数据格式的转换。后面的第二配置参数指不一致的设置可能不兼容的配置参数，例如分辨率，只能将高分辨率的数据转换成低分辨率的，故可以将音视频设备预览数据流中每帧图像的分辨率设置为所有请求的分辨率中的最大值，再按优先级先后将截取到的数据进行分辨率的转换。

在一个实施例中，可以包括，若操作请求包含设置音视频设备的第一配置参数，判断操作请求包含的第一配置参数是否与音视频设备当前的第一配置参数一致；若否，且根据预设的优先级规则，确定发送操作请求的应用优先级不低于音视频设备当前的第一配置参数对应的应用的优先级，确定需要音视频设备执行修改第一配置参数的操作指令。

具体的，上述优先级规则也可以是其他的规则，例如，还可以是确定发送操作请求的应用优先级高于音视频设备当前的第一配置参数对应的应用的优先级；也可以是，确定发送操作请求的应用优先级高于音视频设备当前的第一配置参数对应的应用的优先级，或，确定发送操作请求的应用与音视频设备当前的第一配置参数对应的应用为同一应用，确定需要音视频设备执行修改第一配置参数的操作指令。

(2)操作请求包含设置音视频设备的第二配置参数

在一个实施例中，可以包括，若操作请求包含设置音视频设备的第二配置参数，判断操作请求是否与所述音视频设备当前的第二配置参数相冲突；若是，确定需要音视频设备执行修改第二配置参数的操作指令。

第二配置参数为预览数据流分辨率时，判断操作请求包含的分辨率是否大于音视频设备当前的预览数据流数据的分辨率；若是，确定操作请求与音视频设备当前的预览数据流数据的分辨率相冲突。

(3)操作请求包含开启音视频设备

操作请求包含开启音视频设备，且音视频设备的运行状态为关闭状态时，确定需要音视频设备执行开启的操作指令。

(4)操作请求包含关闭音视频设备

操作请求包含关闭音视频设备，且确定没有其他应用正在使用音视频设备，确定需要音视频设备执行关闭的操作指令。

针对现有技术中多个APP同时使用同一camera资源可能引起状态混乱的问题，本发明实施例一通过在代理层设置一套管理机制(优先级规则)来解决。APP发起操作camera的请求后，代理层捕获，一旦出现部分相互冲突的camera操作请求，按照优先级规则进行取舍。

在一个实施例中，向音视频设备发送操作指令后，还包括：向应用发送操作请求执行成功的消息。

在一个实施例中，当截取的音视频数据的参数与操作请求包含的请求参数不一致时，将截取的音视频数据提供给应用前，还可以包括，根据操作请求包含的请求参数处理截取的音视频数据；将处理后的音视频数据发送给应用。

具体的，上述参数可以包括分辨率、每帧图像的尺寸和数据格式中的至少一项。当应用请求的图片数据或音视频数据的分辨率不同时，从音视频设备的预览数据流中截取所请求的最大分辨率的图片数据或音视频数据，再按照其他请求的应用的预先级，将截取的数据依次进行降分辨率处理，处理成每个应用所请求的分辨率后再发送给相应的应用；当应用请求的图片数据或音视频数据的每帧图像的预览尺寸不同时，从音视频设备的预览数据流中直接截取的图片数据或音视频数据是优先级最高的应用所请求的预览尺寸，再按照其他请求的应用的预先级，将截取的数据依次进行预览尺寸转换处理，处理成每个应用所请求的尺寸后再发送给相应的应用；当应用请求的图片数据或音视频数据的数据格式不同时，从音视频设备的预览数据流中直接截取的图片数据或音视频数据是优先级最高的应用所请求的数据格式，再按照其他请求的应用的预先级，将截取的数据依次进行格式转换，转换成每个应用所请求的格式后再发送给相应的应用。

可选的，代理模块也可以不对从音视频设备的预览数据流中截取的视频数据进行处理，而是直接按照请求的应用个数进行复制后发送给各应用，由各应用按需求将接收到的数据进行转换处理。

参照图4所示，为本发明实施例一实现的一种可行的底层架构图，代理层ProxyAPP在每个应用程序APK使用相机接口Camera API打开camera时，均会创建一个对应的代理对象实现类GLT Thread Manager Impl2(图4中的虚线框)和此APK进行交互。当有多个APK接入时，便有多个GLT Thread Manager Impl2，这些GLT Thread Manager Impl2被相机代理管理实现类Camera Proxy Manager Impl2所管理。GLT Thread Manager Impl2与APK之间经由Session通信。

Camera Proxy Manager Impl2直接使用Camera.java来对接Camera Service，操作相机设备，包括管理各个APK对相机的参数设置指令，设置相机的参数set Parameter，接收相机返回的信息Call back发送给对应的APK。从相机角度看，并不是同时被多个APK访问，而是仅有一个相机接口Camera API的访问进程。

Camera Proxy Manager Impl2管理对单个APK的所有渲染层surface的渲染，如图4中所示，“圆圈”代表APK可能设置的surface，“圆角长方形”表示“源图像”，这里的“源图像”是通过Camera Proxy Manager Impl2获得，然后分发给每个APK的。

多个APK接入时，在Camera Proxy Manager Impl2中便有多个“源图像”需要填充，此工作由GL Texture Flinger来完成，GL Texture Flinger具有唯一的源数据端，但有多个接收端sink端，这些sink端就是Camera Proxy Manager Impl2中的“源图像”，而唯一的源数据端的数据来自Surface Texture，Surface Texture的数据由Camera Service填充。自此，Camera Service的预览数据首先发送给GL Texture Flinger的唯一源数据端(Surface Texture)，接着按照管理的请求相机数据的序列Take Picture Queue分发给所有的sink端(GLT Thread Manager Impl2的“源图像”)，每个GLT Thread Manager Impl2再进行二次分发。

每个APK改变参数时，均会导致对应的GLT Thread Manager Impl2参数改变，所有参数改变在管理者(Camera Proxy Manager Impl2)中进行优先级处理，以便决定哪个APK的参数可以最终下发给Camera Service。Camera Service的回调，如拍照数据，聚焦状态等，也由Camera Proxy Manager Impl2分发给每个GLT Thread Manager Impl2对象，再由GLT Thread Manager Impl2发送到APK。

实施例二

本发明实施例二提供一种多路直播方法，其流程如图5所示，包括如下步骤：

步骤S51：根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用，接收直播应用返回的处理后音视频数据。

各直播应用不是直接访问音视频设备，而是通过中间的代理模块，代理模块对多个直播应用的音视频数据获取请求统一管理，根据从音视频设备的预览数据流中截取的音视频数据为各直播应用提供相应的数据。

若同时存在多个请求音视频数据的直播应用，且请求的数据格式和需要的参数设置都一致，代理模块只需要将实时从音视频设备的预览数据流中截取的音视频数据复制相应的份数，将复制后的数据发送给直播应用即可，可以是同步发送。

若同时存在多个请求音视频数据的直播应用，且请求的数据格式不一致，则将实时从音视频设备的预览数据流中截取的音视频数据复制相应的份数，按照优先级规则逐一将复制后的数据转换成应用请求的数据格式和/或参数，再发送给相应的应用；可选的，也可以不进行数据的转换，直接发送复制后的数据，由各直播应用将接收到的数据转换成需要的数据格式和/或参数。

同时，代理模块统一管理各直播应用对音视频设备的操作请求，若根据操作请求、音视频设备当前的运行状态和预设的优先级规则，确定需要音视频设备执行操作指令时，或根据作请求和音视频设备当前的运行状态确定需要音视频设备执行操作指令时，向音视频设备发送相应的操作指令。具体方法如实施例一中所述，此处不再赘述。

步骤S52：将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。

各直播应用通过代理模块实现了音视频设备的共享，播放装置同屏播放各直播应用返回的处理后音视频数据，在同一终端实现了多路直播。

具体的，本发明实施例二提供的多路直播方法，各个直播应用如何获取音视频设备实时预览的音视频数据，及代理模块如何统一管理各直播应用的数据获取请求和操作指令，具体方法与上述实施例一中的方法类似，此处不再赘述。

本发明实施例二提供的多路直播方法，根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用，接收直播应用返回的处理后音视频数据；将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。各个直播应用直接对接的不是音视频设备，而是通过中间的模块，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给各个请求音视频数据的直播应用进行处理；接收各个直播应用返回的处理后音视频数据并发送给播放装置进行同屏播放，在同一直播端实现了多路直播的功能，使得只需一台直播端便可实现多路直播，无需同时打开多台直播端，节省了直播成本，且使得直播操作更加便捷；直播端不需要设置多个音视频设备，进一步节省了成本；同时，只使用一台直播端易于移动直播。

基于本发明的发明构思，本发明实施例还提供一种多应用共享音视频设备的装置，能够实现上述多应用共享音视频设备的方法。该装置可以设置在手机终端、电脑终端或PAD终端等设置有音视频设备硬件的设备中，该装置的结构如图6所示，包括确定模块61、截取模块62和通信模块63；

确定模块61，用于响应于通信模块63获取到的应用对音视频设备的操作请求，根据所述操作请求确定是否需要获取音视频数据；

截取模块62，用于当确定模块61确定为是时，从音视频设备的预览数据流中截取所请求的音视频数据；

通信模块63，用于将截取模块62截取的音视频数据提供给所述应用。

基于本发明的发明构思，本发明实施例还提供一种多应用共享音视频设备的系统，能够实现上述多应用共享音视频设备的方法。该系统置可以设置在手机终端、电脑终端或PAD终端等设置有音视频设备硬件的设备中，该系统的结构如图7所示，包括代理模块71和多个应用72；

代理模块71，用于响应于应用72对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给应用72。

基于本发明的发明构思，本发明实施例还提供一种多应用共享音视频设备的系统，能够实现上述多应用共享音视频设备的方法。该系统置可以设置在手机终端、电脑终端或PAD终端等设置有音视频设备硬件的设备中，该系统的结构如图8所示，包括操作系统81和安装于操作系统81上的多个应用82；

操作系统81，用于响应于应用82对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给应用82。

基于本发明的发明构思，本发明实施例还提供一种终端，其结构如图9所示，包括代理模块91和多个应用92；

代理模块91，用于响应于应用92对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据时，从音视频设备的预览数据流中截取所请求的音视频数据，将截取的音视频数据提供给应用92。

基于本发明的发明构思，本发明实施例还提供一种多路直播装置，能够实现上述多路直播方法。该装置可以设置在手机终端、电脑终端或PAD终端等设置有音视频设备硬件的设备中，该装置的结构如图10所示，包括截取模块101和通信模块102；

截取模块101，用于根据多个直播应用的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据；

通信模块102，用于将截取模块101截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。

基于本发明的发明构思，本发明实施例还提供一种多路直播系统，能够实现上述多路直播方法。该系统可以设置在手机终端、电脑终端或PAD终端等设置有音视频设备硬件的设备中，该系统的结构如图11所示，包括代理模块111、播放装置112和多个直播应用113；

代理模块111，用于根据多个直播应用113的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用113，接收直播应用113返回的处理后音视频数据；

播放装置112，用于同屏播放代理模块111发送的各直播应用113返回的处理后音视频数据。

基于本发明的发明构思，本发明实施例还提供一种多路直播系统，能够实现上述多路直播方法。该系统可以设置在手机终端、电脑终端或PAD终端等设置有音视频设备硬件的设备中，该系统的结构如图12所示，包括操作系统121和安装于操作系统121上的播放装置122和多个直播应用123；

操作系统121，用于根据多个直播应用123的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用123，接收直播应用123返回的处理后音视频数据；

播放装置122，用于同屏播放操作系统121发送的各直播应用123返回的处理后音视频数据。

基于本发明的发明构思，本发明实施例还提供一种多路直播终端，其结构如图13所示，包括代理模块131、播放装置132和多个直播应用133；

代理模块131，用于根据多个直播应用133的音视频数据获取请求，从音视频设备的预览数据流中截取请求的音视频数据，将截取的音视频数据提供给相应的直播应用133，接收直播应用133返回的处理后音视频数据；

播放装置132，用于同屏播放代理模块131发送的各直播应用133返回的处理后音视频数据。

关于上述实施例中的装置和系统，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

基于本发明的发明构思，本发明实施例还提供了一种非临时性计算机可读存储介质，其上存储有计算机指令，当该指令被处理器执行时实现上述多应用共享音视频设备的方法，或实现上述多路直播方法。

基于本发明的发明构思，本发明实施例还提供了一种计算机设备，包括存储器、处理器及存储于存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述多应用共享音视频设备的方法，或实现上述多路直播方法。

除非另外具体陈述，术语比如处理、计算、运算、确定、显示等等可以指一个或更多个处理或者计算系统、或类似设备的动作和/或过程，所述动作和/或过程将表示为处理系统的寄存器或存储器内的物理(如电子)量的数据操作和转换成为类似地表示为处理系统的存储器、寄存器或者其他此类信息存储、发射或者显示设备内的物理量的其他数据。信息和信号可以使用多种不同的技术和方法中的任何一种来表示。例如，在贯穿上面的描述中提及的数据、指令、命令、信息、信号、比特、符号和码片可以用电压、电流、电磁波、磁场或粒子、光场或粒子或者其任意组合来表示。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

本领域技术人员还应当理解，结合本文的实施例描述的各种说明性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地说明硬件和软件之间的可交换性，上面对各种说明性的部件、框、模块、电路和步骤均围绕其功能进行了一般地描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以变通的方式实现所描述的功能，但是，这种实现决策不应解释为背离本公开的保护范围。

结合本文的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或其组合。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质连接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。当然，处理器和存储介质也可以作为分立组件存在于用户终端中。

对于软件实现，本申请中描述的技术可用执行本申请所述功能的模块(例如，过程、函数等)来实现。这些软件代码可以存储在存储器单元并由处理器执行。存储器单元可以实现在处理器内，也可以实现在处理器外，在后一种情况下，它经由各种手段以通信方式耦合到处理器，这些都是本领域中所公知的。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

Claims (12)

1.一种多应用共享音视频设备的方法，其特征在于，包括：

设置于操作系统的应用层与框架层之间的代理层，响应于从所述框架层获取的应用对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据，当前需要获取音视频数据的操作请求有多个，且请求的音视频数据类型不同时，所述类型包括图片和视频，按预设的应用优先级规则确定请求的音视频数据类型的处理顺序，按所述处理顺序依次从音视频设备的预览数据流中截取相应类型的音视频数据，将截取的音视频数据提供给所述应用。

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

若根据所述操作请求、音视频设备当前的运行状态和预设的应用优先级规则，确定需要音视频设备执行操作指令时，或根据所述操作请求和音视频设备当前的运行状态确定需要音视频设备执行操作指令时，向音视频设备发送所述操作指令。

3.如权利要求2所述的方法，其特征在于，根据所述操作请求、音视频设备当前的运行状态和预设的应用优先级规则，确定需要音视频设备执行操作指令，具体包括：

若所述操作请求包含设置音视频设备的第一配置参数，判断所述操作请求包含的第一配置参数是否与所述音视频设备当前的第一配置参数一致；

若否，且根据预设的应用优先级规则，确定发送所述操作请求的应用优先级不低于音视频设备当前的第一配置参数对应的应用的优先级，确定需要音视频设备执行修改第一配置参数的操作指令。

4.如权利要求2所述的方法，其特征在于，根据所述操作请求和音视频设备当前的运行状态确定需要音视频设备执行操作指令，具体包括：

若所述操作请求包含设置音视频设备的第二配置参数，判断所述操作请求是否与所述音视频设备当前的第二配置参数相冲突；

若是，确定需要音视频设备执行修改第二配置参数的操作指令。

5.如权利要求4所述的方法，其特征在于，所述第二配置参数为预览数据流分辨率时，所述判断所述操作请求是否与所述音视频设备当前的第二配置参数相冲突，具体包括：

判断所述操作请求包含的分辨率是否大于所述音视频设备当前的预览数据流数据的分辨率；

若是，确定所述操作请求与所述音视频设备当前的预览数据流数据的分辨率相冲突。

6.如权利要求1～5任一项所述的方法，其特征在于，所述响应于应用对音视频设备的操作请求，具体包括：

代理模块从系统的框架层获取应用对音视频设备的操作请求，响应于获取到的所述操作请求。

7.一种多路直播方法，其特征在于，包括：

设置于操作系统的应用层与框架层之间的代理层，根据从所述框架层获取的多个直播应用的音视频数据获取请求，若请求的音视频数据类型不同，所述类型包括图片和视频，按预设的应用优先级规则确定请求的音视频数据类型的处理顺序，按所述处理顺序依次从音视频设备的预览数据流中截取相应类型的音视频数据，将截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；

将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。

8.一种多应用共享音视频设备的装置，其特征在于，所述装置设置于操作系统的应用层与框架层之间，包括确定模块、截取模块和通信模块；

所述确定模块，用于响应于所述通信模块从所述框架层获取到的应用对音视频设备的操作请求，根据所述操作请求确定是否需要获取音视频数据；

所述截取模块，用于当所述确定模块确定为是，当前需要获取音视频数据的操作请求有多个，且请求的音视频数据类型不同时，所述类型包括图片和视频，按预设的应用优先级规则确定请求的音视频数据类型的处理顺序，按所述处理顺序依次从音视频设备的预览数据流中截取相应类型的音视频数据；

通信模块，用于将所述截取模块截取的音视频数据提供给所述应用。

9.一种多应用共享音视频设备的系统，其特征在于，包括代理模块和多个应用，所述代理模块设置于操作系统的应用层与框架层之间；

所述代理模块，用于响应于从所述框架层获取的应用对音视频设备的操作请求，若根据所述操作请求确定需要获取音视频数据，当前需要获取音视频数据的操作请求有多个，且请求的音视频数据类型不同时，所述类型包括图片和视频，按预设的应用优先级规则确定请求的音视频数据类型的处理顺序，按所述处理顺序依次从音视频设备的预览数据流中截取相应类型的音视频数据，将截取的音视频数据提供给所述应用。

10.一种多路直播装置，其特征在于，所述多路直播装置设置于操作系统的应用层与框架层之间，包括截取模块和通信模块；

所述截取模块，用于根据从所述框架层获取的多个直播应用的音视频数据获取请求，若请求的音视频数据类型不同，所述类型包括图片和视频，按预设的应用优先级规则确定请求的音视频数据类型的处理顺序，按所述处理顺序依次从音视频设备的预览数据流中截取相应类型的音视频数据；

通信模块，用于将所述截取模块截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；将各直播应用返回的处理后音视频数据发送给播放装置，使得播放装置同屏播放各直播应用返回的处理后音视频数据。

11.一种多路直播系统，其特征在于，包括代理模块、播放装置和多个直播应用，所述代理模块设置于操作系统的应用层与框架层之间；

所述代理模块，用于根据从所述框架层获取的多个直播应用的音视频数据获取请求，若请求的音视频数据类型不同，所述类型包括图片和视频，按预设的应用优先级规则确定请求的音视频数据类型的处理顺序，按所述处理顺序依次从音视频设备的预览数据流中截取相应类型的音视频数据，将截取的音视频数据提供给相应的直播应用，接收所述直播应用返回的处理后音视频数据；

所述播放装置，用于同屏播放所述代理模块发送的各直播应用返回的处理后音视频数据。

12.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，当该指令被处理器执行时实现权利要求1～6任一项所述的多应用共享音视频设备的方法，或实现权利要求7所述的多路直播方法。

Images