CN105611427B

CN105611427B - 音视频的播放控制方法及装置

Info

Publication number: CN105611427B
Application number: CN201610087774.1A
Authority: CN
Inventors: 张晓红
Original assignee: Qingdao Hisense Electronics Co Ltd
Current assignee: Hisense Visual Technology Co Ltd
Priority date: 2016-02-16
Filing date: 2016-02-16
Publication date: 2019-04-16
Anticipated expiration: 2036-02-16
Also published as: CN105611427A

Abstract

本发明实施例提供一种音视频的播放控制方法及装置，该方法包括：解析待播放音视频的类型码，在播放控件库中匹配上述类型码标识的上述至少一个播放控件，按照预设顺序加载上述至少一个播放控件，实现上述待播放音视频的播放，实现了通过组合至少一个播放控件的方式来实现音视频播放，其中，每个播放控件为音视频文件播放功能的一个元素，这样无需每个类型的音视频都配备一套完整的功能，节约了设备的软件系统资源，且便于移植，同时大大的提高了智能设备音视频播放的可扩展性。

Description

音视频的播放控制方法及装置

技术领域

本发明涉及音视频播放技术，尤其涉及一种音视频的播放控制方法及装置。

背景技术

随着各种智能设备的普及，智能电视也越来越多的出现在人们的生活中，使用智能电视，可以播放的音视频类型也越来越多。

现有技术中，智能电视播放不同类型的音视频都是采用分别定义的功能接口，由各种类型的音视频对应的接口各自实现播放功能。这些实现播放功能接口所对应的参数或者条件都以播放控件的形式集成到软件系统中，例如：实现数字视频广播(Digital VideoBroadcasting,简称DVB)的播放包括先锁频再启动音视频播放、然后进行认证中心(Certificate Authority，简称CA)解扰；实现互联网协议正交幅度调制(InternetProtocol Quadrature Amplitude Modulation，简称IPQAM)资源的播放包括先进行信令交互、通知服务器发码流、然后再锁频再启动音视频播放。

可见，采用现有技术进行音视频播放，不同类型的音视频都必须独立完成播放功能，相应地就需要给每个类型的音视频配备完成播放功能所需的播放控件的全套资源，而针对每个类型的音视频所需的播放控件在很多时候是重复的，相应的就会增加智能电视越来越多的音视频播放类型的开发难度，浪费较多的软件系统资源。

发明内容

本发明提供一种音视频的播放控制方法及装置，用于解决现有技术中的音视频播放功能浪费较多智能电视软件系统资源的问题。

本发明第一方面提供一种音视频的播放控制方法，包括：

解析待播放音视频文件的类型码，所述类型码包括所述待播放音视频文件播放过程中所需的至少一个播放控件的标识；

在播放控件库中匹配所述类型码标识的所述至少一个播放控件；

按照预设顺序加载所述至少一个播放控件，实现所述待播放音视频的播放。

本发明第二方面提供一种音视频的播放控制装置，包括：

解析模块，用于解析待播放音视频文件的类型码，所述类型码包括所述待播放音视频文件播放过程中所需的至少一个播放控件的标识；

匹配模块，用于在播放控件库中匹配所述类型码标识的所述至少一个播放控件；

播放模块，用于按照预设顺序加载所述至少一个播放控件，实现所述待播放音视频的播放。

本发明提供的音视频的播放控制方法及装置中，解析待播放音视频的类型码，在播放控件库中匹配上述类型码标识的上述至少一个播放控件，按照预设顺序加载上述至少一个播放控件，实现上述待播放音视频的播放，实现了通过组合至少一个播放控件的方式来实现音视频播放，这样无需每个类型的音视频都配备一套完整的播放功能，即不需要针对每种音视频播放类型都开发一套独立的播放控件的组合，节约了设备的软件系统资源，且便于移植，当增加新的音视频类型后，如果当前播放控件库中的控件可以满足需要，则只需要配置新的类型码即可；如果当前播放控件库中缺少某个播放控件，配置新的类型码的同时再添加缺少的播放控件，就可以实现新类型的音视频播放，大大的提高了智能设备音视频播放的可扩展性。

附图说明

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

图1为本发明提供的音视频的播放控制方法实施例一的流程示意图；

图2为本发明提供的音视频的播放控制装置实施例一的结构示意图；

图3为本发明提供的音视频的播放控制装置实施例二的结构示意图。

具体实施方式

本发明中的智能设备可以是智能电视、智能手机等智能设备，在此不作限制。

图1为本发明提供的音视频的播放控制方法实施例一的流程示意图，该方法的执行主体可以是上述智能设备，如图1所示，该方法包括：

S101、解析待播放音视频的类型码，该类型码包括上述待播放音视频文件播放过程中所需的至少一个播放控件的标识。

其中，每个播放控件可以为音视频文件播放功能的一个元素。

具体实现过程中，类型码可以是一个字符串，这个字符串的每一位可以用来标识不同的播放控件，整个字符串就可以标识至少一个播放控件的组合。但不以此为限。

S102、在播放控件库中匹配上述类型码标识的上述至少一个播放控件。

再划分好各种播放控件后，可以将这些播放控件都存储在播放控件库中，根据不同的类型码从播放控件库中匹配调用需要的播放控件。

不同类型的音视频在播放过程中，有些元素是可以复用的，这样通过将播放功能拆分成多个元素，使用的时候再自由组合。例如，DVB的播放包括先锁频再启动音视频播放、然后进行CA解扰，若采用本实施例的方法“先锁频再启动音视频播放”为一个播放控件，“CA解扰”为一个播放控件；IPQAM资源的播放包括先进行信令交互(例如：通知服务器发码流)、然后再锁频再启动音视频播放，若采用本实施例的方法“信令交互”为一个播放控件，“先锁频再启动音视频播放”为一个播放控件。可以看出这两种类型的音视频播放过程中“先锁频再启动音视频播放”这个播放控件就可以复用。

这样，无需每个类型的音视频都配备一套完整的功能，节约了资源，且便于移植。当增加新的音视频类型后，如果当前播放控件库中的控件可以满足需要，则只需要配置新的类型码即可；如果当前播放控件库中缺少某个播放控件，配置新的类型码的同时再添加缺少的播放控件，就可以实现新类型的音视频播放。

S103、按照预设顺序加载上述至少一个播放控件，实现上述待播放音视频的播放。

例如DVB对应控件的加载顺序为：“先锁频再启动音视频播放”→“CA解扰”，按照这个顺序加载完成后就可以实现DVB的播放。

本实施例中，解析待播放音视频的类型码，在播放控件库中匹配上述类型码标识的上述至少一个播放控件，按照预设顺序加载上述至少一个播放控件，实现上述待播放音视频的播放，实现了通过组合至少一个播放控件的方式来实现音视频播放，这样无需每个类型的音视频都配备一套完整的播放功能，即不需要针对每种音视频播放类型都开发一套独立的播放控件的组合，节约了设备的软件系统资源，且便于移植，当增加新的音视频类型后，如果当前播放控件库中的控件可以满足需要，则只需要配置新的类型码即可；如果当前播放控件库中缺少某个播放控件，配置新的类型码的同时再添加缺少的播放控件，就可以实现新类型的音视频播放，大大的提高了智能设备音视频播放的可扩展性。

另外，在上述实施例的基础上，本发明实施例中定义统一的接口，所有类型的音视频都通过这个统一的接口传输类型码以及待播放音视频资源，这样，标准化便于管理，也便于通过各播放控件组合来实现播放功能。无需再为每个类型的音视频预设独立的接口，以及独立实现播放功能。

相应地，上述解析待播放音视频的类型码之前，还包括：通过统一播放接口接收上述待播放音视频的类型码。接收到类型码之后再开始进行解析。

进一步地，上述至少一个播放控件中的每个播放控件属于不同的控件类型。

具体地，播放控件库中的播放控件会划分为不同的控件类型，对于每个待播放音视频来说，在所需的控件类型中会需要某个对应的播放控件。

举例说明，控件类型可以包括：播放信令类控件、数据接收类控件、解码器控制类控件以及未分类控件。未分类控件中包括不属于其它三类播放控件的其它所有剩余控件。当然，具体的分类并不以此为限，可以根据实现需要具体划分。

对于DVB来说，播放过程中需要解码器控制类控件，更具体地，需要解码器控制类控件中的“DVB播放控件”。“DVB播放控件”即可以表示“先锁频再启动音视频播放”。

每个控件类型下都包括至少一个播放控件，预先可以配置每个播放控件的标识，具体地：

1)A类型-播放信令类控件可以包括：基于传输控制协议(Transmission ControlProtocol，简称TCP)的实时流传输协议(Real Time Streaming Protocol，简称RTSP)信令(标识为A1)，基于用户数据报协议(User Datagram Protocol，简称UDP)的RTSP信令(标识为A2)，基于超文本传输协议(HyperText Transfer Protocol，简称HTTP)的信令(标识为A3)，……，An；

2)B类型-数据接收类控件可以包括：基于实时传输协议(Real-time TransportProtocol，简称RTP)的数据接收(标识为B1)，基于HTTP的数据接收(标识为B2)，……，Bm；

3)C类型-解码器控制类控件可以包括：互联网协议(Internet Protocol，简称IP)播放控件(标识为C1)、DVB播放控件(标识为C2)，本地播放控件(标识为C3)，……，Ch；

4)D类型-未分类控件可以包括：CA解扰控件(标识为D1)，……，Dk。

相应地，按照上述分类，类型码可以选用8位字符串，第1、2位标识播放信令类控件；第3、4位标识数据接收类控件；第5、6位标识解码器控制类控件；第7、8位标识未分类控件。需要说明的是，如果不需要某类型的控件，则对应的字符位标识为“0”。但并不以此为限，可以根据具体地控件分类灵活调整。

举例说明：基于IP模式的TCP的RTSP资源，其播放类型码定义为A1B1C100。表示该资源的播放需要A、B、C三类播放控件，具体包括：基于TCP的RTSP信令、基于RTP的数据接收以及IP播放控件，且不需要D类型的控件。加载这3个控件就可以实现基于IP模式的TCP的RTSP资源的播放；

基于IPQAM模式的TCP的RTSP资源，其播放类型码定义为A100C200。表示该资源的播放需要A、C两类播放控件，具体包括：基于TCP的RTSP信令、以及DVB播放控件，且不需要B、D类型的控件。加载这2个控件就可以实现基于IPQAM模式的TCP的RTSP资源的播放；

DVB资源，其播放类型码定义为0000C2D1。表示该资源的播放需要C、D两类播放控件，具体包括：DVB播放控件、以及CA解扰控件，且不需要A、B类型的控件。加载这2个控件就可以实现DVB资源的播放。

当然，并不以上述示例为限。

可选地，上述预设顺序为上述至少一个播放控件分别所属控件类型的顺序。例如，按照上述示例的A、B、C、D分类，预设顺序即可配置为A→B→C→D。具体实现过程中，如果不需要某个类型的控件，依然按照预设顺序排列，跳过不存在的类型即可。以DVB资源为例，不需要A、B类型的控件，那就先加载C类型控件“DVB播放控件”，再加载D类型控件“CA解扰控件”。具体通过定义统一接口实现上述方法的过程可以由下述程序体现，但仅作示例，不以此为限：

Player_StartPlay(播放类型码，播放参数)

{

解析播放类型码，得到各控件类型：A＝xxx，B＝xxx，C＝xxx，D＝xxx；

if(A＝＝A1){

A1控件加载；

}…..else if(A＝＝An){

An控件加载；；

}

if(B＝＝B1){

B1控件加载；

}…..

else if(B＝＝Bm){

Bm控件加载；

}

if(C＝＝C1){

C1控件加载；

}…..

else if(C＝＝Ch){

Ch控件加载；

}

if(D＝＝D1){

D1控件加载；

}…..

else if(D＝＝Dk){

Dk控件加载；

}

需要说明的是，传输类型码的同时也可以传输待播放音视频的播放参数，这里播放参数可以包括待播放音视频的：系统端标识、播放时间点、接收端口、音视频类型等，在此不做限制，可以根据具体情况具体设定。

图2为本发明提供的音视频的播放控制装置实施例一的结构示意图，如图2所示，该装置包括：解析模块201、匹配模块202以及播放模块203，其中：

解析模块201，用于解析待播放音视频文件的类型码，所述类型码包括所述待播放音视频文件播放过程中所需的至少一个播放控件的标识，其中，每个所述播放控件为音视频文件播放功能的一个元素。

匹配模块202，用于在播放控件库中匹配所述类型码标识的所述至少一个播放控件。

播放模块203，用于按照预设顺序加载所述至少一个播放控件，实现所述待播放音视频的播放。

可选地，所述至少一个播放控件中的每个所述播放控件属于不同的控件类型。

相应地，所述预设顺序为所述至少一个播放控件分别所属控件类型的顺序。

其中，上述控件类型可以包括：播放信令类控件、数据接收类控件、解码器控制类控件以及未分类控件。

图3为本发明提供的音视频的播放控制装置实施例二的结构示意图，如图3所示，在图2的基础上，该装置还可以包括：接收模块301，用于通过统一播放接口接收所述待播放音视频文件的类型码。

该装置用于执行前述方法实施例，其实现原理和技术效果类似，在此不再赘述。

本发明实施例还可以提供一种音视频的播放控制装置，包括存储器和处理器，存储器用于存储程序指令，处理器用于调用存储器中的程序指令执行前述方法实施例，其实现原理和技术效果与前述方法实施例类似，在此不再赘述。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取存储器(英文：Random Access Memory，简称：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims

1.一种音视频的播放控制方法，其特征在于，包括：

按照预设顺序加载所述至少一个播放控件，实现所述待播放音视频的播放；所述预设顺序为所述至少一个播放控件分别所属控件类型的顺序。

2.根据权利要求1所述的方法，其特征在于，所述至少一个播放控件中的每个所述播放控件属于不同的控件类型。

3.根据权利要求2所述的方法，其特征在于，所述控件类型包括：播放信令类控件、数据接收类控件、解码器控制类控件以及未分类控件。

4.根据权利要求1所述的方法，其特征在于，所述解析待播放音视频文件的类型码之前，还包括：

通过统一播放接口接收所述待播放音视频文件的类型码。

5.一种音视频的播放控制装置，其特征在于，包括：

播放模块，用于按照预设顺序加载所述至少一个播放控件，实现所述待播放音视频的播放；所述预设顺序为所述至少一个播放控件分别所属控件类型的顺序。

6.根据权利要求5所述的装置，其特征在于，所述至少一个播放控件中的每个所述播放控件属于不同的控件类型。

7.根据权利要求6所述的装置，其特征在于，所述控件类型包括：播放信令类控件、数据接收类控件、解码器控制类控件以及未分类控件。

8.根据权利要求5所述的装置，其特征在于，所述装置还包括：

接收模块，用于通过统一播放接口接收所述待播放音视频文件的类型码。