本申請涉及多媒體處理技術(shù)領(lǐng)域，更具體地說，涉及一種流媒體文件處理方法及裝置。

背景技術(shù)：

隨著智能手機等移動終端的普及，越來越多的用戶習慣于通過移動終端來觀看網(wǎng)絡上的多媒體文件，例如在智能手機上觀看視頻網(wǎng)站提供的視頻等。用戶通過移動終端觀看多媒體文件都是基于流媒體協(xié)議實現(xiàn)的，所謂流媒體是指采用流式傳輸?shù)姆绞綄崿F(xiàn)在線播放的媒體格式，通過流媒體協(xié)議能夠?qū)崿F(xiàn)邊下載邊播放的功能。

目前比較常見的流媒體協(xié)議主要有HLS協(xié)議(HTTP Live Streaming，HTTP流媒體協(xié)議)、RTSP協(xié)議(Real Time Streaming Protocol，實時傳輸流協(xié)議)、RTP協(xié)議(Real-time Transport Protocol，實時傳輸協(xié)議)、MMS協(xié)議(Microsoft Media Server Protocol，微軟媒體服務器協(xié)議)等?，F(xiàn)有的移動終端上的多媒體播放器大多都支持HLS協(xié)議和RTSP/RTP協(xié)議，但是卻不支持MMS協(xié)議。因此，用戶無法在移動終端上下載或觀看MMS協(xié)議的多媒體文件。

技術(shù)實現(xiàn)要素：

有鑒于此，本申請?zhí)峁┝艘环N流媒體文件處理方法及裝置，用于解決現(xiàn)有移動終端上的多媒體播放器不支持MMS協(xié)議，造成用戶無法下載或觀看MMS協(xié)議的多媒體文件的問題。

為了實現(xiàn)上述目的，現(xiàn)提出的方案如下：

一種流媒體文件處理方法，應用于移動終端，該方法包括：

響應目標流媒體文件下載請求，獲取目標流媒體文件的統(tǒng)一資源定位符URL；

根據(jù)所述URL頭部的模式信息，判斷所述目標流媒體文件是否為MMS協(xié)議的流媒體文件；

若是，參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，將與所述URL頭部的模式信息相對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

一種流媒體文件處理裝置，應用于移動終端，該裝置包括：

URL獲取單元，用于響應目標流媒體文件下載請求，獲取目標流媒體文件的統(tǒng)一資源定位符URL；

文件判斷單元，用于根據(jù)所述URL頭部的模式信息，判斷所述目標流媒體文件是否為MMS協(xié)議的流媒體文件；

通信協(xié)議確定單元，用于在所述文件判斷單元判斷結(jié)果為是時，參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，將與所述URL頭部的模式信息相對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

文件數(shù)據(jù)拉取單元，用于利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

從上述的技術(shù)方案可以看出，本申請實施例提供的流媒體文件處理方法，應用于移動終端，在響應目標流媒體文件下載請求時，獲取目標流媒體文件的URL，并根據(jù)URL頭部的模式信息，判斷目標流媒體文件是否為MMS協(xié)議的流媒體文件，如果是，則參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，確定與URL的模式信息對應的目標網(wǎng)絡通信協(xié)議，進而利用目標網(wǎng)絡通信協(xié)議從URL的域名地址指定的服務器中拉取目標流媒體文件數(shù)據(jù)。本申請通過流媒體文件的URL確定其是否為MMS協(xié)議的文件，在確定是的情況下，進一步參考預置的URL模式信息與網(wǎng)絡通信協(xié)議間對應關(guān)系，確定與目標流媒體文件的URL模式信息對應的網(wǎng)絡通信協(xié)議，進而可以按照該協(xié)議去拉取目標流媒體文件數(shù)據(jù)，在移動終端上實現(xiàn)了對MMS協(xié)議的流媒體文件的下載，方便了用戶的使用。

附圖說明

為了更清楚地說明本申請實施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對實施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)提供的附圖獲得其他的附圖。

圖1為本申請實施例公開的一種流媒體文件處理方法流程圖；

圖2為本申請實施例公開的另一種流媒體文件處理方法流程圖；

圖3為本申請實施例公開的又一種流媒體文件處理方法流程圖；

圖4為本申請實施例公開的又一種流媒體文件處理方法流程圖；

圖5為本申請實施例公開的又一種流媒體文件處理方法流程圖；

圖6為本申請實施例公開的一種流媒體文件處理裝置結(jié)構(gòu)示意圖；

圖7為本申請實施例公開的一種移動終端硬件結(jié)構(gòu)示意圖。

具體實施方式

下面將結(jié)合本申請實施例中的附圖，對本申請實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├绢I(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。

本案發(fā)明人通過對現(xiàn)有移動終端上的多媒體播放器的研究，發(fā)現(xiàn)其不支持MMS協(xié)議的多媒體文件的播放，也即當用戶想要在移動終端上觀看某個MMS協(xié)議的多媒體文件時，現(xiàn)有移動終端上的播放器將出錯，無法下載并播放MMS協(xié)議的多媒體文件。為此，本申請實施例提供了一種應用于移動終端的流媒體文件處理方法及流媒體文件處理裝置，以解決上述問題。參見圖1，圖1為本申請實施例公開的一種流媒體文件處理方法流程圖。

如圖1所示，該方法包括：

步驟S100、響應目標流媒體文件下載請求，獲取目標流媒體文件的URL；

本申請的方法可以是應用于移動終端的瀏覽器中，也可以是應用于移動終端的多媒體播放器中。以移動終端為手機進行說明，用戶在手機瀏覽器中點擊某個目標流媒體文件時，即可觸發(fā)目標流媒體文件下載請求，由本申請 的流媒體文件處理裝置獲取目標流媒體文件的URL(Uniform Resource Locator，統(tǒng)一資源定位符)。

對于URL，互聯(lián)網(wǎng)上的每個文件都有一個唯一的URL，它包含的信息指出文件的位置以及瀏覽器應該怎么處理它。URL由模式(或稱協(xié)議)部分和域名地址部分組成。模式部分位于頭部，模式信息與域名地址信息之間一般通過“://”間隔，例如常見的百度URL為：https://www.baidu.com/，其中https為模式信息，www.baidu.com/為域名地址信息。

步驟S110、根據(jù)所述URL頭部的模式信息，判斷所述目標流媒體文件是否為MMS協(xié)議的流媒體文件，若是，執(zhí)行步驟S120；

具體地，URL頭部的模式信息為流媒體文件供應商側(cè)的服務器所決定，服務器規(guī)定了該流媒體文件的流媒體協(xié)議，以及該流媒體協(xié)議所支持的網(wǎng)絡通信協(xié)議。因此，本步驟中可以通過URL頭部的模式信息來判斷目標流媒體文件是否為MMS協(xié)議的流媒體文件。如果是移動終端所原本支持的其他類型協(xié)議，而非MMS協(xié)議，則按照現(xiàn)有流程處理。

步驟S120、參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，將與所述URL頭部的模式信息相對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

MMS協(xié)議的流媒體文件所在的服務器規(guī)定了該文件所支持的網(wǎng)絡通信協(xié)議，移動終端只有以規(guī)定的網(wǎng)絡通信協(xié)議才能夠從服務器中獲取該文件。而不同的MMS協(xié)議的流媒體所支持的網(wǎng)絡通信協(xié)議也不盡相同，例如某些MMS協(xié)議的流媒體文件支持HTTP網(wǎng)絡通信協(xié)議，某些支持TCP網(wǎng)絡通信協(xié)議等。為此，可以在流媒體文件URL的模式信息中添加標識，標識出該流媒體文件所支持的網(wǎng)絡通信協(xié)議。

本申請預置了模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，在確定目標流媒體文件為MMS協(xié)議的流媒體文件時，查詢與目標流媒體文件的模式信息對應的網(wǎng)絡通信協(xié)議，確定為目標網(wǎng)絡通信協(xié)議。

步驟S130、利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

具體地，目標流媒體文件URL的域名地址指定了該文件所在的服務器。利用上一步驟確定的目標網(wǎng)絡通信協(xié)議，從URL域名地址所指定的服務器中獲取目標流媒體文件數(shù)據(jù)。

本申請實施例提供的流媒體文件處理方法，應用于移動終端，在響應目標流媒體文件下載請求時，獲取目標流媒體文件的URL，并根據(jù)URL頭部的模式信息，判斷目標流媒體文件是否為MMS協(xié)議的流媒體文件，如果是，則參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，確定與URL的模式信息對應的目標網(wǎng)絡通信協(xié)議，進而利用目標網(wǎng)絡通信協(xié)議從URL的域名地址指定的服務器中拉取目標流媒體文件數(shù)據(jù)。本申請通過流媒體文件的URL確定其是否為MMS協(xié)議的文件，在確定是的情況下，進一步參考預置的URL模式信息與網(wǎng)絡通信協(xié)議間對應關(guān)系，確定與目標流媒體文件的URL模式信息對應的網(wǎng)絡通信協(xié)議，進而可以按照該協(xié)議去拉取目標流媒體文件數(shù)據(jù)，在移動終端上實現(xiàn)了對MMS協(xié)議的流媒體文件的下載，方便了用戶的使用。

參見圖2，圖2為本申請實施例公開的另一種流媒體文件處理方法流程圖。

如圖2所示，該方法包括：

步驟S200、響應目標流媒體文件下載請求，獲取目標流媒體文件的URL；

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

通過解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干個字符串及符號組成，本實施例中可以以“://”作為標識，將“://”前面的字符串提取出來，作為表征URL模式信息的字符串。

步驟S220、判斷所述字符串是否以MMS開頭，若是，則執(zhí)行步驟S230，若否，則執(zhí)行步驟S240；

步驟S230、確定所述目標流媒體文件是MMS協(xié)議的流媒體文件，進一步執(zhí)行步驟S250；

步驟S240、確定所述目標流媒體文件不是MMS協(xié)議的流媒體文件；

具體地，可以規(guī)定MMS協(xié)議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣，如果發(fā)現(xiàn)目標流媒體文件的模式信息以“MMS”這幾個字符開頭，則確定其為MMS協(xié)議的流媒體文件。

步驟S250、參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，將與所述URL頭部的模式信息相對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

本申請預置了模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，在確定目標流媒體文件為MMS協(xié)議的流媒體文件時，查詢與目標流媒體文件的模式信息對應的網(wǎng)絡通信協(xié)議，確定為目標網(wǎng)絡通信協(xié)議。

步驟S260、利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

相比于上一實施例，本實施例中公開了一種依據(jù)URL模式信息判斷文件是否為MMS協(xié)議的可實施方案。具體地，通過對URL進行解析，得到表征模式信息的字符串，若確定字符串以MMS開頭，則確定其為MMS協(xié)議的流媒體文件。

在本申請的又一個實施例中，公開了又一種流媒體文件處理方法，參見圖3，圖3為本申請實施例公開的又一種流媒體文件處理方法流程圖。

如圖3所示，該方法包括：

步驟S300、響應目標流媒體文件下載請求，獲取目標流媒體文件的URL；

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

通過解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干個字符串及符號組成，本實施例中可以以“://”作為標識，將“://”前面的字符串提取出來，作為表征URL模式信息的字符串。

步驟S320、判斷所述字符串是否以MMS開頭，若是，則執(zhí)行步驟S330，若否，則執(zhí)行步驟S340；

步驟S330、確定所述目標流媒體文件是MMS協(xié)議的流媒體文件，進一步執(zhí)行步驟S350；

步驟S340、確定所述目標流媒體文件不是MMS協(xié)議的流媒體文件；

具體地，可以規(guī)定MMS協(xié)議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣，如果發(fā)現(xiàn)目標流媒體文件的模式信息以“MMS”這幾個字符開頭，則確定其為MMS協(xié)議的流媒體文件。

步驟S350、判斷所述字符串是否為MMSU、MMST、MMSH中的某一個，若是，執(zhí)行步驟S360；

步驟S360、將與所述字符串對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

其中與MMSU對應的網(wǎng)絡通信協(xié)議為UDP協(xié)議(User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議)、與MMST對應的網(wǎng)絡通信協(xié)議為TCP協(xié)議(Transmission Control Protocol，傳輸控制協(xié)議)、與MMSH對應的網(wǎng)絡通信協(xié)議為HTTP協(xié)議(Hyper Text Transfer Protocol，超文本傳送協(xié)議)。

步驟S370、利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

在本實施例中，規(guī)定了與MMSU對應的網(wǎng)絡通信協(xié)議為用戶數(shù)據(jù)報協(xié)議UDP協(xié)議、與MMST對應的網(wǎng)絡通信協(xié)議為傳輸控制協(xié)議TCP協(xié)議、與MMSH對應的網(wǎng)絡通信協(xié)議為超文本傳送協(xié)議HTTP協(xié)議。因此，如果一個流媒體文件的URL的模式信息為MMSU，則代表該流媒體文件支持UDP網(wǎng)絡通信協(xié)議，如果一個流媒體文件的URL的模式信息為MMST，則代表該流媒體文件支持TCP網(wǎng)絡通信協(xié)議，以此類推。

當然，上述UDP、TCP和HTTP三種網(wǎng)絡通信協(xié)議為現(xiàn)有比較成熟的通信協(xié)議，一般MMS協(xié)議的流媒體文件也僅僅是從上述三種網(wǎng)絡通信協(xié)議中選擇一種支持。因此，本實施例中僅規(guī)定了與上述三種通信協(xié)議對應的模式信息：MMSU、MMST和MMSH。如果后續(xù)出現(xiàn)支持其它網(wǎng)絡通信協(xié)議的MMS流媒體文件，則可以設(shè)置對應的模式信息，本實施例不再贅述。

在本申請的又一個實施例中，進一步介紹了又一種流媒體文件處理方法，參見圖4，圖4為本申請實施例公開的又一種流媒體文件處理方法流程圖。

如圖4所示，該方法包括：

步驟S400、響應目標流媒體文件下載請求，獲取目標流媒體文件的URL；

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

通過解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干個字符串及符號組成，本實施例中可以以“://”作為標識，將“://”前面的字符串提取出來，作為表征URL模式信息的字符串。

步驟S420、判斷所述字符串是否以MMS開頭，若是，則執(zhí)行步驟S430，若否，則執(zhí)行步驟S440；

步驟S430、確定所述目標流媒體文件是MMS協(xié)議的流媒體文件，進一步執(zhí)行步驟S450；

步驟S440、確定所述目標流媒體文件不是MMS協(xié)議的流媒體文件；

具體地，可以規(guī)定MMS協(xié)議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣，如果發(fā)現(xiàn)目標流媒體文件的模式信息以“MMS”這幾個字符開頭，則確定其為MMS協(xié)議的流媒體文件。

步驟S450、判斷所述字符串是否為MMSU、MMST、MMSH中的某一個，若是，執(zhí)行步驟S460，若否，執(zhí)行步驟S480；

步驟S460、將與所述字符串對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

其中與MMSU對應的網(wǎng)絡通信協(xié)議為UDP協(xié)議(User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議)、與MMST對應的網(wǎng)絡通信協(xié)議為TCP協(xié)議(Transmission Control Protocol，傳輸控制協(xié)議)、與MMSH對應的網(wǎng)絡通信協(xié)議為HTTP協(xié)議(Hyper Text Transfer Protocol，超文本傳送協(xié)議)。

步驟S470、利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)；

步驟S480、依次將所述UDP協(xié)議、所述TCP協(xié)議和所述HTTP協(xié)議作為目標網(wǎng)絡通信協(xié)議；

步驟S490、依次嘗試各目標網(wǎng)絡通信協(xié)議，直至成功拉取目標流媒體文件數(shù)據(jù)。

具體地，依次利用各所述目標網(wǎng)絡通信協(xié)議嘗試從所述URL的域名地址部分所指定的服務器中拉取目標流媒體文件數(shù)據(jù)，直至成功拉取目標流媒體文件數(shù)據(jù)。

需要說明的是，某些情況下在制定MMS協(xié)議的流媒體文件的URL時，可能由于疏忽等問題，未在模式部分進行標記，而直接以MMS作為URL的模式信息。對于這種情況，本實施例中按照UDP協(xié)議、TCP協(xié)議、HTTP協(xié)議的順序逐個嘗試，直至成功拉取文件數(shù)據(jù)。

在本申請的又一個實施例中，進一步介紹了又一種流媒體文件處理方法，參見圖5，圖5為本申請實施例公開的又一種流媒體文件處理方法流程圖。

如圖5所示，該方法包括：

步驟S500、響應目標流媒體文件下載請求，獲取目標流媒體文件的URL；

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

通過解析URL，可以得到表征URL模式信息的字符串。一般性的，URL由若干個字符串及符號組成，本實施例中可以以“://”作為標識，將“://”前面的字符串提取出來，作為表征URL模式信息的字符串。

步驟S520、判斷所述字符串是否以MMS開頭，若是，則執(zhí)行步驟S530，若否，則執(zhí)行步驟S540；

步驟S530、確定所述目標流媒體文件是MMS協(xié)議的流媒體文件，進一步執(zhí)行步驟S550；

步驟S540、確定所述目標流媒體文件不是MMS協(xié)議的流媒體文件；

具體地，可以規(guī)定MMS協(xié)議的流媒體文件的URL的模式信息以“MMS”這幾個字符開頭。這樣，如果發(fā)現(xiàn)目標流媒體文件的模式信息以“MMS”這幾個字符開頭，則確定其為MMS協(xié)議的流媒體文件。

步驟S550、判斷所述字符串是否以MMSU開頭，若是，執(zhí)行步驟S560，若否，執(zhí)行步驟S570；

步驟S560、將與所述MMSU對應的用戶數(shù)據(jù)報協(xié)議UDP協(xié)議確定為目標網(wǎng)絡通信協(xié)議，順序執(zhí)行步驟S650；

步驟S570、判斷所述字符串是否以MMST開頭，若是，執(zhí)行步驟S580，若否，執(zhí)行步驟S590；

步驟S580、將與所述MMST對應的傳輸控制協(xié)議TCP協(xié)議確定為目標網(wǎng)絡通信協(xié)議，順序執(zhí)行步驟S650；

步驟S590、判斷所述字符串是否以MMSH開頭，若是，執(zhí)行步驟S600，若否，執(zhí)行步驟S610；

步驟S600、將與所述MMSH對應的超文本傳送協(xié)議HTTP協(xié)議確定為目標網(wǎng)絡通信協(xié)議，順序執(zhí)行步驟S650；

步驟S610、嘗試利用UDP協(xié)議拉取目標流媒體文件數(shù)據(jù)，判斷是否成功，若是，結(jié)束，若否，執(zhí)行步驟S620；

具體地，嘗試利用UDP協(xié)議從URL的域名地址部分所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

步驟S620、嘗試利用TCP協(xié)議拉取目標流媒體文件數(shù)據(jù)，判斷是否成功，若是，結(jié)束，若否，執(zhí)行步驟S630；

具體地，嘗試利用TCP協(xié)議從URL的域名地址部分所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

步驟S630、嘗試利用HTTP協(xié)議拉取目標流媒體文件數(shù)據(jù)，判斷是否成功，若是，結(jié)束，若否，執(zhí)行步驟S640；

具體地，嘗試利用HTTP協(xié)議從URL的域名地址部分所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

步驟S640、嘗試失敗，報錯；

步驟S650、利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

本實施例中介紹了一種依據(jù)模式信息確定網(wǎng)絡通信協(xié)議，在無法確定時，按照一定順序逐個嘗試下載文件的過程。其中，步驟S550、S570和S590的執(zhí)行順序可以顛倒或者同時執(zhí)行。同理，步驟S610-S630的執(zhí)行順序可以顛倒或者同時執(zhí)行。

進一步可選的，在上述各個實施例的基礎(chǔ)上，本申請在拉取目標流媒體文件數(shù)據(jù)之后，可以進一步創(chuàng)建并初始化解碼器，然后對解碼器解碼后的目標流媒體文件數(shù)據(jù)進行播放。

下面對本申請實施例提供的流媒體文件處理裝置進行描述，下文描述的流媒體文件處理裝置與上文描述的流媒體文件處理方法可相互對應參照。

參見圖6，圖6為本申請實施例公開的一種流媒體文件處理裝置結(jié)構(gòu)示意圖。

如圖7所示，該裝置包括：

URL獲取單元61，用于響應目標流媒體文件下載請求，獲取目標流媒體文件的統(tǒng)一資源定位符URL；

文件判斷單元62，用于根據(jù)所述URL頭部的模式信息，判斷所述目標流媒體文件是否為MMS協(xié)議的流媒體文件；

通信協(xié)議確定單元63，用于在所述文件判斷單元62判斷結(jié)果為是時，參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，將與所述URL頭部的模式信息相對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

文件數(shù)據(jù)拉取單元64，用于利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

本申請實施例提供的流媒體文件處理裝置，由文件判斷單元通過流媒體文件的URL判斷其是否為MMS協(xié)議的文件，在確定是的情況下，由通信協(xié)議確定單元參考預置的URL模式信息與網(wǎng)絡通信協(xié)議間對應關(guān)系，確定與目標流媒體文件的URL模式信息對應的網(wǎng)絡通信協(xié)議，進而由文件數(shù)據(jù)拉取單元按照該協(xié)議去拉取目標流媒體文件數(shù)據(jù)。使用本申請的流媒體文件處理裝置，在移動終端上實現(xiàn)了對MMS協(xié)議的流媒體文件的下載，方便了用戶的使用。

可選的，本申請實施例提供了上述文件判斷單元的一種可選結(jié)構(gòu)，文件判斷單元可以包括：

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

字符串判斷單元，用于判斷所述字符串是否以MMS開頭，若是，則確定所述目標流媒體文件是MMS協(xié)議的流媒體文件，若否，則確定所述目標流媒體文件不是MMS協(xié)議的流媒體文件。

可選的，本申請實施例提供了上述通信協(xié)議確定單元的一種可選結(jié)構(gòu)，通信協(xié)議確定單元可以包括：

第一通信協(xié)議確定子單元，用于判斷所述字符串是否為MMSU、MMST、MMSH中的某一個；

第二通信協(xié)議確定子單元，用于在所述第一通信協(xié)議確定子單元判斷結(jié)果為是時，將與所述字符串對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議，其中與MMSU對應的網(wǎng)絡通信協(xié)議為用戶數(shù)據(jù)報協(xié)議UDP協(xié)議、與MMST對應的網(wǎng)絡通信協(xié)議為傳輸控制協(xié)議TCP協(xié)議、與MMSH對應的網(wǎng)絡通信協(xié)議為超文本傳送協(xié)議HTTP協(xié)議。

可選的，本實施例提供了流媒體文件處理裝置的另一種可選結(jié)構(gòu)，該裝置還可以進一步包括：

第三通信協(xié)議確定子單元，用于在所述第一通信協(xié)議確定子單元判斷結(jié)果為否時，依次將所述UDP協(xié)議、所述TCP協(xié)議和所述HTTP協(xié)議作為目標網(wǎng)絡通信協(xié)議；

所述文件數(shù)據(jù)拉取單元具體用于，依次利用各所述目標網(wǎng)絡通信協(xié)議嘗試從所述URL的域名地址部分所指定的服務器中拉取目標流媒體文件數(shù)據(jù)，直至成功拉取目標流媒體文件數(shù)據(jù)。

可選的，本實施例提供了流媒體文件處理裝置的又一種可選結(jié)構(gòu)，該裝置還可以進一步包括：

解碼器創(chuàng)建單元，用于利用拉取的目標流媒體文件數(shù)據(jù)，創(chuàng)建并初始化解碼器；

媒體播放單元，用于對所述解碼器解碼后的目標流媒體文件數(shù)據(jù)進行播放。

本申請實施例還提供一種移動終端，包括上述所述的流媒體文件處理裝置。對于流媒體文件處理裝置的描述可參照上文對應部分描述，此處不再贅述。

對于移動終端的硬件結(jié)構(gòu)，參見圖7，圖7為本申請實施例提供的移動終端的硬件結(jié)構(gòu)示意圖。如圖7所示，該移動終端可以包括：

處理器1，通信接口2，存儲器3，通信總線4，和顯示屏5；

其中處理器1、通信接口2、存儲器3和顯示屏5通過通信總線4完成相互間的通信；

可選的，通信接口2可以為通信模塊的接口，如GSM模塊的接口；

處理器1，用于執(zhí)行程序；

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

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

處理器1可能是一個中央處理器CPU，或者是特定集成電路ASIC(Application Specific Integrated Circuit)，或者是被配置成實施本申請實施例的一個或多個集成電路。

存儲器3可能包含高速RAM存儲器，也可能還包括非易失性存儲器(non-volatile memory)，例如至少一個磁盤存儲器。

其中，程序可具體用于：

響應目標流媒體文件下載請求，獲取目標流媒體文件的統(tǒng)一資源定位符URL；

根據(jù)所述URL頭部的模式信息，判斷所述目標流媒體文件是否為MMS協(xié)議的流媒體文件；

若是，參考預置的模式信息與網(wǎng)絡通信協(xié)議間的對應關(guān)系，將與所述URL頭部的模式信息相對應的網(wǎng)絡通信協(xié)議確定為目標網(wǎng)絡通信協(xié)議；

利用所述目標網(wǎng)絡通信協(xié)議，從所述URL的域名地址所指定的服務器中拉取目標流媒體文件數(shù)據(jù)。

最后，還需要說明的是，在本文中，諸如第一和第二等之類的關(guān)系術(shù)語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關(guān)系或者順序。而且，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設(shè)備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設(shè)備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設(shè)備中還存在另外的相同要素。

本說明書中各個實施例采用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似部分互相參見即可。

對所公開的實施例的上述說明，使本領(lǐng)域?qū)I(yè)技術(shù)人員能夠?qū)崿F(xiàn)或使用本申請。對這些實施例的多種修改對本領(lǐng)域的專業(yè)技術(shù)人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本申請的精神或范圍的情況下， 在其它實施例中實現(xiàn)。因此，本申請將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。