一种多应用共同播放多媒体的方法及其装置与流程

本发明涉及多媒体播放领域，尤其涉及一种在终端多应用共同播放多媒体的方法及其装置。

背景技术：

随着计算机技术和网络技术的飞速发展，互联网和即时通信技术在人们的日常生活、工作、学习中发挥的作用越来越大，特别是移动互联网时代的到来，移动终端个体应用呈现百花齐放的态势，各种移动终端，特别是手机，已经远远不只作为通信工具，更成为娱乐、办公的必备产品。

在目前手机操作系统中(例如android)，不同应用可能都会尽量应用多种系统资源来更佳的提供服务，最常见的就是大多数应用都会调用音频设备来播放内容。然而不同的应用之间由于权限不同，并不具备相互管理的能力，只能是探测当前音频设备的使用情况，然后在设备未被使用时才播放自身内容，或者是直接调用音频设备播放自身内容，在这种情况下，有可能与其他应用正在播放的音频内容冲突，造成相互音频播放干扰。

现有技术1披露了一种网页中视频与音频共存时的交互方法和系统，能够在一定程度上避免视频音频播放的干扰。然而该方法是通过在接收到的视频打开指令或视频关闭指令时对网页中的音频和视频进行播放选择控制，也即是在同一个应用程序中放置不同音频冲突，并没有解决操作系统中不同应用间音频的“共存”的需求。

现有技术2披露了一种视频文件交互装置，允许将获取的视频文件中的音频替换为其他音频文件。可以看出该方案也仅仅是在一个应用内部改变音频输出的内容，无法解决不同应用间音频播放的“共存”问题。

现有技术3披露了一种音乐类app抢占播放的方法，在安卓系统代码中通过设置声音优先级的参数，可以解决声音冲突的播放优先级问题。例如当多个声音冲突时，系统会优先播放优先级高的声音。另外还有解决多音频同时播放的技术方案——soundpool，该技术支持同时播放多种声音，这些声音在系统开始时会加载到列表中，按照这些声音的id，可以调用这些声音。但是soundpool只适合播放需要反复播放且时间较短的声音，其最大申请内存空间仅仅只有1m，也即soundpool只能使用一些很短的声音片段，而不能播放歌曲或者游戏背景音乐。另外soundpool提供的pause和stop方法有些时候可能会使其他程序莫名其妙的终止；在停止播放方面，soundpool不会立即中止播放声音，而是把缓冲区里的数据播放完才会停下来，导致可能会存在多播放一秒钟的尴尬；在音频格式方面，soundpool对音频格式要求严格，对建议使用的ogg格式支持较好，然而使用非建议的音频格式时，在声音播放间隔较短的情况下会出现异常关闭的情况。由此可见，现有技术3同样无法解决背景音乐应用和网页视频之间同时播放的矛盾。

现有技术1：cn201410439144.7(申请日2014-08-29)，网页中音频与视频共存时的音频视频交互方法及系统。

现有技术2：cn201310024374.2(申请日2013-01-23)，一种视频交互方法、装置和系统。

现有技术3：google官方文档sharetheaudiofocus，(https://developer.android.com/guide/topics/media-apps/volume-and-earphones.html)

技术实现要素：

本发明要解决的技术问题在于，如何提供一种在移动终端中多个应用的播放共存时的交互方法和装置。

本发明一方面提出了一种终端多应用共同播放多媒体的方法，包括：

检测播放类应用状态；

当有播放类应用开始播放后，基于播放类应用状态的检测结果，根据预定策略或用户选择，控制是否允许开始播放的所述播放类应用的音视频输出。

优选地，在所述控制是否允许开始播放的所述播放类应用的音视频输出步骤前，在系统api级别获取所有播放类应用的通道信息。

优选地，仅在系统播放器资源足够的情况下，才允许播放类应用开始播放。

优选地，所述播放类应用包括音频播放应用、视频播放应用、音视频播放应用中的至少一种，所述通道信息包括音频通道信息、显示通道信息中的至少一种，所述控制是否允许开始播放的所述播放类应用的音视频输出包括分别控制每个播放类应用的音轨输出使能、视频显示窗口大小、视频显示窗口可见性中的至少一种。

本发明的另一方面提出了一种终端多应用共同播放多媒体的装置，包括：

状态检测部，用于检测播放类应用状态；

播放控制部，用于当有播放类应用开始播放后，基于播放类应用状态的检测结果，根据预定策略或用户选择，控制是否允许开始播放的所述播放类应用的音视频输出。

优选地，该装置还包括状态获取部，用于在系统api级别获取所有播放类应用的通道信息。

优选地，该装置还包括系统资源检测部，用于检测系统播放器资源是否足够。

优选地，所述播放类应用包括音频播放应用、视频播放应用、音视频播放应用中的至少一种，所述通道信息包括音频通道信息、显示通道信息中的至少一种，所述控制是否允许开始播放的所述播放类应用的音视频输出包括分别控制每个播放类应用的音轨输出使能、视频显示窗口大小、视频显示窗口可见性中的至少一种。

本发明利用系统内置的播放器管理系统，结合播放器底层接口获取的信息，获知当前的播放器音视频输出状态，并根据预设的或者动态的策略，调整每个正在播放的app的音视频输出通道。由于app都需要基于系统播放及显示相关api进行播放显示，采用这种方式，避免了app之间沟通协调的成本及使用混乱，具有很强的稳定性及很大的扩展性，同时也具有很高的效率。

此外，本发明根据需求动态控制音频的输出而不是根据音频预设的优先级来设置，也就是说即使是设了某个优先级的音频通道，它是可以根据需要输出或者关闭输出的，因而具有更高的灵活性，且易于实施，可以直接应用于产品，具有良好的市场前景。

附图说明

图1为本发明的多应用共同播放多媒体的方法的流程图。

图2为本发明的多应用共同播放多媒体的装置结构图。

图3为本发明的一种优选方法流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

随着移动互联网的日益发展，移动终端被越来越广泛地使用在人们的日常生活中。特别是近些年来，移动终端进入智能化时代，在移动终端中会安装一个操作系统，用以管理移动终端中的各种软硬件资源，其一个显著的特点是允许终端安装第三方软件，进而可以扩展移动终端的功能。

第三方软件，也被称为应用(app)，目前许多应用都会向用户播放多媒体内容，当多个应用同时被用户打开并且都期望播放自身的多媒体内容时就会出现冲突，具体表现为不同应用的音视频内容被同时播放，混杂在一起影响用户收听和观看，或者是不期望的应用的音频或视频被输出给用户，而期望的应用的音频或视频却无法输出。此时，用户只能选择关闭不期望的应用来避免干扰，而有时找到不期望的应用并将其关闭是件非常繁琐的事情。

为了避免上述问题，在本发明的一个实施方式中，提出一种终端多应用共同播放多媒体的方法，以解决上述问题的困扰。该方法流程如图1所示，包括：

s10：检测播放类应用状态。本发明中的播放类应用包括视频播放应用和/或音频播放应用，但也不仅限这些应用，凡是能够输出音频或视频的应用都适用于本发明。

对播放类应用状态的检测可以通过系统内置的播放器管理系统，结合播放器底层接口获取的信息，来获知当前的播放器音视频输出状态。例如，底层接口获取的信息可以是根据之前已经启动的系统底层播放器的状态输出，记录其音频和显示通道信息；系统内置的播放器管理系统在之前的专利cn106155828a中有描述，通过播放器内部的消息通知获取并发送到播放器管理系统从而获取底层接口信息。

s20：当有播放类应用开始播放后，基于播放类应用状态的检测结果，根据预定策略或用户选择，控制是否允许开始播放的所述播放类应用的音视频输出。

例如，对于音频通道，可以控制其是否mix到外部声音输出模块来实现控制是否允许开始播放的所述音频播放类应用的音频输出；对于显示通道，可以控制各显示层的显示顺序z-order(可见性)及各显示层中的视窗位置来实现控制是否允许开始播放的所述视频播放类应用的视频输出。z-order是图像处理中一个术语，表示多层显示通道的先后顺序，通过z-order，自动进行不同图层的显示隐藏处理，这些操作对app是透明的。

通过上述实施方式，可以在系统级别控制不同应用的输出使能，避免了应用之间沟通协调的成本及使用混乱，具有很强的稳定性及很大的扩展性，同时也具有很高的效率。此外，允许用户参与应用输出的使能，因此允许用户来决定输出多个应用中的哪个应用的音频或视频。

在一个优选实施方式中，在控制开始播放的播放类应用的输出使能之前，先在系统api级别获取所有播放类应用的通道信息。

在一个优选实施方式中，仅在系统播放器资源足够的情况下，才允许播放类应用开始播放。

在一个优选实施方式中，所述播放类应用包括音频播放应用或视频播放应用，所述通道信息包括音频通道信息或显示通道信息，所述控制是否允许开始播放的所述播放类应用的音视频输出包括分别控制每个播放类应用的音轨输出使能，或者视频显示窗口大小，或者视频显示的z-order。

另外，本发明还提供一种终端多应用共同播放多媒体的装置的实施方式。该装置如图2所示，包括：

状态检测部，用于检测播放类应用状态；

播放控制部，用于当有播放类应用开始播放后，基于播放类应用状态的检测结果，根据预定策略或用户选择，控制是否允许开始播放的所述播放类应用的音视频输出；

状态获取部，用于在系统api级别获取所有播放类应用的通道信息；

系统资源检测部，用于检测系统播放器资源是否足够。

下面讨论几种不同的预定策略。

在一个可能实施方式中，重点考虑音乐视频屏保存在的场景。在该场景中，当用户没有任何操作的情况下，等待若干时间进入视频屏保，同时可以启动后台音乐播放，这个时候启动了两个播放类应用，并且可以被系统播放器管理系统侦测到。对于这种情形，播放器管理系统可以根据应用名称判断出是在屏保界面，如果屏保应用有音频输出不加以控制，会和音乐输出一起混合，影响用户听音乐，这个时候根据预设的策略，为了优先保证后台音乐独立输出清晰的声音，可以调用音轨相关的底层api接口关闭屏保应用的音轨输出，这样自动操作后，保证了用户正常观看屏保视频画面和听后台音乐。

在一个可能实施方式中，重点考虑这样的场景，即已经开启一个音乐app进行后台播放后，又打开新的音乐app进行前台播放的情况。在该场景下，如果app不使用audiofocus，两个音轨会一起混合输出，干预用户正常听音乐，这个情形如图3所示可以有3个选择：1.根据播放的先后顺序，关闭先播放的音轨输出，只输出后来播放的音轨。2.根据用户设置，比如说某个应用播放优先，则保留优先级高的应用的音轨输出，关闭其余应用的音轨输出；或是判断后开启的app是否为纯音频播放，若是则保持原先音频app的播放，从而防止两个音轨混合。3.调用系统api判断app的可见性，关闭后台的音频播放。需要指出的是，由于本发明是在系统层级对音视频输出进行控制，因此避免了app使用的不规范带来的问题，并且可以动态，全局设置，对于使用场景有更好的扩展性。

在一个可能实施方式中，重点考虑某个应用靠边进行小窗视频播放时的场景。在该场景下，当某个应用靠边进行小窗视频播放时，如果播放新的视频应用，并且是大窗的，那么大小窗会有重叠，这种情形下，可以根据预设或者用户设定的大小窗谁在前的策略，由播放器管理系统调整两个应该的显示窗口的排列顺序z-order。通过这样的设置，避免了app使用不规范带来的视频遮挡等糟糕体验，并且可以全局，动态管理。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。