具体实施方式
为了使本公开的目的、技术方案和优点更加清楚,下面将结合附图对本公开作进一步地详细描述,所描述的实施例不应视为对本公开的限制,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本公开保护的范围。
除非另有定义,本文所使用的所有的技术和科学术语与属于本公开的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述具体的实施例的目的,不是旨在限制本公开。
对本公开进行进一步详细说明之前,对本公开实施例中涉及的名词和术语进行说明,本公开实施例中涉及的名词和术语适用于如下的解释。
1)媒体文件,以容器(Box,也称为盒子)的方式存储进行编码的媒体数据(例如音频数据和视频数据中的至少一种)的文件,其中还包括用以表达媒体信息以保证媒体数据被正确解码的元数据。
例如,采用动态图像专家组(MPEG,Moving Picture Experts Group)-4封装格式封装媒体数据的形成的媒体文件被称为MP4文件。典型地,MP4文件中存储高级视频编码(AVC,Advanced Video Coding,即H.264)或MPEG-4(Part 2)规范编码的视频数据和高级音频编码(AAC,Advanced Audio Coding)规范编码的音频数据,当然不排除视频和音频的其他编码方式。
2)容器(Box),也称为盒子,由唯一的类型标识符和长度定义的面向对象的构件,参见图1,是本公开实施例提供的容器的一个可选的结构示意图,包括容器头部(BoxHeader)和容器数据(Box Data),其中填充有用于表达各种信息的二进制数据。
容器头部包括容量(size)和类型(type),容量指明了容器在媒体文件中所占用的长度,类型指明了容器的类型,参见图2,是本公开实施例提供的MP4文件的一个可选的封装结构示意图,MP4文件中涉及的基本容器类型包括文件类型容器(ftyp box)、元数据容器(moov box)和媒体数据容器(mdat box)。
容器数据部分可以存储具体的数据,此时容器称为“数据容器”,容器数据部分也可以进一步封装其他类型的容器,此时容器称为“容器的容器”。
3)轨道(Track),也称为流(Stream),媒体数据容器中按时间排序的相关的采样(Sample),对于媒体数据来说,轨道表示一个视频帧序列或一个音频帧序列,还可以包括与视频帧序列同步的字幕轨,同一轨道中的一组连续的采样称为块(Chunk)。
4)文件类型容器,媒体文件中用于存储文件的容量(即所占用字节的长度)和类型的容器,如图2所示,文件类型容器记为“ftyp box”,其中存储的二进制数据按照规范的字节长度描述了文件的类型和兼容性。
5)元数据容器,媒体文件中用于存储元数据(即描述媒体数据容器中存储的多媒体数据的数据)的容器,在MP4文件中的元数据容器中存储的二进制数据表达的信息称为媒体信息。
如图2所示,元数据容器的头部采用二进制数据表示容器的类型为“moov box”,容器数据部分封装用于存储MP4文件的总体信息的mvhd容器,是独立于MP4文件的,并且与MP4文件的播放相关,包括时长、创建时间和修改时间等。
媒体文件的媒体数据容器中可以包括对应多个轨道的子容器,例如音频轨道容器(audio track box)和视频轨道容器(video track box),在音频轨道容器和视频轨道容器的子容器中都包括了相应轨道的媒体数据的引用和描述,必要的子容器包括:用于描述轨道的特性和总体信息(如时长、宽高)的容器(记为tkhd box)、记录轨道的媒体信息(比如媒体类型和采样的信息)的容器(记为mdia box)。
就mdia box中封装的子容器而言,可以包括:记录轨道的相关属性和内容的容器(记为mdhd box),记录媒体的播放过程信息的容器(记为hdlr box),描述轨道中媒体数据的媒体信息的容器(记为minf box);minf box中又封装了用于解释如何定位媒体信息的子容器(记为dinf box)、以及用于记录轨道中采样的所有时间信息(解码时间/显示时间)、位置信息和编解码等信息的子容器(记为stbl box)。
参见图3,是本公开实施例提供的媒体文件中的媒体数据容器存储媒体数据的结构示意图,利用从stbl box中二进制数据所识别出的媒体信息,可以解释采样的时间、类型、容量以及在媒体数据容器中的位置,下面说明stbl box中的各个子容器。
stsd box包含了一个采样描述(sample description)表,根据不同的编码方案和存储数据的文件数目,每个媒体文件中可以有一个或多个描述表,通过描述表可以找到每个采样的描述信息,描述信息可以保证采样的正确的解码,不同的媒体类型存储不同的描述信息,例如,视频媒体而言描述信息就是图像的结构。
stts box存储了采样的时长信息,并提供表来映射时间(解码时间)和采样的序号,通过sttx box,可以定位媒体文件中任何时间的采样;stts box中还使用其他的表来映射采样的容量和指针,表中每个条目提供了在同一个时间偏移量里面连续的采样的序号,以及采样的偏移量,递增这些偏移量,可以建立一个完整的时间-采样的映射表,计算公式如下:
DT(n+1)=DT(n)+STTS(n) (1)
其中,STTS(n)是第n个采样的时长,DT(n)是第n个采样的显示时间,采样的排列是按照时间的顺序排序,这样偏移量永远是非负的,DT一般以0开始,以第i个采样的显示时间DT(i)为例,计算公式如下:
DT(i)=SUM(for j=0 to i-1 of delta(j)) (2)
所有偏移量的和是轨道中媒体数据的时长。
stss box记录了媒体文件中的关键帧的序号。
sts box记录了采样与存储采样的块的映射关系,通过表来映射采样的序号和块的序号之间的关系,通过查表可以找到包含指定采样的块。
stco box定义了每个块在轨道中的位置,位置采用在媒体数据容器的起始字节的偏移量、以及相对于所述起始字节的长度(即容量)表示。
stsz box记录了媒体文件中每个采样的容量(即大小)。
6)媒体数据容器,媒体文件中用于存储多媒体数据的容器,例如,在MP4文件中媒体数据容器,如图3所示,采样是媒体数据容器中存储的单位,存储在媒体文件的块中,块和样本的长度可不相同。
7)分段媒体文件,媒体文件经过分割形成的子文件,每个分段媒体文件能够被独立解码。
以MP4文件为例,MP4文件中的媒体数据根据关键帧分割,分割后的媒体数据与对应的元数据封装形成分段MP4(FMP4,Fragmented MP4)文件,每个FMP4文件中的元数据能够保证媒体数据被正确解码。
例如,在将如图2所示的MP4文件转换为多个FMP4文件时,参见图4,是本公开实施例提供的FMP4文件的一个可选的封装结构示意图,一个MP4文件可以转换为多个FMP4文件,每个FMP4文件包括三个基本的容器:moov容器、moof容器和mdat容器。
moov容器包括了MP4文件级别的元数据,用来描述FMP4文件所来源的MP4文件中的全部媒体数据,例如MP4文件的时长、创建时间和修改时间等。
moof容器存储了分段级别的元数据,用于描述所在的FMP4文件中封装的媒体数据,保证FMP4中的媒体数据能够被解码。
1个moof容器和1个mdat容器组成分段MP4文件的1个分段,1个分段MP4文件中可以包括1个或多个这样的分段,每个分段中封装的元数据保证分段中封装的媒体数据能够被独立解码。
8)媒体资源扩展(MSE,Media Source Extensions)接口,在网页中实现的面向播放器的接口,在网页中的加载期间通过浏览器的解释器解释、执行前端编程语言(例如JavaScript)而实现,向播放器提供调用超文本标记语言(HTML)媒体元素(Media Element)的播放媒体流的功能,例如使用视频元素<video>、以及音频元素<audio>来实现视频/音频的播放功能。
9)流媒体格式,把媒体数据封装为流媒体的媒体文件,媒体文件不必完整下载、不需要额外转码,即可被解码播放,即,原生地支持一边下载,一边播放的封装技术。典型的流媒体格式的文件包括:基于HTTP直播流(HLS,HTTP Live Streaming)技术的TS媒体文件分片,FLV(Flash Video)文件等。
10)非流媒体格式,把媒体数据封装为媒体文件、且媒体文件完整下载后才可以被解码播放的封装技术,典型的非流媒体格式的文件包括:MP4文件,视窗媒体视频(WMV,Windows Media Video)文件,高级串流格式(ASF,Advanced Streaming Format)文件等。
需要指出,MP4文件原生不支持流媒体形式的播放,但是通过在线转码后向播放器转码后的媒体流、或者部分下载的MP4文件的缺失部分填充无效的二进制数据(例如,在ftyp容器和moov容器完整下载的情况下,填充mdat容器的缺失部分以无效的二进制数据代替)也能实现一边下载一边播放的技术效果,本文中将这种原生不支持流媒体播放的文件的封装格式都称为非流媒体格式。
图5为本公开实施例提供的媒体播放过程中连接分配方法的一个可选的实现流程示意图,实现本公开实施例的终端设备通过应用于各种类型的播放器来实现媒体播放过程中连接分配方法,就终端设备而言,可以是台式机电脑和笔记本电脑等各种终端设备。
作为一个示例,播放器是嵌入浏览器(或者是内嵌浏览器的任意应用程序)所加载的网页中的HTML5(简称H5)播放器,使用面向前端的语言(例如JavaScript)实现,当浏览器加载用于媒体播放的网页时,播放器代码与网页元素一并被下载到浏览器,由于播放器采用面向前端的语言实现,因此不需要经过编译,而由浏览器直接解释、执行播放器代码即可在网页中实现播放器的功能,适应平台广泛,实现效率高。
作为另一个示例,播放器是用于播放媒体文件的应用程序,通过在终端设备中运行预先编译封装的安装包程序而安装到终端设备中。
如图5所示,对于本公开实施例中的媒体播放过程中连接分配方法的实现流程,将结合图5示出的步骤进行说明。
步骤501:播放器接收播放请求,其中,播放器将响应播放请求在网页中播放媒体数据。
在本公开实施例中,播放器可以通过内嵌的方式显示于网页的播放窗口中,也即播放请求是由网页中内嵌的播放器发起的。在实际应用中,播放器在网页中播放多个媒体文件时,则可以通过网页中的多个并发的播放窗口进行并行的播放。
在本公开实施例中,播放请求可以是播放器通过网页发起的基于超文本传输协议(HTTP,Hyper Text Transport Protocol)的请求,当然,播放请求还可以是其他类型的用于供播放器请求播放媒体文件的请求,例如播放器通过网页发起的基于安全套接层的超文本传输协议(HTTPS,Hyper Text Transfer Protocol over Secure Socket Layer)的请求,后者通过加密传输的方式可以避免数据在传输过程中被第三方截获和破解。
需要说明的是,本实施例中的在网页中播放的媒体数据,通常指的是多媒体数据;其中,所述多媒体数据可以包括视频、音频等能够在终端设备上通过网页播放的各种类型的数据。
步骤502:播放器根据播放请求的接收顺序,将所接收的播放请求存放于缓冲队列中进行排队。
其中,缓冲队列是独立于内嵌浏览器所加载的网页而存在的。当网页中内嵌的播放器发起的播放请求存在至少两个时,按照至少两个播放请求的接收顺序,将所接收的播放请求存放于缓冲队列中进行排队等待,以先入队列等待先分配的方式为播放请求分配相应的连接。
步骤503:播放器根据缓冲队列能够使用的并发连接数上限,以及接收顺序,为缓冲队列中的播放请求分配连接。
在本公开实施例中,为缓冲队列中的播放请求所分配的连接用于供所述播放器请求待播放的媒体数据。
这里,所述缓冲队列能够使用的并发连接数,可以用于表示缓冲队列能够同时使用的连接的数目,一般地,缓冲队列的并发连接数据上限未达到时,每个播放请求能够被分配一个连接,以从服务器请求媒体数据。其中,并发连接数可依据用户对网页中的业务的性能需求确定,例如,当用户对网页中的其他业务(如非视频播放或网页浏览)的延迟容忍程度较高时,则可配置的并发连接数的取值较某些业务的延迟容忍程度较低时更大的并发连接数取值。
在本公开实施例中,对于本步骤503中的播放器根据所述缓冲队列能够使用的并发连接数上限,以及接收顺序,为所述缓冲队列中的所述播放请求分配连接来说,可以采用如下方式来实现:当为所接收的播放请求分配的连接未达到所述并发连接数上限时,根据所述接收顺序,依次为所述缓冲队列中的播放请求分配连接,直至分配的连接的数量达到所述并发连接数上限。
举例来说,假设缓冲队列能够使用的并发连接数上限为4,而存放于缓冲队列中进行排队等待分配连接的播放请求的数量为3,若通过网页中内嵌的播放器发起的这三个播放请求分别为播放请求1、播放请求2和播放请求3,且接收这三个播放请求的接收顺序依次为播放请求1、播放请求2和播放请求3,也就是说,先将播放请求1存放于该缓冲队列中,然后将播放请求2存放于该缓冲队列中,最后将播放请求3存放于该缓冲队列中。此时,检测为所接收的播放请求分配的连接的数量是否达到该缓冲队列能够使用的并发连接数上限,显然,3小于4,即确定为所接收的播放请求分配的连接的数量未达到所述并发连接数上限,因此,本公开实施例采用先入先分配连接的策略,根据上述三个播放请求的接收顺序,先为缓冲队列中的播放请求1分配连接1,然后为播放请求2分配连接2,最后为播放请求3分配连接3,这样即可完成为缓冲队列中存放的所有播放请求分配相应的连接。
在本公开实施例中,对于本步骤503中的播放器根据所述缓冲队列能够使用的并发连接数上限,以及所述接收顺序,为缓冲队列中的所述播放请求分配连接来说,可以采用如下方式来实现:当为所接收的播放请求分配的连接达到所述并发连接数上限时,清除所述缓冲队列中释放连接的播放请求,以及根据所述接收顺序,为所述缓冲队列中的播放请求分配相应的连接,直至使得分配的连接的数量达到所述并发连接数上限。
举例来说,假设缓冲队列能够使用的并发连接数上限为3,而存放于缓冲队列中进行排队等待分配连接的播放请求的数量为5,若通过网页中内嵌的播放器发起的这五个播放请求分别为播放请求1、播放请求2、播放请求3、播放请求4和播放请求5,且接收这五个播放请求的接收顺序依次为播放请求1、播放请求2、播放请求3、播放请求4和播放请求5,也就是说,先将播放请求1存放于该缓冲队列中,然后将播放请求2、播放请求3和播放请求4依次存放于该缓冲队列中,最后将播放请求5存放于该缓冲队列中。此时,检测为所接收的播放请求分配的连接的数量是否达到该缓冲队列能够使用的并发连接数上限,显然,5大于3,即确定为所接收的播放请求分配的连接的数量超出设定的并发连接数上限,若采用相关技术的方案则由于并发连接数上限并不能满足为所有的播放请求分配相应连接,只能为播放请求1、播放请求2、播放请求3分配连接,从而导致出现网页无响应,以及有些媒体数据无法播放的问题。
而采用本公开实施例提供的技术方案,在确定为所接收的播放请求分配的连接的数量达到并发连接数上限时,若监测到缓冲队列中存在有播放请求1释放连接1,此时即可清除缓冲队列中释放连接1的播放请求1,以获得空闲的连接,进而为缓冲队列中排队等待的播放请求4和播放请求5分配空闲的连接,本公开实施例采用先入先分配连接的策略,根据播放请求4和播放请求5的接收顺序,则此时仅能为播放请求4分配连接,直至使得分配连接的数量达到所述并发连接数上限,并继续实时监测缓冲队列;而播放请求5将继续等待,直至缓冲队列中再次获得空闲的连接,则再为播放请求5分配相应的连接。
在本公开实施例中,并发连接数上限在所述播放器中通过属性开放接口静态配置;其中,所述并发连接数小于所述网页的并发连接数上限。
这里,并发连接数上限具有静态配置的属性。所述并发连接数上限通过在所述播放器中具有的开放接口进行静态配置,具体来说,所述并发连接数上限可以支持由播放器的开发方、或者运营视频的业务方通过属性开放接口进行静态配置。在本公开实施例中,所述缓冲队列能够使用的并发连接数上限大于或等于2,且小于或等于所述网页中的并发播放窗口的数量。
需要指出,并发连接数上限是根据网页中并发播放窗口的需求进行自适应配置的。本公开实施例中将并发连接数上限的最小值设置为2而不是1,主要是因为网页中会存在有两个播放窗口同时播放的情况,相对于并发连接数上限的最小值为1的情况而言,将并发连接数上限的最小值设置为2,能够避免出现后播放的播放窗口无响应(因为只有1个连接)而需要等待的情况,进而使两个播放窗口具有实时响应的性能。
这里,所述缓冲队列能够使用的并发连接数上限可以预先设定,其中,可根据操作系统的连接数配置规范进行设定,也可由播放器接收浏览器的关于并发连接数上限进行设定;当然,也可以由播放器自主设定,例如根据宿主设备的特征参数进行设定,或者根据网页的网络参数进行设定。下面对播放器根据宿主设备的特征参数进行设定的方案进行举例说明:首先,检测所述播放器的宿主设备的特征参数;然后,根据所述特征参数,动态确定适配所述宿主设备的性能的并发连接数上限。
这里,所述并发连接数上限为具有根据播放器的宿主设备的特征参数而动态自适应调整的属性,也即并发连接数上限为具有动态适应调整特性的上限。其中,对于根据所述特征参数,动态确定适配所述宿主设备的性能的并发连接数上限来说,可以采用如下方式来实现:当所述特征参数的变化符合变化条件时,确定适配变化幅度的并发连接数上限。
举例来说,当检测到播放器的宿主设备的特征参数所发生的变化出现明显的抖动时,可以根据抖动幅度适应调低缓冲队列能够使用的并发连接数上限;当检测到播放器的宿主设备的特征参数所发生的变化有明显的改善时,可以根据改善的量化幅度,来适应调高缓冲队列能够使用的并发连接数上限。
这里,对于调低或调高并发连接数上限的实现方式而言,可以是等比例调低或调高并发连接数上限,也可以是非等比例调低或调高并发连接数上限,本公开实施例在此不做具体限定。
下面以等比例调低或调高并发连接数上限为采用阶梯式的方式对并发连接数上限进行调整为例进行说明。假设缓冲队列能够使用的并发连接数上限的初始值为8,预先设定特征参数的抖动幅度每变化一次,并发连接数上限的初始值等比例的降低一个数值,当检测到播放器的宿主设备的特征参数所发生的变化出现明显的抖动,且抖动幅度由5变为3,可见,特征参数的抖动幅度变化了两次,相应地,可将并发连接数上限的初始值由8降低为6。预先设定特征参数改善的量化幅度每变化一次,并发连接数上限的初始值等比例的调高一个数值,当检测到播放器的宿主设备的特征参数所发生的变化有明显的改善时,且改善的量化幅度由2变为5,可见,特征参数的改善的量化幅度变化了三次,则可将并发连接数上限的初始值由8提高为11。
在本公开实施例中,针对播放器根据网页的网络参数进行设定的方案可以采用如下方式实现:检测所述网页的网络参数,根据所述网络参数,动态确定并发连接数上限。也就是说,具有动态适应调整特性的并发连接数上限还可以根据网页的网络参数设定。其中,所述网络参数可以包括浏览器能够使用的网络带宽、以及播放请求的网络延迟。
这里,以网络参数为浏览器能够使用的网络带宽为例,当网络带宽较高时,则取回媒体数据的延迟较小,因此,此时可以配置较带宽低时更小的并发连接数上限,即网络带宽与并发连接数上限是负相关的关系,也即网络带宽越高,并发连接数上限越小;网络带宽越低,并发连接数上限越大。
采用本公开实施例的技术方案,在网页中进行媒体播放时,将播放器的播放请求存放于缓冲队列中进行排队,并根据缓冲队列能够使用的并发连接数上限,以及播放请求的接收顺序,为缓冲队列中的播放请求分配相应的连接。这样,当网页中的同一页面上存在多个播放窗口时,可以有效提升内嵌播放器的网页的实时响应性能。
图6为本公开实施例提供的媒体播放过程中连接分配方法的另一个可选的实现流程示意图,该媒体播放过程中连接分配方法可以应用于各种类型的播放器,比如嵌入浏览器所加载的网页中的H5播放器或播放媒体文件的应用程序中;如图6所示,本公开实施例中的媒体播放过程中连接分配方法的具体实现流程,将结合图6示出的步骤进行说明。
步骤601:播放器接收播放请求。
步骤602:播放器根据播放请求的接收顺序,将所接收的播放请求存放于缓冲队列中进行排队。
步骤603:播放器检测为所接收的播放请求分配的连接是否达到并发连接数上限,当确定为所接收的播放请求分配的连接达到并发连接数上限时,则执行步骤604,否则,执行步骤605。
在本公开实施例中,所述缓冲队列能够使用的并发连接数上限大于或等于2,且小于或等于所述网页中的并发播放窗口的数量。
所述缓冲队列能够使用的并发连接数上限可以预先设定,其中,可根据操作系统的连接数配置规范进行设定,也可由播放器接收浏览器的关于并发连接数上限进行设定;当然,也可以由播放器自主设定,例如根据宿主设备的特征参数进行设定。
对于并发连接数上限由播放器根据宿主设备的特征参数进行设定来说,可以采用如下方式实现:检测所述播放器的宿主设备的特征参数;根据所述特征参数,动态确定适配所述宿主设备的性能的并发连接数上限。
其中,对于根据所述特征参数,动态确定适配所述宿主设备的性能的并发连接数上限来说,可以采用如下方式来实现:当所述特征参数的变化符合变化条件时,确定适配变化幅度的并发连接数上限。
举例来说,当检测到播放器的宿主设备的特征参数所发生的变化出现明显的抖动时,可以根据抖动幅度适应调低缓冲队列能够使用的并发连接数上限;当检测到播放器的宿主设备的特征参数所发生的变化有明显的改善时,可以根据改善的量化幅度,来适应调高缓冲队列能够使用的并发连接数上限。
在本公开实施例中,还可以由播放器根据网页的网络参数设定并发连接数上限。具体来说,检测网页的网络参数,根据网络参数动态确定并发连接数上限。其中,所述网络参数可以包括浏览器能够使用的网络带宽、以及播放请求的网络延迟。
以网络参数为网络带宽为例,当网络带宽较高时,则取回媒体数据的延迟较小,因此,此时可以配置较带宽低时更小的并发连接数上限,即网络带宽与并发连接数上限是负相关的关系,也即网络带宽越高,并发连接数上限越小;网络带宽越低,并发连接数上限越大。
步骤604:播放器清除缓冲队列中释放连接的播放请求,以及根据接收顺序,为缓冲队列中的播放请求分配相应的连接,直至分配的连接的数量达到并发连接数上限。
这里,由于在为所接收的播放请求分配的连接的数量达到并发连接数上限时,缓冲队列中可能仍然存放有未分配连接的播放请求,对于这些请求来说需要等待空闲的连接,因此,要实时监测缓冲队列中是否存在播放请求释放连接的情况,当监测到缓冲队列中有播放请求释放连接时,即可清除缓冲队列中释放连接的播放请求,以获得空闲的连接,进而采用先入先分配连接的策略,为缓冲队列中排队等待的播放请求分配空闲的连接,直至使得分配的连接的数量达到并发连接数上限,并继续实时监测缓冲队列。
步骤605:播放器根据接收顺序,依次为缓冲队列中的播放请求分配连接,直至分配的连接的数量达到并发连接数上限。
这里,可采用先入先分配连接的策略,根据播放请求的接收顺序,依次为缓冲队列中存放的所有播放请求分配相应的连接,直至使得分配的连接的数量达到并发连接数上限。
需要说明的是,本公开实施例记载的媒体文件可以是流媒体格式或非流媒体格式。
在一个实施例中,针对媒体文件是流媒体文件的情况,播放请求用于向服务器请求给定时段(用于接续播放器的实时的播放点)内的分段媒体文件,通过网页的媒体资源扩展接口发送到网页的媒体元素进行解码,从而实现媒体文件的连续播放。
作为示例,给定时段是在播放点之后的预加载时长,用于在播放点之后预加载部分的媒体文件,用以实现流畅的观看体验。给定时段的长度可以由播放器与网络参数或宿主设备的特征参数相适配,以实现终端资源和/或网络资源的优化利用。
作为示例,给定时段也可以是播放点之后的至少一个内容单元的长度,其中内容单元用于依据媒体文件中的人物、场景和情节等划分形成,用以表示媒体文件中内容的变化,以最大程度避免给定时段被用户跳跃从而消耗不必要流量。
在一个实施例中,针对媒体文件是非流媒体文件的情况,播放器通过确定媒体文件中接续实时的播放点的给定时段,进而确定媒体文件中对应给定时段的两个关键帧(关键帧的解码之间所界定的时段形成给定时段,或者,包括给定时段),进而从服务器请求两个关键帧之间的媒体数据,以此构造能够独立解码播放的分段媒体文件,通过网页的媒体资源扩展接口发送到网页的媒体元素进行解码,从而实现媒体文件的连续播放。
其中,播放点对应的时间是相对于媒体时间坐标系统(以媒体文件的播放开始时间为时间原点)的时间度量,给定时段的长度小于媒体文件的长度,例如媒体文件长度的预定比例5%,或者是设定的长度如10分钟。
下面继续对根据给定时段确定媒体文件中对应的两个关键帧的方式进行说明。
两个关键帧的解码时间为端点的时段包括给定时段,以两个关键帧之间的媒体数据作为对应给定时段的媒体数据,构造分段媒体文件进行播放,给定时段用于接续播放器的实时的播放点,从而实现媒体文件的连续播放。
就播放点而言,可以是通过连续播放媒体文件(也即在用户未加以干预的情况下自然播放)的方式到达的播放时刻,例如从第30分钟开始播放到第40分钟的播放点;也可以是通过跳转的方式(也即用户通过光标点击进度条实现页面跳转)到达媒体文件到达的播放时刻,例如原播放点为播放进度的20%,跳转后的播放点为播放进度的30%。
在一个实施例中,针对播放点是通过连续播放媒体文件的方式到达的播放时刻的情况,根据播放点对应的视频帧及给定时段的结束时间对应的视频帧为普通帧或关键帧的情况,说明确定两个关键帧(设为第一关键帧、以及解码时间是第一关键帧之后的第二关键帧)的实现方式。
情况1)播放点所对应的视频帧为普通帧,由于播放器以两个关键帧之间的媒体数据为基本播放加载单位,因此,播放点之后的首个关键帧(解码时间晚于播放点的关键帧中距离播放点最近的关键帧)之前的媒体数据为已加载的媒体数据,而为了避免重复获取该部分已加载的媒体数据,给定时段的两个关键帧中的第一关键帧为:媒体文件中解码时间在播放点之后的首个关键帧。
情况2)播放点所对应的视频帧为关键帧,给定时段的两个关键帧中的第一关键帧为:播放点对应的关键帧,即与给定时段的起始时间对齐的关键帧。
情况3)若给定时段的结束时间对应的视频帧为普通帧,由于播放器以两个关键帧之间的媒体数据为基本播放加载单位,因此,若将结束时间之前的关键帧作为给定时段的第二关键帧,则会漏获取该关键帧与结束时间对应的视频帧之间的媒体数据,则进行媒体文件播放的时候,结束时间之前的关键帧到结束时间对应的视频帧之间的媒体数据则无法实现播放而跳帧,因此,为了保证给定时段的结束时间对应的视频帧能够正常播放不会出现跳帧的情况,给定时段的两个关键帧中的第二关键帧为:解码时间晚于给定时段的结束时间的关键帧中距离结束时间最近的关键帧。
情况4)给定时段的结束时间对应的视频帧为关键帧,给定时段的两个关键帧中的第二关键帧为:解码时间对齐给定时段的结束时间的第二关键帧,即与给定时段的结束时间对齐的关键帧。
在上述情况1)和3)中,将跨越播放点的关键帧作为给定时段的媒体数据的端点,能够保证在播放点所对应的视频帧有足够的信息用于正确解码,不会出现因为缺少解码数据(即关键帧)而跳帧的情况。
在上述情况2)和4)中,对于播放点对齐关键帧的情况,则直接将对齐的关键帧作为给定时间段的媒体数据的端点,最大程度减少请求多余数据的情况,避免对连接和流量的占用导致网页中非媒体播放业务延迟的情况。
在另一个实施例中,针对播放点是通过跳转的方式到达的播放时刻的情况,根据播放点对应的视频帧及给定时段的结束时间对应的视频帧为普通帧或关键帧的情况,说明确定两个关键帧(设为第一关键帧、以及解码时间第一关键帧之后的第二关键帧)的实现方式。
情况1)播放点所对应的视频帧为普通帧,由于播放点是跳转到达的,因此播放点之前的首个关键帧、与播放点之间的媒体数据没有被加载,第一关键帧为:媒体文件中解码时间在播放点之前的首个关键帧,也即是媒体数据的时间(也即是,媒体信息所表示的序号与帧的解码时间的对应关系)中查找解码时间早于给定时段的起始时间、且距离起始时间最近的关键帧。
通过额外请求播放点至播放点之前的关键帧之间的媒体数据,可以保证跳转到任何播放点都能够正常解码,避免出现播放点对应普通帧时因为无法解码而跳帧的情况。
情况2)播放点所对应的视频帧为关键帧,第一关键帧为:播放点所对应的关键帧,也即是从媒体数据的时间(也即是媒体信息所表示的序号与帧的解码时间的对应关系)中查找的解码时间对齐给定时段的起始时间的关键帧。
情况3)给定时段的结束时间对应的视频帧为普通帧,第二关键帧为:解码时间晚于给定时段的结束时间、且距离结束时间最近的关键帧。
在上述情况1)和3)中,将跨越播放点的关键帧作为给定时段的媒体数据的端点,能够保证在播放点所对应的视频帧有足够的信息用于正确解码,不会出现因为缺少解码数据(即关键帧)而跳帧的情况。
情况4)给定时段的结束时间对应的视频帧为关键帧,第二关键帧为:解码时间对齐给定时段的结束时间的关键帧。
在情况2)和4)中,以对齐播放点的关键帧来界定待获取的媒体数据,在播放点能够被正确解码的前提下,最大程度减少了获取不必要的媒体数据的情况,减少了对连接和流量的占用,进而保证网页中非媒体播放业务的实时性。
下面说明根据媒体数据封装成分段媒体文件的实现方式,首先,将媒体数据和与媒体数据对应的元数据,封装成对应的分段媒体文件;然后,将分段媒体文件通过媒体资源扩展接口传递给网页的媒体元素进行播放。
在一个实施例中,播放器通过这样的方式封装成对应的分段媒体文件:从服务器获取媒体文件中对应给定时段的媒体数据,其中给定时段用于接续播放点,将根据媒体数据、以及描述所述媒体数据的元数据根据分段媒体文件的封装结构进行封装,形成能够用于被网页的媒体元素独立解码的分段媒体文件,继续结合图7说明。
参见图7,图7是本公开示例提供的封装分段媒体文件的一个可选的实现流程示意图,将结合图7示出的步骤进行说明。
步骤701:将表示分段媒体文件的类型和兼容性的数据,填充到分段媒体文件的文件类型容器中。
例如,以封装形成如图4时所示的封装结构的FMP4文件为例,在FMP4文件的文件类型容器即ftyp box的头部填充容器的类型和长度(表示ftyp box的整体长度),在ftyp box的数据部分填充生成表示文件类型为FMP4以及兼容协议的数据(二进制数据)。
步骤702:将表示所述分段媒体文件的文件级别的元数据,填充到所述分段媒体文件的元数据容器中。
在一个实施例中,根据向分段媒体文件的封装结构待填充的媒体数据,根据分段媒体文件中的元数据容器的嵌套结构,计算填充嵌套结构所需要的描述媒体数据的元数据。
仍以图4为例,计算表示FMP4文件的文件级别的元数据,并填充到FMP4的元数据容器(即moov box)中,在moov box中嵌套有mvhd、track和视频扩展(mvex,movie extend)三个容器。
步骤703:将所提取的媒体数据、以及描述所述媒体数据的元数据,对应填充到所述分段媒体文件的分段容器中的媒体数据容器、以及分段级别的元数据容器中。
在一个实施例中,分段媒体文件中可以封装有一个或多个分段(fragment),对于待填充的媒体数据而言,可以填充到分段媒体文件的一个或分段的媒体数据容器(即mdatbox)中,每个分段中封装有分段级别的元数据容器(记为moof box),其中填充的元数据用以描述分段中填充的媒体数据,使分段能够被独立解码。
结合图4,以将待填充的媒体数据填充到FMP4文件的封装结构的2个分段中为例,填充到每个分段媒体数据;计算需要填充到相应分段的分段级别的元数据容器(即moofbox)中的元数据,并对应填充到moof box嵌套的子容器中,其中在moof box的头部称为moof box,其中填充的二进制数据用于表示容器的类型为“moof box”,以及moof box的长度。
在步骤701至步骤703中填充数据到相应容器的一个实施例中,当执行填充操作时,调用类的写操作功能在所述子容器的内存缓冲区完成二进制数据的写入和合并,以及返回所述类的实例,所返回的实例用于合并所述子容器与具有嵌套关系的子容器的合并。
作为填充数据的一个示例,建立用于实现封装功能的类MP4,将分段媒体文件中的每个子容器封装为类Stream的静态方法;建立用于实现二进制数据操作功能的类(记为Stream),每个类Stream提供有一个内存缓冲区,用来保存待填充的二进制数据;通过Stream提供的静态方法,转换待填充的多字节十进制数据到二进制数据;通过类Stream的实例提供的写操作功能,在内存缓冲区完成待填充到子容器的二进制数据的合并以及填充;Stream提供的静态方法返回一个新的Stream实例,可以实现当前子容器与其他具有嵌套关系的子容器的合并。
下面继续说明播放器向网页的媒体资源扩展接口发送分段媒体文件给网页的媒体元素进行解码播放的过程。
参见图8,是本公开实施例提供的播放器通过网页的媒体资源扩展接口发送分段媒体文件给网页的媒体元素进行解码播放的流程示意图,将结合图8示出的步骤进行说明。
步骤801:播放器将分段媒体文件添加到媒体资源扩展接口中的媒体源对象。
参见图9,图9为本公开实施例提供的播放器通过网页的媒体资源扩展接口播放分段媒体文件的一个可选的示意图,当播放器在网页中播放窗口(播放器对应播放窗口)接收到媒体文件的播放事件时,播放器通过执行媒体资源扩展接口中封装的MediaSource方法创建媒体源(Media Source)对象;执行媒体资源扩展接口中封装的addSourceBuffer方法创建MediaSource对象的缓存,即源缓存(SourceBuffer)对象,一个MediaSource对象拥有一个或多个SourceBuffer对象,每个SourceBuffer对象可以用于对应网页中的一个播放窗口,用于接收窗口中待播放的分段媒体文件。
在媒体文件的播放过程中,播放器中的解析器(Parser)通过解析新获取的媒体数据,不断构造新的分段媒体文件,通过执行SourceBuffer对象的appendBuffer方法,添加分段媒体文件到同一个MediaSource对象的SourceBuffer对象。
步骤802:播放器调用媒体资源扩展接口创建对应媒体源对象的虚拟地址。
例如,播放器执行媒体资源扩展接口中封装的createObjectURL方法,创建对应媒体源对象的虚拟地址,即虚拟URL,其中封装有Blob类型的分段媒体文件。
此外,播放器将MediaSource对象设置为虚拟URL的源(src)属性,也就是将虚拟URL与网页中的媒体元素如video/audio元素绑定,这个过程也称为将媒体源对象关联到网页中的媒体元素。
步骤803:播放器向网页的媒体元素传递虚拟地址,虚拟地址用于供媒体元素以媒体源对象为数据源进行播放。
例如,播放器中包括有调用媒体元素播放虚拟URL的语句,例如:<audio>虚拟URL。当浏览器解释网页中嵌入的播放器中对应的语句时,使得浏览器的媒体元素到虚拟URL绑定的SourceBuffer对象中读取分段媒体文件,并解码播放。
下面,以播放器将MP4文件转换FMP4文件并通过媒体资源扩展接口在网页播放的过程进行说明。
参见图10,图10为本公开实施例提供的MP4文件转换为FMP4文件并通过媒体资源扩展接口播放的一个示意图,播放器基于媒体文件的真实地址(http://www.toutiao.com/a/b.mp4),从服务器请求获取MP4文件中部分的媒体数据,例如解码时间处于用于接续播放点的给定时段的数据。
播放器基于获取的媒体数据构造FMP4文件,然后添加到MediaSource对象对应的SourceBuffer对象,由于虚拟URL被绑定到MediaSource对象,因此播放器调用audio/video元素的代码被执行时,audio/video元素从MediaSource对象的SourceBuffer对象中读取被不断添加的新的FMP4文件并解码,实现媒体文件的连续播放。
采用本公开实施例的技术方案,在网页中进行媒体播放时,将播放器的播放请求存放于缓冲队列中进行排队,并根据缓冲队列能够使用的并发连接数上限,以及播放请求的接收顺序,为缓冲队列中的播放请求分配相应的连接。这样,当网页中的同一页面上存在多个播放窗口时,可以有效提升内嵌播放器的网页的实时响应性能。
为了实现上述媒体播放过程中连接分配方法,本公开实施例还提供了一种媒体播放过程中连接分配装置,所述媒体播放过程中连接分配装置可以为用于运行各种类型的播放器,比如嵌入浏览器所加载的网页中的H5播放器或播放媒体文件的应用程序,图11为本公开实施例提供的媒体播放过程中连接分配装置的一个可选的功能结构示意图;如图11所示,所述媒体播放过程中连接分配装置包括接收模块1101、存放模块1102和分配模块1103。下面对各模块进行详细说明。
所述接收模块1101,用于接收网页中内嵌的播放器发起的播放请求,其中,所述播放器在所述网页中播放媒体数据。
所述存放模块1102,用于根据所述播放请求的接收顺序,将所接收的播放请求存放于缓冲队列中进行排队。
所述分配模块1103,用于根据所述缓冲队列能够使用的并发连接数上限,以及所述接收顺序,为所述缓冲队列中的所述播放请求分配连接。
在本公开实施例中,所述连接用于供所述播放器请求待播放的媒体数据。播放器可以通过内嵌的方式显示于网页的播放窗口中,即播放请求是由网页中内嵌的播放器发起的。其中,播放器在网页中播放多个媒体文件时,则可以通过网页中的多个并发的播放窗口进行并行的播放;在网页中播放的媒体数据,可以包括视频、音频等能够在终端设备上通过网页播放的各种类型的数据。
在本公开实施例中,对于所述分配模块1103根据所述缓冲队列能够使用的并发连接数上限,以及所述接收顺序,为所述缓冲队列中的所述播放请求分配连接来说,可以采用如下方式来实现:当为所接收的播放请求分配的连接未达到所述并发连接数上限时,根据所述接收顺序,依次为所述缓冲队列中的播放请求分配连接,直至分配的连接的数量达到所述并发连接数上限。
在本公开实施例中,对于所述分配模块1103根据所述缓冲队列能够使用的并发连接数上限,以及所述接收顺序,为所述缓冲队列中的所述播放请求分配连接来说,还可以采用如下方式来实现:当为所接收的播放请求分配的连接达到所述并发连接数上限时,清除所述缓冲队列中释放连接的播放请求,以及根据所述接收顺序,为所述缓冲队列中的播放请求分配相应的连接,直至分配的连接的数量达到所述并发连接数上限。
这里,所述并发连接数上限在所述播放器中通过属性开放接口静态配置;其中,所述并发连接数小于所述网页的并发连接数上限。
举例来说,所述并发连接数上限通过在播放器中具有的开放接口进行静态配置,具体来说,所述并发连接数上限可以支持由播放器的开发方、或者运营视频的业务方通过属性开放接口进行静态配置。
这里,所述缓冲队列能够使用的并发连接数上限大于或等于2,且小于或等于所述网页中的并发播放窗口的数量。
这里,所述缓冲队列能够使用的并发连接数上限可以预先设定,其中,可根据操作系统的连接数配置规范进行设定,也可由播放器接收浏览器的关于并发连接数上限进行设定;当然,也可以由播放器自主设定,举例来说,可由播放器根据宿主设备的特征参数进行设定,也可由播放器根据网页的网络参数进行设定。
下面针对由播放器设定的方案进行说明,图12为本公开实施例提供的媒体播放过程中连接分配装置的另一个可选的功能结构示意图,如图12所示,该媒体播放过程中连接分配装置还可以包括:
检测模块1104,用于检测所述播放器的宿主设备的特征参数。
确定模块1105,用于根据所述特征参数,动态确定适配所述宿主设备的性能的并发连接数上限。
在本公开实施例中,对于所述确定模块1105根据所述特征参数,动态确定适配所述宿主设备的性能的并发连接数上限来说,可以采用如下方式来实现:当所述特征参数的变化符合变化条件时,确定适配变化幅度的并发连接数上限。
举例来说,当检测到播放器的宿主设备的特征参数所发生的变化出现明显的抖动时,可以根据抖动幅度适应调低缓冲队列能够使用的并发连接数上限;当检测到播放器的宿主设备的特征参数所发生的变化有明显的改善时,可以根据改善的量化幅度,来适应调高缓冲队列能够使用的并发连接数上限。
在本实施例中,所述检测模块1104,还用于检测所述网页的网络参数。
所述确定模块1105,还用于根据所述网络参数,动态确定并发连接数上限。
其中,所述网络参数可以包括浏览器能够使用的网络带宽、以及播放请求的网络延迟。
这里,以网络参数为网络带宽为例,当检测模块1104检测到网络带宽较高时,则取回媒体数据的延迟较小,因此,此时可以配置较带宽低时更小的并发连接数上限,即网络带宽与并发连接数上限是负相关的关系,也即网络带宽越高,并发连接数上限越小;网络带宽越低,并发连接数上限越大。
需要说明的是:上述实施例提供的媒体播放过程中连接分配装置在对媒体数据进行媒体播放控制时,仅以上述各程序模块的划分进行举例说明,在实际应用中,可以根据需要而将上述处理分配由不同的程序模块完成,即将媒体播放过程中连接分配装置的内部结构划分成不同的程序模块,以完成以上描述的全部或者部分处理。
在实际应用中,上述模块中的存放模块1102、分配模块1103、检测模块1104和确定模块1105均可由播放器上的中央处理器(CPU,Central Processing Unit)、微处理器(MPU,Micro Processor Unit)、数字信号处理器(DSP,Digital Signal Processor)、或现场可编程门阵列(FPGA,Field Programmable Gate Array)等实现;上述模块中的接收模块1101,在实际应用中可通过通信模组(包含:基础通信套件、操作系统、通信模块、标准化接口和协议等)及收发天线实现。
为了实现上述媒体播放过程中连接分配方法,本公开实施例还提供了一种媒体播放过程中连接分配装置的硬件结构。现在将参考附图描述实现本公开实施例的媒体播放过程中连接分配装置的硬件结构,该媒体播放过程中连接分配装置可以为运行各种类型的播放器,比如嵌入浏览器所加载的网页中的H5播放器或播放媒体文件的应用程序等。
下面对本公开实施例的媒体播放过程中连接分配装置的硬件结构做进一步说明,可以理解,图13仅仅示出了媒体播放过程中连接分配装置的示例性结构而非全部结构,根据需要可以实施图13示出的部分结构或全部结构。
参见图13,图13为本公开实施例提供的媒体播放过程中连接分配装置的一个可选的硬件结构示意图,在实际应用中可以用于前述的各种形式的播放器,图13所示的媒体播放过程中连接分配装置1300可以包括:至少一个处理器1301、存储器1302、用户接口1303和至少一个网络接口1304。媒体播放过程中连接分配装置1300中的各个组件通过总线系统1305耦合在一起。可以理解,总线系统1305用于实现这些组件之间的连接通信。总线系统1305除包括数据总线之外,还可以包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图13中将各种总线都标为总线系统1305。
其中,用户接口1303可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按钮、触感板或者触摸屏等。
可以理解,存储器1302可以是易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。
本公开实施例中的存储器1302用于存储各种类型的数据以支持媒体播放过程中连接分配装置1300的操作。这些数据的示例包括:用于在媒体播放过程中连接分配装置1300上操作的任何可执行指令,如可执行程序13021和操作系统13022,实现本公开实施例的媒体播放过程中连接分配方法的程序可以包含在可执行程序13021中。
本公开实施例提供的媒体播放过程中连接分配方法可以应用于处理器1301中,或者由处理器1301实现。处理器1301可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述媒体播放过程中连接分配方法的各步骤可以通过处理器1301中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1301可以是通用处理器、DSP,或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器1301可以实现或者执行本公开实施例中提供的媒体播放过程中连接分配方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本公开实施例所提供的媒体播放过程中连接分配方法的步骤,可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中,该存储介质位于存储器1302,处理器1301读取存储器1302中的信息,结合其硬件完成本公开实施例提供的媒体播放过程中连接分配方法的步骤。
在本实施例中,所述媒体播放过程中连接分配装置1300包括存储器1302,用于存储可执行指令;处理器1301,用于执行所述可执行指令时,实现本公开实施例提供的媒体播放过程中连接分配方法。
在示例性实施例中,本公开实施例还提供了一种存储介质,所述存储介质可为光盘、闪存或磁盘等存储介质,可选为非瞬间存储介质。其中,所述存储介质上存储有可执行指令,所述可执行指令被执行时实现本公开实施例提供的媒体播放过程中连接分配方法。
综上所述,本公开实施例具有以下有益效果:当网页中的同一页面上存在多个播放窗口时,不会因为这多个播放窗口大量占用连接而导致出现网页中的其他业务如网页浏览延迟或无响应的情况,以及媒体播放窗口延迟或无响应的情况,能够有效提升内嵌播放器的网页的实时响应性能,从而大大提高用户的观看体验。
本公开实施例所记载的各技术方案之间,在不冲突的情况下,可以任意组合。
以上所述,仅为本公开的具体实施方式,但本公开的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应以所述权利要求的保护范围为准。