一、什么是RTSP協(xié)議
RTSP是一個實(shí)時傳輸流協(xié)議，是一個應(yīng)用層的協(xié)議。通常說的RTSP包括RTSP協(xié)議、RTP協(xié)議、RTCP協(xié)議。
- RTSP協(xié)議：負(fù)責(zé)服務(wù)器與客戶端之間的請求與相應(yīng)
- RTP協(xié)議 ：負(fù)責(zé)服務(wù)器與客戶端之間傳輸媒體數(shù)據(jù)
-
RTCP協(xié)議：負(fù)責(zé)提供有關(guān)RTP傳輸指令的反饋，就是確保RTP傳輸?shù)馁|(zhì)量
吧
三者關(guān)系：RTSP并不會發(fā)送媒體數(shù)據(jù)，只是完成服務(wù)器和客戶端之間的交互。
RTP協(xié)議負(fù)責(zé)媒體數(shù)據(jù)傳輸，RTCP負(fù)責(zé)RTP數(shù)據(jù)包的監(jiān)視和反饋。RTP和RTCP并沒有規(guī)定傳輸層的類型，可以選擇UDP或者TCP。RTSP的傳輸層則是TCP。
二、協(xié)議分析
RTSP常用的方法包括：OPTIONS、DESCRIBE、ANNOUNCE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER等。
| 方法 | 方向 | 是否必須 | 含義 |
|---|---|---|---|
| OPTIONS | C->S | 否 | 查詢服務(wù)器支持的方法和協(xié)議選項(xiàng)，幫助客戶端了解服務(wù)器的能力和限制，以便進(jìn)行后續(xù)的實(shí)時流傳輸控制。 |
| DESCRIBE | C->S | 否 | 客戶端可以獲取到媒體流的詳細(xì)信息，例如媒體類型、編解碼格式、傳輸協(xié)議等，以便為后續(xù)的播放或者錄制操作做準(zhǔn)備。 |
| SETUP | C->S | 是 | 用于建立媒體傳輸?shù)耐ǖ??？蛻舳撕头?wù)器可以就媒體流的傳輸進(jìn)行協(xié)商，并最終確定有效的傳輸通道，為后續(xù)的播放或者錄制操作做準(zhǔn)備。 |
| PLAY | C->S | 是 | 客戶端告知服務(wù)器可以開始傳輸媒體流數(shù)據(jù)，服務(wù)器收到PLAY請求后即可開始向客戶端發(fā)送實(shí)時的媒體流數(shù)據(jù)，實(shí)現(xiàn)實(shí)時的音視頻播放。當(dāng)多個PLAY請求到達(dá)時，服務(wù)器會將PLAY請求排成隊(duì)列，順序執(zhí)行，即必須等待第一個PLAY的時間完成后，才會繼續(xù)處理第二個PLAY消息。 |
| 。。。 | 。。。 | 。。。 | 。。。 |
簡單的RTSP交互過程：
C表示RTSP客戶端，S表示RTSP服務(wù)端
1.C->S：OPTIONS request //詢問S有哪些方法可用
1.S->C：OPTIONS response //S回應(yīng)信息中包括提供的所有可用方法
2.C->S：DESCRIBE request //要求得到S提供的媒體初始化描述信息
2.S->C：DESCRIBE response //S回應(yīng)媒體初始化描述信息，主要是sdp
3.C->S：SETUP request //設(shè)置會話的屬性，以及傳輸模式，提醒S建立會話
3.S->C：SETUP response //S建立會話，返回會話標(biāo)識符，以及會話相關(guān)信息
4.C->S：PLAY request //C請求播放
4.S->C：PLAY response //S回應(yīng)該請求的信息
S->C：發(fā)送流媒體數(shù)據(jù)
5.C->S：TEARDOWN request //C請求關(guān)閉會話
5.S->C：TEARDOWN response //S回應(yīng)該請求文章來源：http://www.zghlxwxcb.cn/news/detail-858592.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-858592.html
連接信息交流過程（rbuf為客戶端發(fā)送信息 ， sbuf為服務(wù)器發(fā)送信息）
accept client;client ip : xxx.xxx.xxx.xxx,client port:62922
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = OPTIONS rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
CSeq: 1
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Public: OPTIONS, DESCRIBE, SETUP, PLAY
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = DESCRIBE rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
Accept: application/sdp
CSeq: 2
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Content-Base: rtsp://xxx.xxx.xxx.xxx:8554
Content-type: application/sdp
Content-length: 128
v=0
o=- 91710247606 1 IN IP4 xxx.xxx.xxx.xxx
t=0 0
a=control:*
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:track0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = SETUP rtsp://xxx.xxx.xxx.xxx:8554/track0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;client_port=10150-10151
CSeq: 3
User-Agent: Lavf60.13.100
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Transport: RTP/AVP;unicast;client_port=10150-10151;server_port=55532-55533
Session: 66334873
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
doClient rBuf = PLAY rtsp://xxx.xxx.xxx.xxx:8554 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent: Lavf60.13.100
Session: 66334873
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
doClient sBuf = RTSP/1.0 200 OK
CSeq: 0
Range: npt=0.000-
Session: 66334873; timeout=10
start play
client ip:xxx.xxx.xxx.xxx
client port:10150
三、RTPHeader分析
* 0 1 2 3
* 7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* |V=2|P|X| CC |M| PT | sequence number |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* | timestamp |
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* | synchronization source (SSRC) identifier |
* +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
* | contributing source (CSRC) identifiers |
* : .... :
* +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
struct RtpHeader
{
/* byte 0 */
uint8_t csrcLen : 4;//CSRC計(jì)數(shù)器，占4位，指示CSRC 標(biāo)識符的個數(shù)。（多路流匯成一路流時會用到）
uint8_t extension : 1;//占1位，如果X=1，則在RTP報(bào)頭后跟有一個擴(kuò)展報(bào)頭。
uint8_t padding : 1;//填充標(biāo)志，占1位，如果P=1，則在該報(bào)文的尾部填充一個或多個額外的八位組，它們不是有效載荷的一部分。
uint8_t version : 2;//RTP協(xié)議的版本號，占2位，當(dāng)前協(xié)議版本號為2。
/* byte 1 */
uint8_t payloadType : 7;//有效載荷類型，占7位，用于說明RTP報(bào)文中有效載荷的類型，如GSM音頻、JPEM圖像等。
uint8_t marker : 1;//標(biāo)記，占1位，不同的有效載荷有不同的含義，對于視頻，標(biāo)記一幀的結(jié)束；對于音頻，標(biāo)記會話的開始。
/* bytes 2,3 */
uint16_t seq;//占16位，用于標(biāo)識發(fā)送者所發(fā)送的RTP報(bào)文的序列號，每發(fā)送一個報(bào)文，序列號增1。接收者通過序列號來檢測報(bào)文丟失情況，重新排序報(bào)文，恢復(fù)數(shù)據(jù)。
/* bytes 4-7 */
uint32_t timestamp;//占32位，時戳反映了該RTP報(bào)文的第一個八位組的采樣時刻。接收者使用時戳來計(jì)算延遲和延遲抖動，并進(jìn)行同步控制。
/* bytes 8-11 */
uint32_t ssrc;//占32位，用于標(biāo)識同步信源。該標(biāo)識符是隨機(jī)選擇的，參加同一視頻會議的兩個同步信源不能有相同的SSRC。
/*標(biāo)準(zhǔn)的RTP Header 還可能存在 0-15個特約信源(CSRC)標(biāo)識符
每個CSRC標(biāo)識符占32位，可以有0～15個。每個CSRC標(biāo)識了包含在該RTP報(bào)文有效載荷中的所有特約信源
*/
};
到了這里，關(guān)于【音視頻開發(fā)】：RTSP服務(wù)器協(xié)議內(nèi)容的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
