2. 程式人生 > >H264視訊傳輸、編解碼----RTSP協議

H264視訊傳輸、編解碼----RTSP協議

阿新 • • 發佈：2019-01-28

RTSP(Real Time Streaming Protocol), 實時流傳輸協議,

  • 它是TCP/IP協議體系中的一個應用層協議
  • 它是對流媒體進行控制 的網路控制協議，可以對流媒體提供諸如播放、暫停、快進、停止等操作，它負責定義具體的控制訊息、操作方法、狀態碼等，此外還描述了與RTP間的互動操作。
  • 但是，實時流的傳輸並不是它負責，而是交給RTP、RTCP協議。
  • RTSP傳送的指令一般通過TCP進行傳輸，以保證服務端會收到。
  • 而在RTP/RTCP協議下實時流的傳輸 通過UDP傳輸，以保證資料的實時性。在實際情況下，是允許實時流少量的丟幀。

RTSP通用欄位解釋

1、請求頭欄位

下面是所有命令都接受的頭欄位型別，一些命令接受或者必須用到一些附加的特別的頭欄位。

  • Authorization 客戶端的認證資訊.
  • CSeq 請求序列號.
  • Session 會話 ID (返回自服務端的 SETUP 應答).
  • Content-Length 內容的長度.
  • Content-Type 內容的媒體型別.
  • User-Agent 關於建立這個請求的客戶端的資訊.
  • Require 查詢是否支援指定的選項，不支援的選項會在 Unsupported 頭中列出.

2、請求回覆欄位

RTSP/1.0 < Status Code> < Reason Phrase> < CRLF>
Headerfield3: val3< CRLF>
Headerfield4: val4< CRLF>
…
< CRLF>
[Body]

應答的第一行包含了表示請求是否成功或者失敗的狀態碼和原因短語，在 RFC 2326 有對狀態碼的詳細描述，如下：

”100” ; Continue (all 100 range)
“200” ; OK
”201” ; Created
”250” ; Low on Storage Space
”300” ; Multiple Choices
”301” ; Moved Permanently
”302” ; Moved Temporarily
”303” ; See Other
”304” ; Not Modified
”305” ; Use Proxy
”350” ; Going Away
”351” ; Load Balancing
”400” ; Bad Request
”401” ; Unauthorized
”402” ; Payment Required
”403” ; Forbidden
”404” ; Not Found
”405” ; Method Not Allowed
”406” ; Not Acceptable
”407” ; Proxy Authentication Required
”408” ; Request Time-out
”410” ; Gone
”411” ; Length Required
”412” ; Precondition Failed
”413” ; Request Entity Too Large
”414” ; Request-URI Too Large
”415” ; Unsupported Media Type
”451” ; Parameter Not Understood
”452” ; reserved
”453” ; Not Enough Bandwidth
”454” ; Session Not Found
”455” ; Method Not Valid in This State
”456” ; Header Field Not Valid for Resource
”457” ; Invalid Range
”458” ; Parameter Is Read-Only
”459” ; Aggregate operation not allowed
”460” ; Only aggregate operation allowed
”461” ; Unsupported transport
”462” ; Destination unreachable
”500” ; Internal Server Error
”501” ; Not Implemented
”502” ; Bad Gateway
”503” ; Service Unavailable
”504” ; Gateway Time-out
”505” ; RTSP Version not supported
”551” ; Option not supported

下面的頭欄位可以在所有的 RTSP 應答訊息中包含。

CSeq ：應答序列號 (和請求序列匹配).
Session ：會話 ID.
WWW-Authenticate ：客戶端的認證資訊.
Date ：應答的日期和時間.
Unsupported ：服務端不支援的特性和功能.

RTSP請求

RTSP請求指令有DESCRIBE, SETUP, OPTIONS, PLAY, PAUSE, TEARDOWN 或 SET_PARAMETER 等。

1、RTSP DESCRIBE

DESCRIBE 命令用於請求指定的媒體流的 SDP ( Session Description Protocol,會話描述協議) 描述資訊。
DESCRIBE 請求訊息接受如下附加的頭欄位：

Accept ：列出客戶支援的內容型別 (application/sdp is the only supported type).

DESCRIBE 命令的應答訊息包含如下附加的頭欄位：

Content-Type ：內容型別 (application/sdp).
Content-Length ：SDP 描述串的長度.
Content-Base ：如果 SDP 描述串中使用了相對 URL, 這裡是相關的基本 URL.

例如：
請求

DESCRIBE rtsp://myserver/live.mp4 RTSP/1.0
CSeq: 0
User-Agent: Vision MC
Accept: application/sdp
Authorization: Basic cm9vdDpwYXNz

回覆

RTSP/1.0 200 OK
CSeq: 0
Content-Type: application/sdp
Content-Base: rtsp://myserver/live.mp4
Date: Wed, 16 Jul 2008 12:48:47 GMT
Content-Length: 847
v=0//以下都是SDP資訊
o=- 1216212527554872 1216212527554872 IN IP4 myserver
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:50064
t=0 0
a=control:rtsp://myserver/live.mp4
&resolution=640x480
a=range:npt=0.000000-
m=video 0 RTP/AVP 96 //m表示媒體描述, 下面是對會話中視訊通道的媒體描述
b=AS:50000
a=framerate:30.0
a=control:rtsp://myserver/live.mp4?trackID=1//trackID＝1表示視訊流用的是通道1
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0IAKeKQFAe2AtwEBAaQeJEV,aM48gA==
m=audio 0 RTP/AVP 97//m表示媒體描述, 下面是對會話中音訊通道的媒體描述
b=AS:64
a=control:rtsp://myserver/live.mp4?trackID=2//trackID＝2表示視訊流用的是通道2
a=rtpmap:97 mpeg4-generic/16000/1
a=fmtp:97 profile-level-id=15; mode=AAC-hbr;config=1408; SizeLength=13; IndexLength=3;IndexDeltaLength=3; Profile=1; bitrate=64000;

2、RTSP OPTIONS

OPTIONS 請求用於返回服務端支援的 RTSP 命令列表 。也可以定時傳送這個請求來保活相關的 RTSP 會話
請求

OPTIONS * RTSP/1.0
CSeq: 1
User-Agent: Vision MC
Session: 12345678
Authorization: Basic cm9vdDpwYXNz

應答

RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Public: DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Date: Wed, 16 Jul 2008 12:48:48 GMT

回覆欄位中Public欄位列出了支援的 RTSP 命令。

3、RTSP SETUP

SETUP 命令用於配置資料傳輸的方法，比如Transport欄位指定了客戶端支援的傳輸方式RTP協議，以及指定了客戶端RTP和RTCP的埠，並建立會話session，這個Session ID在以後的請求中都會使用。
請求

SETUP rtsp://myserver/live.mp4?trackID=1 RTSP/1.0
CSeq: 2
User-Agent: Vision MC
Transport: RTP/AVP;unicast;client_port=20000-20001
Authorization: Basic cm9vdDpwYXNz
//uri中 帶有trackID＝0, 表示對該通道進行設定. 
//Transport引數設定了傳輸模式, 客戶端埠.

這裡指定了伺服器的rtsp路徑，CSeq表示當前請求的的序號，Transport指定了使用RTP協議進行實時流的傳輸；unicast表示單播傳輸，一對一；client_port表示RTP/RTCP協議在客戶端的埠號。分別支援 RTP/AVP;
unicast;
client_port=port1-port2 RTP/AVP;
multicast;
client_port=port1-port2 RTP/AVP/TCP;
unicast
等不同的傳輸方式
RTP/AVP/TCP表示通過TCP傳輸RTP包，RTP/AVP/UDP表示使用UDP傳輸RTP包。
應答

RTSP/1.0 200 OK
CSeq: 2
Session: 12345678; timeout=60
Transport: RTP/AVP;unicast;client_port=20000-20001;
       server_port=50000-50001;ssrc=B0BA7855;mode="PLAY"
Date: Wed, 16 Jul 2008 12:48:47 GMT

服務端返回的資料中server_port表示RTP/RTCP協議在服務端的埠號，客戶端可以去繫結這兩個埠，從而可以進行通訊。
在以後的請求中，都需要帶上這個Session，以表示在同一個會話中
請求

SETUP rtsp://myserver/live.mp4
trackID=2 RTSP/1.0
CSeq: 3
User-Agent: Vision MC
Transport: RTP/AVP;unicast;client_port=20002-20003
Session: 12345678
Authorization: Basic cm9vdDpwYXNz

應答

RTSP/1.0 200 OK
CSeq: 3
Session: 12345678; timeout=60
Transport: RTP/AVP;unicast;client_port=20002-20003;server_port=50002-50003;ssrc=D7EB59C0;mode="PLAY"
Date: Wed, 16 Jul 2008 12:48:48 GMT

如果這個 Session 頭欄位包含了 timemout 引數, 除非有保活，否則會話會在超時時間後被關閉。
會話可以通過傳送包含 Session ID 的 RTSP 請求 (如 OPTIONS，GET_PARAMETER) 給服務端來保活。 或者使用 RTCP 訊息。

4、RTSP PLAY

這個 PLAY 用於啟動 (當暫停時重啟) 傳輸實時流資料給客戶端.
例如：

請求

PLAY rtsp://myserver/live.mp4 RTSP/1.0
CSeq: 4
User-Agent: Vision MC
Range: npt=0.000- //設定播放時間的範圍
Session: 12345678
Authorization: Basic cm9vdDpwYXNz

應答

RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
Range: npt=0.645272-//設定播放時間的範圍
RTP-Info: url=rtsp://myserver/live.mp4? trackID=1;seq=46932;rtptime=1027887748, url=rtsp://myserver/live.mp4?trackID=2;seq=3322;rtptime=611053482
Date: Wed, 16 Jul 2008 12:48:48 GMT

例如： 還可以指定相應ID的資原始檔，Play back the recording “myrecording”.
請求

PLAY rtsp://myserver/live.mp4?recordingid=”myrecording” RTSP/1.0
CSeq: 4
User-Agent: Vision MC
Session: 12345678
Authorization: Basic cm9vdDpwYXNz

Range ：播放時間段.
RTP-Info ：關於 RTP 流的資訊。包含相關的流的第一個包的序列號。

5、RTSP PAUSE

PAUSE 請求用於臨時停止服務端的資料的傳輸。使用 PLAY 來重新啟動資料傳輸。
例如：
請求

PAUSE rtsp://myserver/live.mp4 RTSP/1.0
CSeq: 5
User-Agent: Vision MC
Session: 12345678
Authorization: Basic cm9vdDpwYXNz

應答

RTSP/1.0 200 OK
CSeq: 5
Session: 12345678
Date: Wed, 16 Jul 2008 12:48:49 GMT

這裡的RTSP/1.0表示RTSP協議的版本；

6、RTSP TEARDOWN

TEARDOWN 請求用於終止來自服務端的資料的傳輸。
例如：
請求

TEARDOWN rtsp://myserver/live.mp4 RTSP/1.0
CSeq: 6
User-Agent: Vision MC
Session: 12345678
Authorization: Basic cm9vdDpwYXNz

應答

RTSP/1.0 200 OK
CSeq: 6
Session: 12345678
Date: Wed, 16 Jul 2008 12:49:01 GMT

7、RTSP SET_PARAMETER

SET_PARAMETER 命令用於請求儘快生成一個 I 幀。例如當開始錄影的時候。必須包含 X-Request-Key-Frame: 1 的頭欄位。
請求

SET_PARAMETER rtsp://myserver/live.mp4 RTSP/1.0
CSeq: 7
Session: 12345678
Authorization: Basic cm9vdDpwYXNz
X-Request-Key-Frame: 1
Content-Type: text/parameters
Content-Length: 19
Renew-Stream: yes

應答

RTSP/1.0 200 OK
CSeq: 8
Session: 12345678
Date: Wed, 16 Jul 2008 13:01:25 GMT

8、RTSP GET_PARAMETER

標準協議中 GET_PARAMETER 可以用於查詢引數狀態, 目前裝置主要通過 GET 命令來查詢裝置引數, 所以 GET_PARAMETER 用處不大, 目前主要用來用做會話保活請求.
請求

GET_PARAMETER rtsp://myserver/live.mp4 RTSP/1.0
CSeq: 7
Session: 12345678
Authorization: Basic cm9vdDpwYXNz

應答

RTSP/1.0 200 OK
CSeq: 8
Session: 12345678
Date: Wed, 16 Jul 2008 13:01:25 GMT

9、RTSP REDIRECT

當 流媒體伺服器有上百臺， 需要動態的選擇一臺均衡負載最小的伺服器， 或者選擇一臺離客戶端機器最近的一臺伺服器提供流服務的時候，我們可以利用 rtsp協議的redirect 機制進行重定向。
實現原理很簡單：
client -> server 發出 rtsp請求
伺服器收到請求後, 取出 客戶端的 IP 地址， 根據客戶端的IP地址， 判斷客戶端所在的地區， 在客戶端所在地的伺服器中選擇一臺負載最小的伺服器。通過 redirect 協議 的Location ， 指定重定向的新地址即可完成任務。

RTSP/1.0 301 Moved
CSeq : 2
Location: rtsp://192.168.2.33/mp4/f1.ts
Range:Clock=20180101T123456Z-

客戶端收到該協議描述， 既會連線新的伺服器進行流請求。
Range欄位規定了客戶端在2018年1月1日12點34分56秒進行重定向。

10、RTSP RECORD

用於請求伺服器錄一段內容，包括音視訊。時間戳表示錄製的開始/結束時間，格式為UTC時間。

11、RTSP ANNOUNCE

該方法方法有兩個目的：

  • 當從客戶端發往伺服器端，ANNOUNCE向伺服器端上傳請求URL所標識的表示或媒體物件的描述。
  • 當從伺服器端發往客戶端，ANNOUNCE實時更新會話描述。
    當一個新的媒體流加入Session時（比如之前只有視訊流，現在加入音訊流），需要通知客戶端，讓客戶端做出是否接入音訊流的選擇。

RTSP基本請求流程

C表示rtsp客戶端, S表示rtsp服務端

1. C->S:OPTION request //詢問S有哪些方法可用
1. S->C:OPTION response //S迴應資訊中包括提供的所有可用方法
2. C->S:DESCRIBE request //要求得到S提供的媒體初始化描述資訊
2. S->C:DESCRIBE response //S迴應媒體初始化描述資訊, 主要是sdp
3. C->S:SETUP request //設定會話的屬性, 以及傳輸模式, 提醒S建立會話
3. S->C:SETUP response //S建立會話, 返回會話識別符號, 以及會話相關資訊
4. C->S:PLAY request //C請求播放
4. S->C:PLAY response //S迴應該請求的資訊
   S->C:傳送流媒體資料
5. C->S:TEARDOWN request //C請求關閉會話
5. S->C:TEARDOWN response //S迴應該請求

SDP協議

會話描述協議（SDP）為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。

* v = （協議版本）
* o = （所有者/建立者和會話識別符號）
* s = （會話名稱）
* i = * （會話資訊）
* u = * （URI 描述）
* e = * （Email 地址）
* p = * （電話號碼）
* c = * （連線資訊 ― 如果包含在所有媒體中，則不需要該欄位）
* b = * （頻寬資訊）

一個或更多時間描述（如下所示）：

* z = * （時間區域調整）
* k = * （加密金鑰）
* a = * （0 個或多個會話屬性行）
* 0個或多個媒體描述（如下所示）

時間描述

* t = （會話活動時間）
* r = * （0或多次重複次數）

媒體描述

* m = （媒體名稱和傳輸地址）
* i = * （媒體標題）
* c = * （連線資訊 — 如果包含在會話層則該欄位可選）
* b = * （頻寬資訊）
* k = * （加密金鑰）
* a = * （0 個或多個會話屬性行

相關推薦

H264視訊傳輸、編解碼----RTSP協議

RTSP(Real Time Streaming Protocol), 實時流傳輸協議, 它是TCP/IP協議體系中的一個應用層協議 它是對流媒體進行控制 的網路控制協議，可以對流媒體提供諸如播放、暫停、快進、停止等操作，它負責定義具體的控制訊息、操作方法

【視訊開發】EasyIPCamera通過RTSP協議接入海康、大華等攝像機，摒棄私有SDK接入弊端

近期工作中需要開發一套視訊監控系統，實現WEB端、手機APP端預覽區域網內的道路監控攝像機，我負責一些後臺服務的開發工作。       由於之前專案中的程式都是採用私有協議、各攝像機廠商的SDK進行視訊監控系統開發，這種技術方案更適合C/S架構的系統，應用於此次專案存在

Android音視訊(四)MediaCodec編解碼AAC

Android音視訊(一) Camera2 API採集資料 Android音視訊(二)音訊AudioRecord和AudioTrack Android音視訊(三)FFmpeg Camera2推流直播 MediaCodec類可以訪問底層媒體編解碼框架（StageFright 或 OpenMAX），即編解碼

十、編解碼技術--Java序列化

Java自身的序列化機制，就是隻需要序列化的POJO物件實現Java.io.Serializable介面，根據實際情況生成序列ID，這個類就能夠通過java.io.ObjectInput和java.io.ObjectOutput序列化和反序列化。 服務端：N

九、編解碼技術

一、Java序列化 基於Java提供的物件輸入和輸出流(ObjectInputStream和ObjectOutputStream)，可以把Java物件作為可儲存的位元組陣列寫入檔案，也可以傳輸到網路中。對於我們開發人員來說，基於JDK預設的序列化機制

H264 編解碼協議詳解

1.、什麼是 H264？ H264 是 MPEG-4 標準所定義的最新編碼格式，同時也是技術含量最高、代表最新技術水平的視訊編碼格式之一，標準寫法應該是H.264 H264 視訊格式是經過有失真壓縮的，但在技術上儘可能做的降低儲存體積下獲得較好影象質量和低頻寬影象快速傳輸。

H264/AVC 視訊編解碼一些基本知識

本篇對學習H264常見的知識點做個備註。 1.H264編碼位元速率設定 對視訊進行編碼時，位元速率和視訊質量是一對矛盾的話題。一般位元速率越大，視訊丟棄冗餘資訊就越少，視訊質量就越高。但是位元速率達到一定程度，視訊質量人類無法識別，所以每種解析度都有一個閾值，編碼時按照閾值即可。一

文章索引-視訊協議，播放，編解碼

    FFmpeg Documentation ： https://www.ffmpeg.org/doxygen/trunk/index.html   : 文件 下載地址:  https://ffmpeg.zeranoe.

h264視訊編解碼

KevinLib開發類庫說明本類庫為快速發視訊系統必備參考之一，實現介面簡單，開放原始碼，可以無限制的重複使用 開發工具 VC++7.0 實現了視訊採集，音訊採集，壓縮解壓編碼：H264,MPEG4,WMV9,DIVX,XVID等 另外類庫裡有一些檔案操作類，介面十分簡單，十分鐘就可以建

從零開始的鐳射通訊（第1章 協議棧）——4、原始資料編解碼

從零開始的鐳射通訊（第1章 協議棧）——4、原始資料編解碼 github 簡介 移動位置法 提取最高位法 函式說明 github https://github.com/HaHaHaHaHaGe/mynet

視訊RTSP、RTMP和HTTP協議的區別

共同點： 1：RTSP RTMP HTTP都是在應用應用層。 3.理論上RTSP RTMPHTTP都可以做直播和點播，但一般做直播用RTSP RTMP，做點播用HTTP。做視訊會議的時候原來用SIP協議，現在基本上被RTMP協議取代了。 區別： 1：HTTP:

關注IOS、Android網路、音視訊編解碼、特效、Neon演算法優化，DSP等嵌入式驅動開發演算法移植

（1）音訊格式：典型WAV 封裝格式是每個音訊檔案必不可少的組成部分之一，它給我們提供了以下參考資訊。音訊檔案型別、編解碼方法、單雙聲道、取樣深度、取樣率、量化位數、音訊檔案大小、長度。下面首先來分析一下經典的wav音訊的封裝格式。個人精力有限不可能把每種音視訊格式都一一解

【H.264/AVC視訊編解碼技術詳解】二十三、幀間預測編碼(1)：幀間預測編碼的基本原理

《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼的形式操作一遍，才能對視訊壓

【H.264/AVC視訊編解碼技術詳解】二十二、熵編碼(7)：語法元素的CABAC解析

《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼的形式操作一遍，才能對視訊壓

【H.264/AVC視訊編解碼技術詳解】二十、H.264的去塊濾波演算法

《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼

關於視訊H264編解碼的應用實現

專案要用到視訊編解碼，最近半個月都在搞，說實話真是走了很多彎路，浪費了很多時間。將自己的最終成果記錄於此，期望會給其他人提供些許幫助。   參考教程： 整體過程流程如下： 顯而易見，整個過程分為三個部分：採集、

【H.264/AVC視訊編解碼技術詳解】十二、解析H.264碼流的巨集塊結構（上）

《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼

【H.264/AVC視訊編解碼技術詳解】十五、H.264的變換編碼（二）：H.264整數變換和量化的實現

《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼

【H.264/AVC視訊編解碼技術詳解】十三、熵編碼演算法（4）：H.264使用CAVLC解析巨集塊的殘差資料

《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼

【H.264/AVC視訊編解碼技術詳解】 九、序列引數集Sequence Paramater Set(SPS)解析

《H.264/AVC視訊編解碼技術詳解》視訊教程已經在“CSDN學院”上線，視訊中詳述了H.264的背景、標準協議和實現，並通過一個實戰工程的形式對H.264的標準進行解析和實現，歡迎觀看！ “紙上得來終覺淺，絕知此事要躬行”，只有自己按照標準文件以程式碼