專利名稱：終端流媒體播放方法
技術(shù)領(lǐng)域：
本發(fā)明涉及流媒體播放算法，特別是涉及一種終端流媒體播放方法。
背景技術(shù)：
隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，主干網(wǎng)與寬帶網(wǎng)接入技術(shù)日臻成熟，網(wǎng)絡(luò)視頻的傳輸已經(jīng)成為了 hternet應(yīng)用的一個(gè)亮點(diǎn)。為了提高視頻數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸效率，并實(shí)現(xiàn)視頻的實(shí)時(shí)播放，流媒體技術(shù)的研究與應(yīng)用都得到了極大的發(fā)展?；诖筇艫RENA平臺(tái)的流媒體實(shí)時(shí)傳輸協(xié)議主要包括用于數(shù)據(jù)流部分的實(shí)時(shí)傳輸協(xié)議RTP (Real-time Transport ftOtocol)，以及，用于控制部分的實(shí)時(shí)傳輸控制協(xié)議 RTCP(Real-time Transport Control Protocol)。RTP協(xié)議主要用于在hternet上傳送實(shí)時(shí)的流媒體信息。RTP被定義為在一對(duì)一或一對(duì)多的傳輸情況下工作，其目的是提供時(shí)間信息和實(shí)現(xiàn)流同步，RTP協(xié)議的數(shù)據(jù)報(bào)主要包括多媒體數(shù)據(jù)以及多媒體數(shù)據(jù)所攜帶的時(shí)間戳、順序號(hào)等。而RTCP協(xié)議的數(shù)據(jù)報(bào)則主要包括接收者接收某個(gè)多媒體流的服務(wù)質(zhì)量信息，用于對(duì)服務(wù)器端的反饋。RTP通常使用用戶數(shù)據(jù)包協(xié)議UDP^ser Datagram Protocol)來(lái)傳送數(shù)據(jù)，但是RTP也可以在傳輸控制協(xié)議TCP (Transmission Control Protocol)或異步轉(zhuǎn)移模式 ATM (Asynchronous Transfer Mode)等其它協(xié)議之上工作。當(dāng)應(yīng)用程序開(kāi)始一個(gè)RTP會(huì)話時(shí)將使用兩個(gè)端口 一個(gè)給RTP，一個(gè)給RTCP，RTP 本身并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機(jī)制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。通常RTP算法并不作為一個(gè)獨(dú)立的網(wǎng)絡(luò)層來(lái)實(shí)現(xiàn)，而是作為應(yīng)用程序代碼的一部分。在RTP會(huì)話期間，各參與者周期性地傳送RTCP包，RTCP包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計(jì)資料，因此，服務(wù)器可以利用這些信息動(dòng)態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，將能夠以有效的反饋和最小的開(kāi)銷使傳輸效率最佳化，因而特別適合傳送網(wǎng)絡(luò)上的實(shí)時(shí)數(shù)據(jù)。在基于大唐ARENA平臺(tái)的流媒體傳輸中，RTP僅采用UDP進(jìn)行傳輸，有時(shí)雖然流媒體終端能夠正常地發(fā)起流媒體業(yè)務(wù)，但是由于種種原因，通過(guò)UDP層發(fā)送的數(shù)據(jù)包卻總會(huì)出現(xiàn)不能穿透流媒體服務(wù)器的網(wǎng)關(guān)限制(例如支持協(xié)議類型、端口映射等)的現(xiàn)象；當(dāng)網(wǎng)絡(luò)信號(hào)較差時(shí)，也會(huì)出現(xiàn)定屏等待的情況。然而，當(dāng)出現(xiàn)上述問(wèn)題時(shí)，TCP層卻可以穿透網(wǎng)關(guān)限制，并提供可靠服務(wù)。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問(wèn)題是為了克服現(xiàn)有技術(shù)中因RTP僅采用UDP進(jìn)行傳輸，導(dǎo)致終端在流媒體不能穿透服務(wù)器網(wǎng)關(guān)、網(wǎng)絡(luò)服務(wù)信號(hào)差時(shí)無(wú)法正常播放流媒體的缺陷，提供一種能夠在UDP無(wú)法正常傳輸數(shù)據(jù)時(shí)將RTP包平滑至TCP層上工作，從而使終端能夠可靠地實(shí)現(xiàn)流媒體的正常播放的終端流媒體播放方法。本發(fā)明是通過(guò)下述技術(shù)方案來(lái)解決上述技術(shù)問(wèn)題的一種終端流媒體播放方法，該終端默認(rèn)RTP包工作于UDP層上，其特點(diǎn)在于，該方法包括=S1、終端發(fā)起流媒體業(yè)務(wù)；S2、 終端發(fā)送RTSP(Real Time Streaming Protocol，實(shí)時(shí)流傳輸協(xié)議)包；S3、終端判斷是否收到服務(wù)器的響應(yīng)消息，若未收到，則播放失敗，若收到，則執(zhí)行步驟、；S4、終端啟動(dòng)一設(shè)有一定時(shí)時(shí)間的定時(shí)器；S5、若終端在該定時(shí)時(shí)間內(nèi)接收到來(lái)自服務(wù)器的RTP包，則執(zhí)行步驟 &，若在該定時(shí)時(shí)間內(nèi)未接收到來(lái)自服務(wù)器的RTP包，則執(zhí)行步驟S7_8 ;S6、終端對(duì)RTP包的數(shù)據(jù)進(jìn)行處理并正常播放，然后退出播放流程；S7、終端停止接收RTP包，并通知服務(wù)器停止發(fā)送RTP包；S8、終端設(shè)定RTP包工作于TCP層上，然后再次執(zhí)行步驟Siq其中，該終端基于大唐ARENA平臺(tái)。本發(fā)明的積極進(jìn)步效果在于通過(guò)采用本發(fā)明的該終端流媒體播放方法，終端能夠在UDP無(wú)法正常傳輸數(shù)據(jù)時(shí)將RTP包平滑至TCP層上工作，從而利用TCP層提供的可靠服務(wù)，使得即使在流媒體不能穿透服務(wù)器網(wǎng)關(guān)、網(wǎng)絡(luò)信號(hào)差時(shí)終端也能夠可靠地實(shí)現(xiàn)流媒體的正常播放。


圖1為本發(fā)明中RTP包工作于UDP層上時(shí)的流媒體協(xié)議棧數(shù)據(jù)流示意圖。圖2為本發(fā)明的該終端流媒體播放方法的流程圖。圖3為本發(fā)明中RTP包工作于TCP層上時(shí)的流媒體協(xié)議棧數(shù)據(jù)流示意圖。
具體實(shí)施例方式下面結(jié)合附圖給出本發(fā)明較佳實(shí)施例，以詳細(xì)說(shuō)明本發(fā)明的技術(shù)方案。本實(shí)施例以基于大唐ARENA平臺(tái)的流媒體終端為例，在該終端中默認(rèn)為RTP包工作于UDP層上，該狀態(tài)下的流媒體協(xié)議棧數(shù)據(jù)流如圖1所示。如圖2所示，本發(fā)明的該終端流媒體播放方法包括以下步驟步驟100，終端發(fā)起流媒體業(yè)務(wù)。步驟101，終端向流媒體服務(wù)器發(fā)送RTSP包。步驟102，終端判斷是否收到來(lái)自服務(wù)器的針對(duì)RTSP包的響應(yīng)消息，若未收到，則說(shuō)明此時(shí)網(wǎng)絡(luò)發(fā)生異常，播放失?。蝗粽Ｊ盏?，則終端執(zhí)行步驟103，并且服務(wù)器在響應(yīng)了來(lái)自終端的RTSP包之后，便開(kāi)始向終端發(fā)送RTP包。步驟103，終端啟動(dòng)一定時(shí)器，該定時(shí)器預(yù)設(shè)有一定時(shí)時(shí)間，并且該終端從啟動(dòng)該定時(shí)器時(shí)起便開(kāi)始嘗試接收來(lái)自服務(wù)器的RTP包。步驟104，若終端在該定時(shí)時(shí)間內(nèi)正常地接收到了來(lái)自服務(wù)器的RTP包，則執(zhí)行步驟105 ；若終端在該定時(shí)時(shí)間內(nèi)未接收到來(lái)自服務(wù)器的RTP包，這便意味著發(fā)生了通過(guò) UDP層發(fā)送的數(shù)據(jù)包不能穿透服務(wù)器的網(wǎng)關(guān)限制或是網(wǎng)絡(luò)信號(hào)較差的情況，因此執(zhí)行步驟 106-107。步驟105，終端正常地對(duì)接收到的RTP包內(nèi)的數(shù)據(jù)進(jìn)行處理，然后將處理獲得的多媒體數(shù)據(jù)正常地播放給用戶觀賞，并在播放結(jié)束后退出播放流程。步驟106，終端停止接收RTP包，并通知服務(wù)器停止RTP包的發(fā)送。步驟107，終端對(duì)RTP包的工作層進(jìn)行重新設(shè)置，將RTP包的工作層從UDP層平滑至TCP層，然后再次執(zhí)行步驟100，重新發(fā)起流媒體業(yè)務(wù)。
在步驟107之后再一次執(zhí)行的流媒體播放流程中，由于已經(jīng)將RTP包的工作層平滑至了 TCP層，而TCP層將能夠在流媒體不能穿透服務(wù)器網(wǎng)關(guān)、網(wǎng)絡(luò)信號(hào)差時(shí)穿透網(wǎng)關(guān)限制，并提供可靠服務(wù)，因此在步驟104中終端將能夠正常地在定時(shí)時(shí)間內(nèi)接收到來(lái)自服務(wù)器的RTP包，從而順利地進(jìn)入步驟105，實(shí)現(xiàn)流媒體的正常播放。其中，RTP包工作于TCP層上時(shí)的流媒體協(xié)議棧數(shù)據(jù)流如圖3所示。由于RTP包工作于UDP層上以及工作于TCP層上的具體實(shí)現(xiàn)手段均為本領(lǐng)域中的公知技術(shù)，故在此不做贅述。綜上所述，本發(fā)明能夠在UDP無(wú)法正常傳輸數(shù)據(jù)時(shí)將RTP包平滑至TCP層上工作， 從而利用TCP層提供的可靠服務(wù)，使得即使在流媒體不能穿透服務(wù)器網(wǎng)關(guān)、網(wǎng)絡(luò)信號(hào)差時(shí)終端也能夠可靠地實(shí)現(xiàn)流媒體的正常播放。雖然以上描述了本發(fā)明的具體實(shí)施方式
，但是本領(lǐng)域的技術(shù)人員應(yīng)當(dāng)理解，這些僅是舉例說(shuō)明，本發(fā)明的保護(hù)范圍是由所附權(quán)利要求書(shū)限定的。本領(lǐng)域的技術(shù)人員在不背離本發(fā)明的原理和實(shí)質(zhì)的前提下，可以對(duì)這些實(shí)施方式做出多種變更或修改，但這些變更和修改均落入本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種終端流媒體播放方法，該終端默認(rèn)RTP包工作于UDP層上，其特征在于，該方法包括S1、終端發(fā)起流媒體業(yè)務(wù)； &、終端發(fā)送RTSP包；53、終端判斷是否收到服務(wù)器的響應(yīng)消息，若未收到，則播放失敗，若收到，則執(zhí)行步驟S4 ；54、終端啟動(dòng)一設(shè)有一定時(shí)時(shí)間的定時(shí)器；&、若終端在該定時(shí)時(shí)間內(nèi)接收到來(lái)自服務(wù)器的RTP包，則執(zhí)行步驟&，若在該定時(shí)時(shí)間內(nèi)未接收到來(lái)自服務(wù)器的RTP包，則執(zhí)行步驟S7_8 ；&、終端對(duì)RTP包的數(shù)據(jù)進(jìn)行處理并正常播放，然后退出播放流程； S7、終端停止接收RTP包，并通知服務(wù)器停止發(fā)送RTP包； &、終端設(shè)定RTP包工作于TCP層上，然后再次執(zhí)行步驟Sp
2.如權(quán)利要求1所述的終端流媒體播放方法，其特征在于，該終端基于大唐ARENA平
全文摘要
本發(fā)明公開(kāi)了一種終端流媒體播放方法，該終端默認(rèn)RTP包工作于UDP層上，S1、終端發(fā)起流媒體業(yè)務(wù)；S2、終端發(fā)送RTSP包；S3、終端判斷是否收到服務(wù)器的響應(yīng)消息，若未收到，則播放失敗，若收到，則執(zhí)行步驟S4；S4、終端啟動(dòng)一設(shè)有一定時(shí)時(shí)間的定時(shí)器；S5、若終端在該定時(shí)時(shí)間內(nèi)接收到來(lái)自服務(wù)器的RTP包，則執(zhí)行步驟S6，若在該定時(shí)時(shí)間內(nèi)未接收到來(lái)自服務(wù)器的RTP包，則執(zhí)行步驟S7-8；S6、終端對(duì)RTP包的數(shù)據(jù)進(jìn)行處理并正常播放，然后退出播放流程；S7、終端停止接收RTP包，并通知服務(wù)器停止發(fā)送RTP包；S8、終端設(shè)定RTP包工作于TCP層上，然后再次執(zhí)行步驟S1。本發(fā)明能夠在UDP無(wú)法正常傳輸數(shù)據(jù)時(shí)將RTP包平滑至TCP層上工作，從而使終端能夠可靠地實(shí)現(xiàn)流媒體的正常播放。
文檔編號(hào)H04L29/06GK102404300SQ20101028691
公開(kāi)日2012年4月4日 申請(qǐng)日期2010年9月17日 優(yōu)先權(quán)日2010年9月17日
發(fā)明者劉美紅, 邱真勇 申請(qǐng)人:希姆通信息技術(shù)(上海)有限公司