一種多媒體數據快速發送和接收的方法

專利名稱：一種多媒體數據快速發送和接收的方法
技術領域：
本發明涉及多媒體通信的流媒體點播、直播、時移和視頻實時通信領 域，尤其涉及一種用于實現流媒體在客戶端快速呈現圖像的多媒體數據快 速發送和接收的方法。
背景技術：
隨著網際協議(InternetProtocol,以下簡稱IP)技術的飛速發展，基
于IP的視頻通信及相關技術也得到了大量應用，例如固定網絡的網際協 議電視(Internet Protocol Television,簡稱IPTV)、第三代移動通信(Third Generation,簡稱3G)網絡的流媒體技術、會議電視以及可視電話等都是 視頻通信在固定網絡和移動網絡應用的實例。
由于IP網絡是基于分組交換的技術，通信雙方不能獨占網絡資源， 網絡質量不能得到保證，因此必然存在著網絡的抖動和延時，網絡的抖動 會造成數據包先發后到，造成接收端數據亂序，而延時會造成播放的不連 續，當前通用的技術是通過播放端緩存一定的數據來消除抖動和延時。這 種緩沖技術在消除網絡抖動和延時同時，必然會造成播放時間的滯后。
數據接收緩沖區的大小和網絡狀況有關系，網絡狀況不好時，緩沖區 可能會開得比較大，這樣在通信會話建立到呈現圖像或者在媒體點播做拖 動操作時，用戶需要等待較長的時間，影響用戶體驗。
當前還沒有處理這種問題的公開方法。

發明內容
本發明的目的是克服基于IP技術的多媒體通信中由于增加了緩沖區 造成的延時等待時間過長的缺點，既能充分利用現有網絡帶寬，盡量縮短
接收端緩沖時間，又不會由于網絡阻塞而造成大量丟包。
為實現上述目的，本發明提供一種多媒體數據'決速發送和接收的方 法，其包括下列步驟
步驟l:服務端偵聽控制協議端口，如果快發數據需要帶外發送，需
要偵聽快發數據的控制協議端口 ；
步驟2:客戶端向服務端的控制協議端口發起通信連接，連接成功后， 客戶端向服務端發送控制消息，消息中擴展兩個字段， 一個字段表示客戶 端支持接收快發數據，另一字段表示期望快發的媒體數據時長；
步驟3:服務端響應客戶端的請求消息，如果服務端支持快發，則在 響應消息中攜帶支持快發數據的字段，同時攜帶服務端偵聽的快發數據控
制協議端口字段；如果服務端不支持快發，不攜帶支持快發數據字段，客
戶端認為服務端不支持快發，進行步驟8;
步驟4:如果服務端和客戶端都支持快發而且釆用帶外傳送，客戶端 連接服務端的媒體數據快發的控制協議端口 ；建立媒體數據快發的控制協 議通道；
步驟5:服務端和客戶端正常交互控制協議消息結束后，進入媒體數
據發送階段；
步驟6:服務端通過媒體數據快發的控制協議通道，盡力將媒體數據
發送給客戶端；
步驟7:快發通道的媒體數據發送完畢后，服務端發送一個字段標識，
表示通過該通道的快發碼流結束；
步驟8:服務端根據正常流程發送碼流。
上述步驟2中所述的控制協議可以是傳輸控制協議(Transmission Control Protocol,以下簡稱TCP)，也可以是用戶數據報協議(User Datagram Protocol,以下簡稱UDP);如果控制協議采用UDP方式，則不需要連接, 客戶端直接向服務端發送控制消息。
在上述步驟4中，如果服務端和客戶端雙方都釆用TCP傳送媒體數
據，則媒體快發通道使用媒體的TCP通道，不需要另外建立媒體快發通 道。例如通過實時流協議(Real-time Streaming Protocol,以下簡稱RTSP)、 超文本傳輸協議(Hyper Text Transfer Protocol,以下簡稱HTTP)協議傳 送流媒體數據的隧道方式就屬于這種情況。
如果服務端和客戶端雙方都釆用UDP傳送媒體數據，而控制協議釆 用TCP交互，則媒體快發通道釆用帶外傳送方式，建立媒體快發通道， 或者借用控制協議交互的TCP通道。例如流媒體中通過TCP傳送RTSP 協議,通過UDP傳送媒體的方式，另外H.323系統中通過TCP傳送H.225.0 和H.245 ，通過UDP傳送媒體也屬于這種情況。
如果客戶端由于某些操作導致緩沖區清空，客戶端可以向服務端發送 請求快發字段，客戶端向服務端發送快發請求的觸發條件可以是a、通 信雙方會話建立初期；b、流媒體播放器執行拖動操作；c、流媒體播放器 執行快進、快退操作；d、流媒體播放器快進、快退轉正常播放操作；e、 多點會議的畫面切換。
另外，上述服務端和客戶端分別指多媒體通信服務端和多媒體通信客 戶端，這是一個邏輯概念， 一個物理設備可以是一個獨立的服務端，例如
流媒體服務器；也可以是一個獨立的客戶端，例如流媒體播放器；也可以 是服務端和客戶端的組合，例如可視電話。
本發明的技術方案釆用了 TCP快速發送媒體，釆用TCP通道的好處 是，利用TCP的滑動窗口特性，當網絡擁塞時，TCP協議滑動窗口變小， 發送速度降低，如果網絡狀況較好，可以實現盡力發送，這樣既可以充分 利用帶寬，又不會因為數據包發送速度沒有控制而導致網絡丟包。TCP快 發通道可以是媒體發送通道，可以是控制協議通道，也可以單獨建立快發 通道。
下面結合附圖，對本發明的具體實施作進一步的詳細說明。對于熟悉 本技術領域的人員而言，從對本發明方法的詳細說明中，本發明的上述和 其他目的、特fiE和優點將顯而易見。


圖i是表示本發明的媒體服務端和客戶端的示意圖2是表示本發明媒體服務端和客戶端實現快發碼流的交互圖3是本發明一較佳實施例在流媒體系統中實現的示意圖4是本發明一較佳實施例在H.323系統中實現的示意圖。
具體實施例方式
為使本發明的目的、技術方案及技術效果更加清楚明白，以下通過具 體實施例并參照附圖，對本發明進行詳細說明。
圖l表示本發明涉及的通信雙方，即多媒體通信服務端，例如流媒體
服務器；以及多媒體通信客戶端，例如流媒體播放器，其通過網絡通信(服
務端和客戶端是一個邏輯概念， 一個物理設備可以是一個獨立的服務端， 也可以是一個獨立的客戶端，也可以是服務端和客戶端的組合)。
圖2、圖3、圖4所示的實施例中，首先服務端偵聽控制協議端口， 如果快發數據需要帶外發送，需要偵聽快發數據的控制協議端口，再進行 媒體服務端和客戶端之間的信息交互。進行信息交互時，客戶端首先向服 務端的控制協議端口發起通訊連接，連接成功后，客戶端向服務端發送控
制消息。控制協議可以是傳輸控制協議，也可以是用戶數據報協議；如果
控制協議采用用戶數據報協議，則不需要連接，客戶端直接向服務端發送 控制消息。
圖2表示本發明提出的媒體服務端和客戶端之間的信息交互。具體實 施流程如下
1. 客戶端向服務端發起信令協議交互,在控制協議消息中攜帶快發標 識，本例釆用x-SpeedupPlay:yes和x-HopeSpeedupSecond: 1字段，表示客
戶端支持快發，期望快發數據為1秒，實際使用可以釆用其他類似擴展字 段。
2. 服務端響應客戶端的協議請求后，如果服務端支持快發，服務端響
應消息同樣攜帶x-SpeedupPlay:yes，同時攜帶字段x-SpeedupPort:5000， 快發通道偵聽端口為5000，實際使用可以釆用其他類似擴展字段和端口號。
3. 客戶端向服務器5000端口發起TCP連接請求且釆用帶外傳送，建 立媒體快發通道。
4. 服務端按照正常協議進行交互。
5. 協議雙方交互完畢，客戶端請求發送碼流，在協議中攜帶 x-SpeedupPlay:yes，表示服務端可以快發碼流。客戶端做好在正常媒體通 道和快發通道接收碼流的準備。
6. 服務端發送應答，攜帶x-SpeedupPlay:yes確定快發發送碼流。
7. 服務端通過控制協議通道發送媒體碼流。
8. 服務端發送l秒的快發數據后，停止快發，向客戶端發送消息，攜 帶x-SpeedupPlay:no字段，表示快發結束。
9. 服務端按照正常流程向客戶端發送碼流。
圖3是本發明一較佳實施例在流媒體系統中實現的示意圖。在本較佳 實施例中，由于流媒體控制協議釆用RTSP，通過TCP傳輸，因此快發通 道可以釆用控制協議的通道，x-SpeedupPort字段可以省略，下面參照該圖 對本發明一較佳實施例的具體實施流程進行說明如下
1. 用戶通過客戶端向流媒體服務器發送DESCRIBE點播請求，女口 rtsp:〃serverip/dirl/dir2/test.mp4， 攜 帶 x國SpeedupPlay:yes 和 x-HopeSpeedupSecond: 1表示支持快發。
2. 流媒體服務器響應節目的會話描述協議(Session Description Protocol,以下簡稱SDP)信息(RTSP/1.0 200 OK SDP)，攜帶擴展字段 x-SpeedupPlay:yes，表示服務器支持快發。
3. 客戶端根據SDP信息向流媒體服務器發送SETUP流建立請求， 本例客戶端要求建立RTP/AVP的基于UDP的請求。
4. 流媒體服務器響應確認客戶端的流建立請求(RTSPA.O 200 OK)。5. 客戶端建立第二個流的SETUP請求。
6. 流媒體服務器響應確認客戶端的流建立請求(RTSP/1.0 200 OK)。
7. 客戶端向流媒體服務器發送播放請求，攜帶擴展字段 x-SpeedupPlay:yes,表示客戶端要求接下來的碼流發送服務器進行快發。 此時客戶端應該在交互的UDP端口和TCP通道做好接收碼流的準備。
8. 流媒體服務器響應客戶端的PLAY請求(RTSP/1.0 200 OK)，并攜 帶擴展字段x-SpeedupPlay:yes，表示流媒體服務器將進行媒體流快發。
9. 流媒體服務器通過RTSP的控制通道盡力發送媒體流，快發的媒 體流播放時間應該為1秒。媒體流在TCP通道的打包格式見rfc2326中 10.12關于交織數據的格式描述。
10. 快發結束后，流媒體服務器發送SET—PARAMETER消息，攜帶 x-SpeedupPlay:no字段，表示快發結束。
11. 客戶端響應流媒體服務器的SET—PARAMETER消息(RTSP/1.0 200 OK)。
12. 流媒體服務器通過交互的正常UDP通道向客戶端發送媒體流。
13. 用戶做暫停操作，客戶端向流媒體服務器發送PAUSE消息。
14. 流媒體服務器響應客戶端的暫停請求(RTSP/1.0 200 OK)。
15. 客戶端向流媒體服務器發送PLAY播放請求。由于客戶端的緩沖 區還有數據，客戶端不需要服務器快發媒體數據。
16. 流媒體服務器響應客戶端的播放請求(RTSP/1.0 200 OK)。
17. 流媒體服務器通過UDP通道按照正常速度把碼流發送給客戶端。
18. 用戶做拖動操作，由于客戶端緩沖的數據不能繼續播放，將被清
空，因此客戶端的播放請求中攜帶了要拖動的位置信息，同時攜帶 x-SpeedupPlay:yes字段，要求流媒體服務器快發數據。
19. 流媒體服務器響應客戶端的快發播放請求(RTSP/1.0 200OK)，同 時攜帶x-SpeedupPlay:yes字段。20.流媒體服務器快發數據給客戶端，流程進入步驟9，直到節目播 放完畢或者用戶發送TEARDOWN退出。
圖4是本發明一較佳實施例在H.323系統中實現的示意圖。在H.245 的打開邏輯通道OLC中擴展字段，本實施例是兩個端點之間呼叫的流程， 具體實施流程如下
1. 端點1呼叫端點2，端點1和端點2和網閘之間有消息認證系統 (Message Authentication System ， RAS)消息通信。
2. 端點1和端點2之間經過H.225.0過程。
3. 端點1和端點2之間經過H.245的主從決定和能力集交互。
端點1向端點2發起OLC消息，要求打開邏輯通道。OLC中擴展如 下ASN.l消息。擴展消息包含兩個字段， 一個字段表示是否需要快發，另 一個字段表示快發的時長。
4. 端點2在OLCACK響應中攜帶同步驟4相同的擴展消息， hopeSpeedupSecond是可選字段，可以不帶。
5. 端點2向端點1發送OLC消息，要求打開邏輯通道。擴展字段 同步驟4。
6. 端點1在OLCACK響應中攜帶同步驟4相同的擴展消息， hopeSpeedupSecond是可選字段，可以不帶。
7. 端點之間通過H.245通道快速發送碼流。
快發碼流結束，化245通道發送非標準消息，擴展快發結束的命令類 型。表示快發數據結束。
8. 通信雙方按照正常RTP通道發送媒體流。
當然，本發明還可有其他實施例，在不背離本發明精神及其實質的情 況下，熟悉本領域的技術人員當可根據本發明作出各種相應的改變和變 形，但這些相應的改變和變形都應屬于本發明的權利要求的保護范圍。
權利要求
1.一種多媒體數據快速發送和接收的方法，其特征在于，包括以下步驟步驟1服務端偵聽控制協議端口，如果快發數據需要帶外發送，需要偵聽快發數據的控制協議端口；步驟2客戶端向服務端的控制協議端口發起通訊連接，連接成功后，客戶端向服務端發送控制消息，消息中擴展兩個字段，一個字段表示客戶端支持接收快發數據，另一字段表示期望快發的媒體數據時長；步驟3服務端響應客戶端的請求消息，如果服務端支持快發，則在響應消息中攜帶支持快發數據的字段，同時攜帶服務端偵聽的快發數據控制協議端口字段；如果服務端不支持快發，不攜帶支持快發數據字段，客戶端認為服務端不支持快發，進行步驟8；步驟4如果服務端和客戶端都支持快發而且采用帶外傳送，客戶端連接服務端的媒體數據快發的控制協議端口；建立媒體數據快發的控制協議通道；步驟5服務端和客戶端正常交互控制協議消息結束后，進入媒體數據發送階段；步驟6服務端通過媒體數據快發的控制協議通道，盡力將媒體數據發送給客戶端；步驟7快發通道的媒體數據發送完畢后，服務端發送一個字段標識，表示通過該通道的快發碼流結束；步驟8服務端根據正常流程發送碼流。
2. 根據權利要求1所述的方法,其特征在于上述步驟2中所述的控制協議可以是傳輸控制協議，也可以是用戶數據報協議；如果控制協議采用用戶數據報協^t，則不需要連接，客戶端直接向服務端發送控制消息。
3. 根據權利要求1所述的方法，其特征在于在上述步驟4中，如果服務端和客戶端雙方都釆用傳輸控制協議傳送媒體數據，則媒體快發通道使用媒體的傳輸控制協議通道，不需要另外建立媒體快發通道；如果服務端 和客戶端雙方都釆用用戶數據報協議傳送媒體數據，而控制協議釆用傳輸 控制協議交互，則媒體快發通道釆用帶外傳送方式，建立媒體快發通道， 或者借用控制協議交互的傳輸控制協議通道。
4. 根據權利要求1所述的方法，其特征在于如果客戶端由于某些操作 導致緩沖區清空，客戶端可以向服務端發送請求快發字段，客戶端向服務端發送快發請求的觸發條件可以是a、通訊雙方會話建立初期；b、流媒 體播放器執行拖動操作；c、流媒體播放器執行快進、快退操作；d、流媒 體播放器快進、快退轉正常播放操作；e、多點會議的畫面切換。
5. 根據權利要求1至4中的任何一項所述的方法,其特征在于上述服 務端和客戶端是一個邏輯概念， 一個物理設備可以是一個獨立的服務端， 也可以是一個獨立的客戶端，也可以是服務端和客戶端的組合。
全文摘要
一種實現多媒體數據快速發送和接收的方法，包括服務端偵聽控制協議端口；客戶端向服務端的控制協議端口發起通訊連接；客戶端向服務端發送控制消息；服務端響應客戶端的請求消息，如果服務端和客戶端都支持快發而且采用帶外傳送，客戶端連接服務端的媒體數據快發的傳輸控制協議端口，建立媒體數據快發的傳輸控制協議通道；服務端和客戶端正常交互控制協議消息結束后，服務端通過媒體數據快發的傳輸控制協議通道，盡力將媒體數據發送給客戶端；發送完畢后，服務端根據正常流程發送碼流。本發明的方法采用了TCP快速發送媒體，利用TCP的滑動窗口特性，既可以充分利用帶寬，又不會因為數據包發送速度沒有控制而導致網絡丟包。
文檔編號H04L29/06GK101188601SQ200610145168
公開日2008年5月28日 申請日期2006年11月15日 優先權日2006年11月15日
發明者健 孫, 李加周, 王志英, 陳重奮 申請人:中興通訊股份有限公司