[發(fā)明專(zhuān)利]一種多媒體數(shù)據(jù)快速發(fā)送和接收的方法

有效

• 申請(qǐng)?zhí)枺?/td>: 200610145168.7
• 申請(qǐng)日: 2006-11-15
• 公開(kāi)（公告）號(hào): CN101188601A
• 公開(kāi)（公告）日: 2008-05-28
• 發(fā)明（設(shè)計(jì)）人: 李加周;陳重奮;王志英;孫健
• 申請(qǐng)（專(zhuān)利權(quán)）人: 中興通訊股份有限公司
• 主分類(lèi)號(hào): H04L29/06
• 分類(lèi)號(hào): H04L29/06
• 代理公司: 暫無(wú)信息
• 代理人: 暫無(wú)信息

技術(shù)領(lǐng)域

本發(fā)明涉及多媒體通信的流媒體點(diǎn)播、直播、時(shí)移和視頻實(shí)時(shí)通信領(lǐng)域，尤其涉及一種用于實(shí)現(xiàn)流媒體在客戶(hù)端快速呈現(xiàn)圖像的多媒體數(shù)據(jù)快速發(fā)送和接收的方法。

背景技術(shù)

隨著網(wǎng)際協(xié)議(Internet?Protocol，以下簡(jiǎn)稱(chēng)IP)技術(shù)的飛速發(fā)展，基于IP的視頻通信及相關(guān)技術(shù)也得到了大量應(yīng)用，例如固定網(wǎng)絡(luò)的網(wǎng)際協(xié)議電視(Internet?Protocol?Television，簡(jiǎn)稱(chēng)IPTV)、第三代移動(dòng)通信(ThirdGeneration，簡(jiǎn)稱(chēng)3G)網(wǎng)絡(luò)的流媒體技術(shù)、會(huì)議電視以及可視電話等都是視頻通信在固定網(wǎng)絡(luò)和移動(dòng)網(wǎng)絡(luò)應(yīng)用的實(shí)例。

由于IP網(wǎng)絡(luò)是基于分組交換的技術(shù)，通信雙方不能獨(dú)占網(wǎng)絡(luò)資源，網(wǎng)絡(luò)質(zhì)量不能得到保證，因此必然存在著網(wǎng)絡(luò)的抖動(dòng)和延時(shí)，網(wǎng)絡(luò)的抖動(dòng)會(huì)造成數(shù)據(jù)包先發(fā)后到，造成接收端數(shù)據(jù)亂序，而延時(shí)會(huì)造成播放的不連續(xù)，當(dāng)前通用的技術(shù)是通過(guò)播放端緩存一定的數(shù)據(jù)來(lái)消除抖動(dòng)和延時(shí)。這種緩沖技術(shù)在消除網(wǎng)絡(luò)抖動(dòng)和延時(shí)同時(shí)，必然會(huì)造成播放時(shí)間的滯后。

數(shù)據(jù)接收緩沖區(qū)的大小和網(wǎng)絡(luò)狀況有關(guān)系，網(wǎng)絡(luò)狀況不好時(shí)，緩沖區(qū)可能會(huì)開(kāi)得比較大，這樣在通信會(huì)話建立到呈現(xiàn)圖像或者在媒體點(diǎn)播做拖動(dòng)操作時(shí)，用戶(hù)需要等待較長(zhǎng)的時(shí)間，影響用戶(hù)體驗(yàn)。

當(dāng)前還沒(méi)有處理這種問(wèn)題的公開(kāi)方法。

發(fā)明內(nèi)容

本發(fā)明的目的是克服基于IP技術(shù)的多媒體通信中由于增加了緩沖區(qū)造成的延時(shí)等待時(shí)間過(guò)長(zhǎng)的缺點(diǎn)，既能充分利用現(xiàn)有網(wǎng)絡(luò)帶寬，盡量縮短接收端緩沖時(shí)間，又不會(huì)由于網(wǎng)絡(luò)阻塞而造成大量丟包。

為實(shí)現(xiàn)上述目的，本發(fā)明提供一種多媒體數(shù)據(jù)快速發(fā)送和接收的方法，其包括下列步驟：

步驟1：服務(wù)端偵聽(tīng)控制協(xié)議端口，如果快發(fā)數(shù)據(jù)需要帶外發(fā)送，需要偵聽(tīng)快發(fā)數(shù)據(jù)的控制協(xié)議端口；

步驟2：客戶(hù)端向服務(wù)端的控制協(xié)議端口發(fā)起通信連接，連接成功后，客戶(hù)端向服務(wù)端發(fā)送控制消息，消息中擴(kuò)展兩個(gè)字段，一個(gè)字段表示客戶(hù)端支持接收快發(fā)數(shù)據(jù)，另一字段表示期望快發(fā)的媒體數(shù)據(jù)時(shí)長(zhǎng)；

步驟3：服務(wù)端響應(yīng)客戶(hù)端的請(qǐng)求消息，如果服務(wù)端支持快發(fā)，則在響應(yīng)消息中攜帶支持快發(fā)數(shù)據(jù)的字段，同時(shí)攜帶服務(wù)端偵聽(tīng)的快發(fā)數(shù)據(jù)控制協(xié)議端口字段；如果服務(wù)端不支持快發(fā)，不攜帶支持快發(fā)數(shù)據(jù)字段，客戶(hù)端認(rèn)為服務(wù)端不支持快發(fā)，進(jìn)行步驟8；

步驟4：如果服務(wù)端和客戶(hù)端都支持快發(fā)而且采用帶外傳送，客戶(hù)端連接服務(wù)端的媒體數(shù)據(jù)快發(fā)的控制協(xié)議端口；建立媒體數(shù)據(jù)快發(fā)的控制協(xié)議通道；

步驟5：服務(wù)端和客戶(hù)端正常交互控制協(xié)議消息結(jié)束后，進(jìn)入媒體數(shù)據(jù)發(fā)送階段；

步驟6：服務(wù)端通過(guò)媒體數(shù)據(jù)快發(fā)的控制協(xié)議通道，盡力將媒體數(shù)據(jù)發(fā)送給客戶(hù)端；

步驟7：快發(fā)通道的媒體數(shù)據(jù)發(fā)送完畢后，服務(wù)端發(fā)送一個(gè)字段標(biāo)識(shí)，表示通過(guò)該通道的快發(fā)碼流結(jié)束；

步驟8：服務(wù)端根據(jù)正常流程發(fā)送碼流。

上述步驟2中所述的控制協(xié)議可以是傳輸控制協(xié)議(TransmissionControl?Protocol，以下簡(jiǎn)稱(chēng)TCP)，也可以是用戶(hù)數(shù)據(jù)報(bào)協(xié)議(User?DatagramProtocol，以下簡(jiǎn)稱(chēng)UDP)；如果控制協(xié)議采用UDP方式，則不需要連接，客戶(hù)端直接向服務(wù)端發(fā)送控制消息。

在上述步驟4中，如果服務(wù)端和客戶(hù)端雙方都采用TCP傳送媒體數(shù)據(jù)，則媒體快發(fā)通道使用媒體的TCP通道，不需要另外建立媒體快發(fā)通道。例如通過(guò)實(shí)時(shí)流協(xié)議(Real-time?Streaming?Protocol，以下簡(jiǎn)稱(chēng)RTSP)、超文本傳輸協(xié)議(Hyper?Text?Transfer?Protocol，以下簡(jiǎn)稱(chēng)HTTP)協(xié)議傳送流媒體數(shù)據(jù)的隧道方式就屬于這種情況。

如果服務(wù)端和客戶(hù)端雙方都采用UDP傳送媒體數(shù)據(jù)，而控制協(xié)議采用TCP交互，則媒體快發(fā)通道采用帶外傳送方式，建立媒體快發(fā)通道，或者借用控制協(xié)議交互的TCP通道。例如流媒體中通過(guò)TCP傳送RTSP協(xié)議，通過(guò)UDP傳送媒體的方式，另外H.323系統(tǒng)中通過(guò)TCP傳送H.225.0和H.245，通過(guò)UDP傳送媒體也屬于這種情況。

如果客戶(hù)端由于某些操作導(dǎo)致緩沖區(qū)清空，客戶(hù)端可以向服務(wù)端發(fā)送請(qǐng)求快發(fā)字段，客戶(hù)端向服務(wù)端發(fā)送快發(fā)請(qǐng)求的觸發(fā)條件可以是：a、通信雙方會(huì)話建立初期；b、流媒體播放器執(zhí)行拖動(dòng)操作；c、流媒體播放器執(zhí)行快進(jìn)、快退操作；d、流媒體播放器快進(jìn)、快退轉(zhuǎn)正常播放操作；e、多點(diǎn)會(huì)議的畫(huà)面切換。