一種提高無線流媒體系統連接速度的方法

2023-05-25 22:18:51

專利名稱：一種提高無線流媒體系統連接速度的方法
一種提高無線流媒體系統連接速度的方法
技術領域：
本發明涉及移動通信技術，特別涉及一種提高無線流媒體系統連接速度的 方法。
背景技術：
隨著3G時代的到來，其重要應用之一的移動視頻通信領域將會越來越多受 到人們的關注，而視頻通信中的流媒體業務也成為受注度和使用率最高的業務。 目前，基於RTSP協議的流媒體應用發展迅速，在Internet上傳輸流媒體的相關 技術成為熱點。
現有技術中標準的、友好的RTSP流程要經過圖l所示的六個過程，考慮到 最後的一個交互過程是停止播放時的交互，那麼播放一個節目的交互過程也多 達五個。在有線的IP網絡環境下，網絡延遲一般為毫秒級，完成這五個交互過 程一般會少於三秒，在用戶可以接受的範圍之內，並且不會影響用戶的體驗效 果。但是無線網絡環境下的網絡延遲在秒級，如目前的GPRS網絡，其傳輸數據 的延時為秒級範圍。在絕大部分時間下，GPRS數據通信的平均整體延時為2秒 左右。也就是說，從GPRSDTU端發送的數據包將大致在2秒鐘後到達數據中心。 反之，從數據中的數據包也大致在2秒鐘後到達GPRS DTU。如果網絡延遲為1 秒的話，完成這五個交互過程的時間就需要10秒，嚴重影響用戶的使用及體驗 效果。本專利提出一種改進的rtsp交互方法，設法減少rtsp在無線網絡中的 交互次數，減少總的建立連接時間，從而提高用戶體驗效果。
Real Time Streaming Protocol或者RTSP (實時流媒體協議)，是解決如 何有效地在IP網絡上傳輸流媒體數據的應用層協議。RTSP提供一種可擴展的框 架，使能夠提供能控制的，按需傳輸實時數據，比如音頻和視頻文件。源數據 可以包括現場數據的反饋和存貯的文件。rtsp對流媒體提供了諸如暫停，快進 等控制，而它本身並不傳輸數據，rtsp作用相當於流媒體伺服器的遠程控制。 傳輸數據可以通過傳輸層的tcp， iidp協議，rtsp也提供了基於rtp傳輸機制的 一些有效的方法。圖1中的交互過程的具體實例化如下
RTSP消息格式
RTSP的消息有兩大類， 一是請求消息(request)， 一是回應消息(response)，兩種
消息的格式不同.
請求消息
方法URI RTSP版本CR LF 消息頭CR LF CR LF 消息體CR LF RTSP交互方法
1、 OPTION
目的是得到伺服器提供的可用方法
OPTIONS rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0
CSeq: 1 〃每個消息都有序號來標記，第一個包通常是option
請求消息
User-Agent: QTS .. qtver=6. 5. 1.. os二Windows NT 5. IService Pack 2..
伺服器的回應信息包括提供的一些方法，例如 RTSP/1. 0 200 OK Server: UServer 0. 9. 7_rcl
Cseq: 1 〃每個回應消息的cseq數值和請求消息的cseq相對
應
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN， PLAY, PAUSE, SCALE, GET—PARAMETER 〃伺服器提供的可用的方法
2、 DESCRIBE
Client向Server發起DESCRIBE請求，為了得到會話描述信息(SDP): DESCRIBE rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 2 token:
Accept: 鄰plication/sdp
User—Agent: QTS .. qtver二6. 5. 1. . os=Windows NT 5. IService Pack 2..伺服器回應一些對此會話的描述信息(sdp):
RTSP/1.0 200 OK
Server: UServer 0. 9. 7—rcl
Cseq: 2
x-prev-url: rtsp://192.168. 20. 136:5000
x-next-url: rtsp://192.168. 20. 136:5000
x—Accept—Retransmit: our-retransmit
x-Accept-Dynamic-Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri， 10 Nov 2006 12:34:38 GMT
Date: Fri， 10 Nov 2006 12:34:38 GMT
Expires: Fri， 10 Nov 2006 12:34:38 GMT
Content—Base: rtsp:〃192. 168. 20. 136:5000/xxx666/
Content—Length: 344
Content—Type: application/sdp
v=0 〃以下都是sdp信息
o=0newaveUServerNG 1451516402 1025358037 IN IP4 192.168. 20. 136
s=/xxx666
u=http:/〃
e=admin@
c=IN IP4 0. 0. 0. 0
t=0 0
a=isma—compliance: 1， 1. 0, 1 aFmnge:叩t二O-
m二video 0 RTP/AVP 96 〃m表示媒體描述，下面是對會話中視頻通道 的媒體描述
a=rtpmap:96 MP4V-ES/90000 a=fmtp:96
profile-level-id=245;config=000001B0F5000001B509000001000000012000C888B0E0E0FA62D089028307
a二control:trackID二O 〃tracklD二0表示視頻流用的是通道0
3、 SETUP
Client提醒Server建立會話，並確定傳輸模式
SETUP rtsp:〃192. 168. 20. 136:5000/xxx666/trackID=0 RTSP/1. 0 CSeq: 3
Transport: RTP/AVP/TCP;unicast;interleaved二O-l
User-Agent: QTS . . qtver=6. 5. 1. . os二Windows NT 5. IService Pack 2..
伺服器回應信息 RTSP/1. 0 200 OK Server: UServer 0.9.7—rcl Cseq: 3
Session: 6310936469860791894 〃伺服器回應的會話標識符 Cache—Control: no-cache
Transport: RTP/AVP/TCP; unicast; interleaved^-1; ssrc=6B8B4567
4、 PLAY
客戶端發送播放請求
PLAY rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 4
Session: 6310936469860791894
Range: npt=0. 000- 〃設置播放時間的範圍
User—Agent: QTS .. qtver=6. 5. 1. . os=Windows NT 5. IService Pack 2..
伺服器回應信息 RTSP/1. 0 200 OK Server: UServer 0.9.7—rcl Cseq: 4
Session: 6310936469860791894 Range: npt=0. -RTP-Info: url=trackID=0;seq=17040;rtptime=1467265309 〃seq 和rtptime都是rtp包中的信息
5、 TEA訓麗 客戶端發起關閉請求
TEARDO麗rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 5
Session: 6310936469860791894
User-Agent: QTS . . qtver二6. 5. 1. . os=Windows NT 5.IService Pack 2..
伺服器回應
RTSP/1. 0 200 OK
Server: UServer 0. 9. 7—rcl
Cseq: 5
Session: 6310936469860791894 Connection: Close
由以上來回多個交互過程，將大大增加網絡延遲時間，鑑於此，實有必要 提出一種新的技術方案。

發明內容
本發明目的在於，提出一種改善手機端點播流媒體伺服器連接速度的方案，
能夠加快手機端連接流媒體伺服器的速率，及提高用戶的體驗效果。
為了實現以上目的，本發明一種提高無線流媒體系統連接速度的方法，所 述流媒體系統包括客戶端與伺服器，所述方法基於RTSP協議傳輸數據，其特徵
在於，所述方法如下
Al :客戶端向服務端發起DESCRIBE請求，以獲取會話描述信息SDP， A2:伺服器向客戶端回應對此會話的描述信息； Bl:客戶端向服務端發送的改進後的PLAY請求， B2:伺服器和客戶端回應改進後的PLAY信息。相對現有技術，減少了網絡延遲時間，從而縮短用戶的等待時間，極大的 提高了用戶的體驗效果。


圖1為現有技術中標準的、友好的RTSP流程交互過程示意圖2為本發明方法RTSP流程交互過程示意圖。
具體實施方式
從現有技術的交互過程可以看到，OPTION這個方法只是提供一個查詢功 能，伺服器告訴客戶端有哪些可用的方法，為了適應無線中的延時大的特點， 在本發明方法中流媒體伺服器應用於無線網絡時省略OPTION這個方法。 DESCRIBE這個方法是建立會話及得到媒體的一些信息，包含客戶端要播放的媒 體文件的一些信息，這個過程是必須的。
SETUP這個方法是建立會話及傳輸方法，並且音頻視頻需要二次交互過程。 PLAY方法用於通知伺服器開始播放媒體。考慮到無線網絡的實際情況，在本發 明方法中將SETUP這個方法是建立會話及傳輸方法，並且音頻視頻需要二次交 互過程以及PLAY方法的交互過程三個交互過程整合起來，用一個交互來完成上 述三個方法的功能。具體如下
客戶端在收到DESCRIBE方法的回應包後立即發送改進過的PLAY方法，在 PLAY這個方法中包含客戶端要播放的媒體的trackID (位置信息)，媒體包括視 頻與音頻，或是其中的任意一個，視頻與音頻的會話信息不再分開發送，而是 一起發送。PLAY方法中還包括傳輸的模式及起始播放的時間。在流媒體伺服器 的回應信息中則包含對傳輸模式的確認及媒體數據的會話通道，媒體數據包中 的起始序列號與媒體數據包的中起始時間戳，其中媒體包括視頻與音頻，或是 其中的任一個，視頻與音頻的會話信息不再分開發送。
經過上述方法改進後，客戶端與伺服器的實際交互過程如圖2。 改進後的RTSP交互過程 改進後的PLAY命令 客戶端發送的改進後的PLAY請求PLAY rtsp://192. 168.20. 136:5000/xxx666/tracklDO; trackID=l RTSP/1. 0 CSeq: 4
Session: 6310936469860791894
Range: npt=0. 000- 〃設置播放時間的範圍
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
User-Agent: QTS .. qtver=6. 5. l…os二Windows NT 5. IService Pack 2…
伺服器回應改進後的PLAY信息 RTSP/1. 0 200 OK Server: UServer 0. 9. 7—rcl Cseq: 4
Session: 6310936469860791894 Range: npt=0.OOOOOO-
RTP-Info:url=trackID=0;seq=17040;rtpt ime=1467265309;url=trackID=l;se q=l; rtptime=0〃seq禾口 rtptime都是rtp包中的信息 Transport: RTP/AVP/TCP;unicast;interleaved二0-1;ssrc二6B8B4567
相對於圖1中的現有技術，具體對本發明圖2所示的方法交互過程示意圖 作一個實例化如下
1、 DESCRIBE
Client向Server發起DESCRIBE請求，為了得到會話描述信息(SDP): DESCRIBE rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/1. 0 CSeq: 2 token:
Accept: application/sdp
User-Agent: QTS . . qtver=6. 5. 1. . os二Windows NT 5. IService Pack 2..
伺服器回應一些對此會話的描述信息(sdp):
RTSP/1. 0 200 OK
Server: UServer 0. 9. 7一rcl
Cseq: 2x-next-url: rtsp://192. 168. 20. 136:5000
x-Accept—Retransmit: our-retransmit
x-Accept-Dynamic—Rate: 1
Cache-Control: must-revalidate
Last-Modified: Fri， 10 Nov 2006 12:34:38 GMT
Date: Fri, 10 Nov 2006 12:34:38 GMT
Expires: Fri， 10 Nov 2006 12:34:38 GMT
Content-Base: rtsp:〃192. 168. 20. 136:5000/xxx666/
Content-Length 344
Content-Type: 即plication/sdp
v二0 〃以下都是sdp信息
o=0newaveUServerNG 1451516402 1025358037頂IP4 192.168.20. 136
s=/xxx666
u=hUp:〃/
e=admin@
c=IN IP4 0. 0. 0. 0 t=0 0
a二isma-compliance: 1， 1.0， 1
m=Video 0 RTP/AVP 96 〃m表示媒體描述，下面是對會話中視頻通道 的媒體描述
a二rtpmap:96 MP4V-ES/90000 a=fmtp:96
profile-level-id=245;config=000001B0F5000001B50900000100000001 2000C888B0E0E0FA62D089028307
a=control:trackID=0 〃trackID=0表示視頻流用的是通道O 2、 PLAY
客戶端發送的改進後的PLAY請求PLAY rtsp:〃192. 168. 20. 136:5000/xxx666/tracklDO; trackID二l
RTSP/l. 0 CSeq: 4
Session: 6310936469860791894
Range: npt=0. 000- 〃設置播放時間的範圍
Transport: RTP/AVP/TCP;unicast;interleaved二O-l
User-Agent: QTS .. qtver=6. 5. 1. . os=Windows NT 5. IService Pack 2..
伺服器回應改進後的PLAY信息 RTSP/l. 0 200 OK Server: UServer 0. 9. 7_rcl Cseq: 4
Session: 6310936469860791894 Range:叩t二O. 000000-
RTP-Info:url=trackID=0;seq=17040;rtptime=1467265309;url=trackl D=l; seq=l; rtptime二O〃seq禾口 rtptime都是rtp包中的信息 Tran印ort: RTP/AVP/TCP; unicast; interleaved=0-1; ssrc二6B8B4567
3、 TEARDO麗 客戶端發起關閉請求
TEARDOWN rtsp:〃192. 168. 20. 136:5000/xxx666 RTSP/l. 0 CSeq: 5
Session: 6310936469860791894
User—Agent: QTS . . qtver=6. 5. 1. . os二Windows NT 5.IService Pack 2..
伺服器回應
RTSP/l. 0 200 OK
Server: UServer 0.9.7_rcl
Cseq: 5
Session: 6310936469860791894
12Connection: Close
經過本文所述的方法改進後，把目前的RTSP六個交互過程縮減為三個，不 考慮播放結束時的交互過程的話(因為這個交互過程不會影響到用戶開始播放 時的等待時間)，那改進後的交互過程就盡有二個，如果網絡延遲為l秒的話， 只需要4秒就能完成流媒體伺服器與客戶端的交互，如果網絡延遲為0.5秒的 話，這個過程就會縮減為2秒，從而縮短用戶的等待時間，極大的提高了用戶 的體驗效果。
在上述實施例中，僅對本發明進行了示範性描述，但是本領域技術人員在 不脫離本發明所保護的範圍和精神的情況下，可根據不同的實際需要設計出各 種實施方式。
權利要求
1.一種提高無線流媒體系統連接速度的方法，所述流媒體系統包括客戶端與伺服器，所述方法基於RTSP協議傳輸數據，其特徵在於，所述方法如下A1客戶端向服務端發起DESCRIBE請求，以獲取會話描述信息SDP，A2伺服器向客戶端回應對此會話的描述信息；B1客戶端向服務端發送的改進後的PLAY請求，B2伺服器和客戶端回應改進後的PLAY信息。
2、 如權利要求1所述的提高無線流媒體系統連接速度的方法，其特徵在於所述發送的改進後的PLAY請求以及回應改進後的PLAY信息稱為改進後的PLAY方法為，該改進後的PLAY方法如下將SETUP方法的音頻視頻需要二次交互過程以及PLAY方法的交互過程三個交互過程整合起來，合併為一個交互來完成上述三個方法的功能，其中所述SETUP方法是建立會話及傳輸方法。
3、 如權利要求1所述的提高無線流媒體系統連接速度的方法，其特徵在於所述方法還包括CI:客戶端發起關閉請求，C2:服務端回應關閉請求。
4、 如權利要求1所述的提高無線流媒體系統連接速度的方法，其特徵在於-客戶端在收到DESCRIBE方法的回應包後立即發送改進過的PLAY方法，在PLAY這個方法中包含客戶端要播放的媒體的trackID即位置信息，媒體包括視頻與音頻，或是其中的任意一個，視頻與音頻的會話信息不再分開發送，而是一起發送。
5、 如權利要求2所述的提高無線流媒體系統連接速度的方法，其特徵在於所述PLAY方法中還包括傳輸的模式及起始播放的時間。在流媒體伺服器的回應信息中則包含對傳輸模式的確認及媒體數據的會話通道，媒體數據包中的起始序列號與媒體數據包的中起始時間戳，其中媒體包括視頻與音頻，或是其中的任一個，視頻與音頻的會話信息不再分開發送。
6、如權利要求1所述的提高無線流媒體系統連接速度的方法，其特徵在於: 網絡延遲時間為1秒，則二個交互過程累積的網絡延遲時間為4秒。
全文摘要
本發明涉及一種提高無線流媒體系統連接速度的方法，所述流媒體系統包括客戶端與伺服器，所述方法基於RTSP協議傳輸數據，其特徵在於，所述方法如下A1客戶端向服務端發起DESCRIBE請求，以獲取會話描述信息SDP；A2伺服器向客戶端回應對此會話的描述信息；B1客戶端向服務端發送的改進後的PLAY請求，B2伺服器和客戶端回應改進後的PLAY信息。C1客戶端發起關閉請求，C2服務端回應關閉請求。
文檔編號H04W76/02GK101662839SQ200910190138
公開日2010年3月3日 申請日期2009年9月9日 優先權日2009年9月9日
發明者鄒聯忠 申請人:深圳市融創天下科技發展有限公司