一种流媒体文件处理方法及装置与流程

本申请涉及多媒体处理技术领域，更具体地说，涉及一种流媒体文件处理方法及装置。

背景技术：

随着智能手机等移动终端的普及，越来越多的用户习惯于通过移动终端来观看网络上的多媒体文件，例如在智能手机上观看视频网站提供的视频等。用户通过移动终端观看多媒体文件都是基于流媒体协议实现的，所谓流媒体是指采用流式传输的方式实现在线播放的媒体格式，通过流媒体协议能够实现边下载边播放的功能。

目前比较常见的流媒体协议主要有HLS协议(HTTP Live Streaming，HTTP流媒体协议)、RTSP协议(Real Time Streaming Protocol，实时传输流协议)、RTP协议(Real-time Transport Protocol，实时传输协议)、MMS协议(Microsoft Media Server Protocol，微软媒体服务器协议)等。现有的移动终端上的多媒体播放器大多都支持HLS协议和RTSP/RTP协议，但是却不支持MMS协议。因此，用户无法在移动终端上下载或观看MMS协议的多媒体文件。

技术实现要素：

有鉴于此，本申请提供了一种流媒体文件处理方法及装置，用于解决现有移动终端上的多媒体播放器不支持MMS协议，造成用户无法下载或观看MMS协议的多媒体文件的问题。

为了实现上述目的，现提出的方案如下：

一种流媒体文件处理方法，应用于移动终端，该方法包括：

响应目标流媒体文件下载请求，获取目标流媒体文件的统一资源定位符URL；

根据所述URL头部的模式信息，判断所述目标流媒体文件是否为MMS协议的流媒体文件；

若是，参考预置的模式信息与网络通信协议间的对应关系，将与所述URL头部的模式信息相对应的网络通信协议确定为目标网络通信协议；

利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

一种流媒体文件处理装置，应用于移动终端，该装置包括：

URL获取单元，用于响应目标流媒体文件下载请求，获取目标流媒体文件的统一资源定位符URL；

文件判断单元，用于根据所述URL头部的模式信息，判断所述目标流媒体文件是否为MMS协议的流媒体文件；

通信协议确定单元，用于在所述文件判断单元判断结果为是时，参考预置的模式信息与网络通信协议间的对应关系，将与所述URL头部的模式信息相对应的网络通信协议确定为目标网络通信协议；

文件数据拉取单元，用于利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

从上述的技术方案可以看出，本申请实施例提供的流媒体文件处理方法，应用于移动终端，在响应目标流媒体文件下载请求时，获取目标流媒体文件的URL，并根据URL头部的模式信息，判断目标流媒体文件是否为MMS协议的流媒体文件，如果是，则参考预置的模式信息与网络通信协议间的对应关系，确定与URL的模式信息对应的目标网络通信协议，进而利用目标网络通信协议从URL的域名地址指定的服务器中拉取目标流媒体文件数据。本申请通过流媒体文件的URL确定其是否为MMS协议的文件，在确定是的情况下，进一步参考预置的URL模式信息与网络通信协议间对应关系，确定与目标流媒体文件的URL模式信息对应的网络通信协议，进而可以按照该协议去拉取目标流媒体文件数据，在移动终端上实现了对MMS协议的流媒体文件的下载，方便了用户的使用。

附图说明

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

图1为本申请实施例公开的一种流媒体文件处理方法流程图；

图2为本申请实施例公开的另一种流媒体文件处理方法流程图；

图3为本申请实施例公开的又一种流媒体文件处理方法流程图；

图4为本申请实施例公开的又一种流媒体文件处理方法流程图；

图5为本申请实施例公开的又一种流媒体文件处理方法流程图；

图6为本申请实施例公开的一种流媒体文件处理装置结构示意图；

图7为本申请实施例公开的一种移动终端硬件结构示意图。

具体实施方式

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

本案发明人通过对现有移动终端上的多媒体播放器的研究，发现其不支持MMS协议的多媒体文件的播放，也即当用户想要在移动终端上观看某个MMS协议的多媒体文件时，现有移动终端上的播放器将出错，无法下载并播放MMS协议的多媒体文件。为此，本申请实施例提供了一种应用于移动终端的流媒体文件处理方法及流媒体文件处理装置，以解决上述问题。参见图1，图1为本申请实施例公开的一种流媒体文件处理方法流程图。

如图1所示，该方法包括：

步骤S100、响应目标流媒体文件下载请求，获取目标流媒体文件的URL；

本申请的方法可以是应用于移动终端的浏览器中，也可以是应用于移动终端的多媒体播放器中。以移动终端为手机进行说明，用户在手机浏览器中点击某个目标流媒体文件时，即可触发目标流媒体文件下载请求，由本申请 的流媒体文件处理装置获取目标流媒体文件的URL(Uniform Resource Locator，统一资源定位符)。

对于URL，互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。URL由模式(或称协议)部分和域名地址部分组成。模式部分位于头部，模式信息与域名地址信息之间一般通过“://”间隔，例如常见的百度URL为：https://www.baidu.com/，其中https为模式信息，www.baidu.com/为域名地址信息。

步骤S110、根据所述URL头部的模式信息，判断所述目标流媒体文件是否为MMS协议的流媒体文件，若是，执行步骤S120；

具体地，URL头部的模式信息为流媒体文件供应商侧的服务器所决定，服务器规定了该流媒体文件的流媒体协议，以及该流媒体协议所支持的网络通信协议。因此，本步骤中可以通过URL头部的模式信息来判断目标流媒体文件是否为MMS协议的流媒体文件。如果是移动终端所原本支持的其他类型协议，而非MMS协议，则按照现有流程处理。

步骤S120、参考预置的模式信息与网络通信协议间的对应关系，将与所述URL头部的模式信息相对应的网络通信协议确定为目标网络通信协议；

MMS协议的流媒体文件所在的服务器规定了该文件所支持的网络通信协议，移动终端只有以规定的网络通信协议才能够从服务器中获取该文件。而不同的MMS协议的流媒体所支持的网络通信协议也不尽相同，例如某些MMS协议的流媒体文件支持HTTP网络通信协议，某些支持TCP网络通信协议等。为此，可以在流媒体文件URL的模式信息中添加标识，标识出该流媒体文件所支持的网络通信协议。

本申请预置了模式信息与网络通信协议间的对应关系，在确定目标流媒体文件为MMS协议的流媒体文件时，查询与目标流媒体文件的模式信息对应的网络通信协议，确定为目标网络通信协议。

步骤S130、利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

具体地，目标流媒体文件URL的域名地址指定了该文件所在的服务器。利用上一步骤确定的目标网络通信协议，从URL域名地址所指定的服务器中获取目标流媒体文件数据。

本申请实施例提供的流媒体文件处理方法，应用于移动终端，在响应目标流媒体文件下载请求时，获取目标流媒体文件的URL，并根据URL头部的模式信息，判断目标流媒体文件是否为MMS协议的流媒体文件，如果是，则参考预置的模式信息与网络通信协议间的对应关系，确定与URL的模式信息对应的目标网络通信协议，进而利用目标网络通信协议从URL的域名地址指定的服务器中拉取目标流媒体文件数据。本申请通过流媒体文件的URL确定其是否为MMS协议的文件，在确定是的情况下，进一步参考预置的URL模式信息与网络通信协议间对应关系，确定与目标流媒体文件的URL模式信息对应的网络通信协议，进而可以按照该协议去拉取目标流媒体文件数据，在移动终端上实现了对MMS协议的流媒体文件的下载，方便了用户的使用。

参见图2，图2为本申请实施例公开的另一种流媒体文件处理方法流程图。

如图2所示，该方法包括：

步骤S200、响应目标流媒体文件下载请求，获取目标流媒体文件的URL；

步骤S210、解析所述URL，得到表征所述URL头部的模式信息的字符串；

通过解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干个字符串及符号组成，本实施例中可以以“://”作为标识，将“://”前面的字符串提取出来，作为表征URL模式信息的字符串。

步骤S220、判断所述字符串是否以MMS开头，若是，则执行步骤S230，若否，则执行步骤S240；

步骤S230、确定所述目标流媒体文件是MMS协议的流媒体文件，进一步执行步骤S250；

步骤S240、确定所述目标流媒体文件不是MMS协议的流媒体文件；

具体地，可以规定MMS协议的流媒体文件的URL的模式信息以“MMS”这几个字符开头。这样，如果发现目标流媒体文件的模式信息以“MMS”这几个字符开头，则确定其为MMS协议的流媒体文件。

步骤S250、参考预置的模式信息与网络通信协议间的对应关系，将与所述URL头部的模式信息相对应的网络通信协议确定为目标网络通信协议；

本申请预置了模式信息与网络通信协议间的对应关系，在确定目标流媒体文件为MMS协议的流媒体文件时，查询与目标流媒体文件的模式信息对应的网络通信协议，确定为目标网络通信协议。

步骤S260、利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

相比于上一实施例，本实施例中公开了一种依据URL模式信息判断文件是否为MMS协议的可实施方案。具体地，通过对URL进行解析，得到表征模式信息的字符串，若确定字符串以MMS开头，则确定其为MMS协议的流媒体文件。

在本申请的又一个实施例中，公开了又一种流媒体文件处理方法，参见图3，图3为本申请实施例公开的又一种流媒体文件处理方法流程图。

如图3所示，该方法包括：

步骤S300、响应目标流媒体文件下载请求，获取目标流媒体文件的URL；

步骤S310、解析所述URL，得到表征所述URL头部的模式信息的字符串；

通过解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干个字符串及符号组成，本实施例中可以以“://”作为标识，将“://”前面的字符串提取出来，作为表征URL模式信息的字符串。

步骤S320、判断所述字符串是否以MMS开头，若是，则执行步骤S330，若否，则执行步骤S340；

步骤S330、确定所述目标流媒体文件是MMS协议的流媒体文件，进一步执行步骤S350；

步骤S340、确定所述目标流媒体文件不是MMS协议的流媒体文件；

具体地，可以规定MMS协议的流媒体文件的URL的模式信息以“MMS”这几个字符开头。这样，如果发现目标流媒体文件的模式信息以“MMS”这几个字符开头，则确定其为MMS协议的流媒体文件。

步骤S350、判断所述字符串是否为MMSU、MMST、MMSH中的某一个，若是，执行步骤S360；

步骤S360、将与所述字符串对应的网络通信协议确定为目标网络通信协议；

其中与MMSU对应的网络通信协议为UDP协议(User Datagram Protocol，用户数据报协议)、与MMST对应的网络通信协议为TCP协议(Transmission Control Protocol，传输控制协议)、与MMSH对应的网络通信协议为HTTP协议(Hyper Text Transfer Protocol，超文本传送协议)。

步骤S370、利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

在本实施例中，规定了与MMSU对应的网络通信协议为用户数据报协议UDP协议、与MMST对应的网络通信协议为传输控制协议TCP协议、与MMSH对应的网络通信协议为超文本传送协议HTTP协议。因此，如果一个流媒体文件的URL的模式信息为MMSU，则代表该流媒体文件支持UDP网络通信协议，如果一个流媒体文件的URL的模式信息为MMST，则代表该流媒体文件支持TCP网络通信协议，以此类推。

当然，上述UDP、TCP和HTTP三种网络通信协议为现有比较成熟的通信协议，一般MMS协议的流媒体文件也仅仅是从上述三种网络通信协议中选择一种支持。因此，本实施例中仅规定了与上述三种通信协议对应的模式信息：MMSU、MMST和MMSH。如果后续出现支持其它网络通信协议的MMS流媒体文件，则可以设置对应的模式信息，本实施例不再赘述。

在本申请的又一个实施例中，进一步介绍了又一种流媒体文件处理方法，参见图4，图4为本申请实施例公开的又一种流媒体文件处理方法流程图。

如图4所示，该方法包括：

步骤S400、响应目标流媒体文件下载请求，获取目标流媒体文件的URL；

步骤S410、解析所述URL，得到表征所述URL头部的模式信息的字符串；

通过解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干个字符串及符号组成，本实施例中可以以“://”作为标识，将“://”前面的字符串提取出来，作为表征URL模式信息的字符串。

步骤S420、判断所述字符串是否以MMS开头，若是，则执行步骤S430，若否，则执行步骤S440；

步骤S430、确定所述目标流媒体文件是MMS协议的流媒体文件，进一步执行步骤S450；

步骤S440、确定所述目标流媒体文件不是MMS协议的流媒体文件；

具体地，可以规定MMS协议的流媒体文件的URL的模式信息以“MMS”这几个字符开头。这样，如果发现目标流媒体文件的模式信息以“MMS”这几个字符开头，则确定其为MMS协议的流媒体文件。

步骤S450、判断所述字符串是否为MMSU、MMST、MMSH中的某一个，若是，执行步骤S460，若否，执行步骤S480；

步骤S460、将与所述字符串对应的网络通信协议确定为目标网络通信协议；

其中与MMSU对应的网络通信协议为UDP协议(User Datagram Protocol，用户数据报协议)、与MMST对应的网络通信协议为TCP协议(Transmission Control Protocol，传输控制协议)、与MMSH对应的网络通信协议为HTTP协议(Hyper Text Transfer Protocol，超文本传送协议)。

步骤S470、利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据；

步骤S480、依次将所述UDP协议、所述TCP协议和所述HTTP协议作为目标网络通信协议；

步骤S490、依次尝试各目标网络通信协议，直至成功拉取目标流媒体文件数据。

具体地，依次利用各所述目标网络通信协议尝试从所述URL的域名地址部分所指定的服务器中拉取目标流媒体文件数据，直至成功拉取目标流媒体文件数据。

需要说明的是，某些情况下在制定MMS协议的流媒体文件的URL时，可能由于疏忽等问题，未在模式部分进行标记，而直接以MMS作为URL的模式信息。对于这种情况，本实施例中按照UDP协议、TCP协议、HTTP协议的顺序逐个尝试，直至成功拉取文件数据。

在本申请的又一个实施例中，进一步介绍了又一种流媒体文件处理方法，参见图5，图5为本申请实施例公开的又一种流媒体文件处理方法流程图。

如图5所示，该方法包括：

步骤S500、响应目标流媒体文件下载请求，获取目标流媒体文件的URL；

步骤S510、解析所述URL，得到表征所述URL头部的模式信息的字符串；

通过解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干个字符串及符号组成，本实施例中可以以“://”作为标识，将“://”前面的字符串提取出来，作为表征URL模式信息的字符串。

步骤S520、判断所述字符串是否以MMS开头，若是，则执行步骤S530，若否，则执行步骤S540；

步骤S530、确定所述目标流媒体文件是MMS协议的流媒体文件，进一步执行步骤S550；

步骤S540、确定所述目标流媒体文件不是MMS协议的流媒体文件；

具体地，可以规定MMS协议的流媒体文件的URL的模式信息以“MMS”这几个字符开头。这样，如果发现目标流媒体文件的模式信息以“MMS”这几个字符开头，则确定其为MMS协议的流媒体文件。

步骤S550、判断所述字符串是否以MMSU开头，若是，执行步骤S560，若否，执行步骤S570；

步骤S560、将与所述MMSU对应的用户数据报协议UDP协议确定为目标网络通信协议，顺序执行步骤S650；

步骤S570、判断所述字符串是否以MMST开头，若是，执行步骤S580，若否，执行步骤S590；

步骤S580、将与所述MMST对应的传输控制协议TCP协议确定为目标网络通信协议，顺序执行步骤S650；

步骤S590、判断所述字符串是否以MMSH开头，若是，执行步骤S600，若否，执行步骤S610；

步骤S600、将与所述MMSH对应的超文本传送协议HTTP协议确定为目标网络通信协议，顺序执行步骤S650；

步骤S610、尝试利用UDP协议拉取目标流媒体文件数据，判断是否成功，若是，结束，若否，执行步骤S620；

具体地，尝试利用UDP协议从URL的域名地址部分所指定的服务器中拉取目标流媒体文件数据。

步骤S620、尝试利用TCP协议拉取目标流媒体文件数据，判断是否成功，若是，结束，若否，执行步骤S630；

具体地，尝试利用TCP协议从URL的域名地址部分所指定的服务器中拉取目标流媒体文件数据。

步骤S630、尝试利用HTTP协议拉取目标流媒体文件数据，判断是否成功，若是，结束，若否，执行步骤S640；

具体地，尝试利用HTTP协议从URL的域名地址部分所指定的服务器中拉取目标流媒体文件数据。

步骤S640、尝试失败，报错；

步骤S650、利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

本实施例中介绍了一种依据模式信息确定网络通信协议，在无法确定时，按照一定顺序逐个尝试下载文件的过程。其中，步骤S550、S570和S590的执行顺序可以颠倒或者同时执行。同理，步骤S610-S630的执行顺序可以颠倒或者同时执行。

进一步可选的，在上述各个实施例的基础上，本申请在拉取目标流媒体文件数据之后，可以进一步创建并初始化解码器，然后对解码器解码后的目标流媒体文件数据进行播放。

下面对本申请实施例提供的流媒体文件处理装置进行描述，下文描述的流媒体文件处理装置与上文描述的流媒体文件处理方法可相互对应参照。

参见图6，图6为本申请实施例公开的一种流媒体文件处理装置结构示意图。

如图7所示，该装置包括：

URL获取单元61，用于响应目标流媒体文件下载请求，获取目标流媒体文件的统一资源定位符URL；

文件判断单元62，用于根据所述URL头部的模式信息，判断所述目标流媒体文件是否为MMS协议的流媒体文件；

通信协议确定单元63，用于在所述文件判断单元62判断结果为是时，参考预置的模式信息与网络通信协议间的对应关系，将与所述URL头部的模式信息相对应的网络通信协议确定为目标网络通信协议；

文件数据拉取单元64，用于利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

本申请实施例提供的流媒体文件处理装置，由文件判断单元通过流媒体文件的URL判断其是否为MMS协议的文件，在确定是的情况下，由通信协议确定单元参考预置的URL模式信息与网络通信协议间对应关系，确定与目标流媒体文件的URL模式信息对应的网络通信协议，进而由文件数据拉取单元按照该协议去拉取目标流媒体文件数据。使用本申请的流媒体文件处理装置，在移动终端上实现了对MMS协议的流媒体文件的下载，方便了用户的使用。

可选的，本申请实施例提供了上述文件判断单元的一种可选结构，文件判断单元可以包括：

URL解析单元，用于解析所述URL，得到表征所述URL头部的模式信息的字符串；

字符串判断单元，用于判断所述字符串是否以MMS开头，若是，则确定所述目标流媒体文件是MMS协议的流媒体文件，若否，则确定所述目标流媒体文件不是MMS协议的流媒体文件。

可选的，本申请实施例提供了上述通信协议确定单元的一种可选结构，通信协议确定单元可以包括：

第一通信协议确定子单元，用于判断所述字符串是否为MMSU、MMST、MMSH中的某一个；

第二通信协议确定子单元，用于在所述第一通信协议确定子单元判断结果为是时，将与所述字符串对应的网络通信协议确定为目标网络通信协议，其中与MMSU对应的网络通信协议为用户数据报协议UDP协议、与MMST对应的网络通信协议为传输控制协议TCP协议、与MMSH对应的网络通信协议为超文本传送协议HTTP协议。

可选的，本实施例提供了流媒体文件处理装置的另一种可选结构，该装置还可以进一步包括：

第三通信协议确定子单元，用于在所述第一通信协议确定子单元判断结果为否时，依次将所述UDP协议、所述TCP协议和所述HTTP协议作为目标网络通信协议；

所述文件数据拉取单元具体用于，依次利用各所述目标网络通信协议尝试从所述URL的域名地址部分所指定的服务器中拉取目标流媒体文件数据，直至成功拉取目标流媒体文件数据。

可选的，本实施例提供了流媒体文件处理装置的又一种可选结构，该装置还可以进一步包括：

解码器创建单元，用于利用拉取的目标流媒体文件数据，创建并初始化解码器；

媒体播放单元，用于对所述解码器解码后的目标流媒体文件数据进行播放。

本申请实施例还提供一种移动终端，包括上述所述的流媒体文件处理装置。对于流媒体文件处理装置的描述可参照上文对应部分描述，此处不再赘述。

对于移动终端的硬件结构，参见图7，图7为本申请实施例提供的移动终端的硬件结构示意图。如图7所示，该移动终端可以包括：

处理器1，通信接口2，存储器3，通信总线4，和显示屏5；

其中处理器1、通信接口2、存储器3和显示屏5通过通信总线4完成相互间的通信；

可选的，通信接口2可以为通信模块的接口，如GSM模块的接口；

处理器1，用于执行程序；

存储器3，用于存放程序；

程序可以包括程序代码，所述程序代码包括处理器的操作指令。

处理器1可能是一个中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。

存储器3可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

其中，程序可具体用于：

响应目标流媒体文件下载请求，获取目标流媒体文件的统一资源定位符URL；

根据所述URL头部的模式信息，判断所述目标流媒体文件是否为MMS协议的流媒体文件；

若是，参考预置的模式信息与网络通信协议间的对应关系，将与所述URL头部的模式信息相对应的网络通信协议确定为目标网络通信协议；

利用所述目标网络通信协议，从所述URL的域名地址所指定的服务器中拉取目标流媒体文件数据。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下， 在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。