国产无码综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

<label id="g2j3a"></label>

<mark id="g2j3a"></mark>

流媒體協(xié)議之RTSP詳解

2年前作者：^一二三^分類：Toy博客閱讀(25)違法舉報

這篇具有很好參考價值的文章主要介紹了流媒體協(xié)議之RTSP詳解。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

1 流媒體協(xié)議之RTSP詳解

1.1 RTSP概述

RTSP(Real Time Streaming Protocol):實時流媒體協(xié)議,是由Real network 和 Netscape共同提出的如何有效地在IP網(wǎng)絡上傳輸流媒體數(shù)據(jù)的應用層協(xié)議，RTSP提供一種可擴展的框架，使能夠提供能控制的，按需傳輸實時數(shù)據(jù)，如音頻流、視頻流、metadata; 遵循規(guī)范IETF RFC 2326,4567,6064，其語法和操作參考了HTTP/1.1，基于文本的協(xié)議，采用ISO10646字符集，使用UTF-8編碼；承載RTSP的傳輸層協(xié)議為TCP，默認端口554；如果是RTSP-over-HTTP tunneling，則默認TCP端口為8080；實時流數(shù)據(jù)由不同的協(xié)議傳輸，比如RTP/RTCP完成數(shù)據(jù)流和控制命令的傳輸。
RTSP支持的方法如下：
流媒體協(xié)議之RTSP詳解

RTSP流媒體協(xié)議交互及碼流傳輸過程中所用的協(xié)議如下：
流媒體協(xié)議之RTSP詳解

后續(xù)會對相關協(xié)議進行詳細介紹，這些協(xié)議相互配合，功能完成了流媒體協(xié)議會話及碼流傳輸?shù)倪^程。
可通過請關注公眾號壹零倉，發(fā)送消息獲取，發(fā)送rtsp，獲取rtsp相關文章，發(fā)送rtp，獲取rtp/rtcp相關文章

1.2 RTSP協(xié)議交互過程

RTSP協(xié)議通常是基于TCP的方式進行協(xié)議交互，另外也可基于HTTP，其交互過程有所不通，協(xié)議交互主要實現(xiàn)流媒體信息描述/碼流通道建立/流媒體控制等功能，這里要區(qū)分RTSP協(xié)議交互與流媒體碼流傳輸，RTSP協(xié)議交互，只做流媒體會話交互功能，通過describe來同步流媒體編碼、封裝、連接等信息，通過setup來建立流媒體傳輸通道，通過play來開啟流媒體播放，通過teardown來結束播放；流媒體碼流的傳輸是通過RTSP交互建立的流媒體傳輸通道來傳輸碼流，其傳輸協(xié)議一般為RTP/RTCP，其傳輸層可以為UDP或者TCP。

1.2.1 RTSP基于TCP交互過程

承載RTSP的協(xié)議為TCP，其主要交互過程如下圖所示：
流媒體協(xié)議之RTSP詳解

RTSP返回的狀態(tài)碼與HTTP類似，各個方法的說明也很簡單也不做過多的說明，再開發(fā)中，RTSP客戶端可以直接發(fā)送describe，而無強制要求必須要發(fā)送option，describe之后，根據(jù)其攜帶的SDP信息，判斷流媒體的編碼格式/封裝格式/payloadtype/timescale，track標識等信息，客戶端保存此信息用于后續(xù)碼流的解復用和解碼，根據(jù)track標識去申請想要的類型的碼流，客戶端通過setup來建立碼流通道，如果有多路，需要根據(jù)不通的track 調(diào)用setup方法多次，一般setup建立通道可以是rtp/avp或者rtp/avp/tcp類型，這里標識以rtp傳輸音視頻，前者基于UDP傳輸，后者基于TCP傳輸，這里要注意基于UDP傳輸碼流時，需要根據(jù)setup交互的信息，單獨建立RTP/RTCP兩路UDP通道，如果是TCP則與RTSP公用一個TCP通道，通過在RTP/RTCP頭加上$開頭的四個字節(jié)的tcpheader來區(qū)分是哪一路的RTP/RTCP，還是RTSP。
流媒體協(xié)議之RTSP詳解

1.2.2 RTSP基于HTTP的交互過程

RTSP-over-HTTP tunneling，通過HTTP隧道來傳輸RTSP協(xié)議和媒體流，需要RTSP服務器支持此種方式，開啟HTTP隧道監(jiān)聽端口；客戶端首先會建立一個鏈接通過HTTP-GET方法來獲取協(xié)議響應消息和媒體流，然后再建立一個鏈路，通過HTTP-POST方法來發(fā)送請求消息，兩個tcp鏈接都是長連接，POST 連接中發(fā)送RTSP請求消息，一般要進行BASE64編碼，來隱藏RTSP信息。數(shù)據(jù)流的發(fā)送封裝方式與RTP/TCP一樣，通過GET鏈路發(fā)送給客戶端，響應消息也是通過GET鏈路發(fā)送給客戶端，其流程如下：
流媒體協(xié)議之RTSP詳解

1.3 RTSP協(xié)議拉流詳解

RTSP協(xié)議交互無論是基于TCP，還是HTTP，或者近期比較流行的無插件播放的RTSP OVER websocket方式，其協(xié)議交互流程不變，以下按照客戶端拉流的協(xié)議交互順序，對RTSP協(xié)議各個方法極其響應進行詳細說明。

1.3.1 OPTION方法

請求及響應實例如下：

OPTIONS rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0
CSeq: 2
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)

RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER
Date:  Wed, Jul 27 2022 10:37:06 GMT

此方法主要用來詢問流媒體服務器支持哪些RTSP方法，此例子說明服務器支持OPTIONS, DESCRIBE, PLAY, PAUSE, SETUP, TEARDOWN, SET_PARAMETER, GET_PARAMETER，此方法不是交互必須的，客戶端可以跳過此方法直接發(fā)describe，服務器需要注意兼容。

1.3.2 DESCRIBE方法

從服務器獲取媒體流相關的信息，可以包含多個媒體流類型極信息，通過SDP來描述和區(qū)分不通媒體類型的媒體源，客戶端根據(jù)服務器支持的媒體源通過setup建立媒體流通道，其實例如下：

DESCRIBE rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0
CSeq: 3
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

RTSP/1.0 401 Unauthorized
CSeq: 3
WWW-Authenticate: Digest realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", stale="FALSE"
Date:  Wed, Jul 27 2022 10:37:06 GMT

DESCRIBE rtsp://10.45.12.141:554/h264/ch1/main/av_stream RTSP/1.0
CSeq: 4
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream", response="be7cde07af4a08db991dd58a89db7621"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Accept: application/sdp

RTSP/1.0 200 OK
CSeq: 4
Content-Type: application/sdp
Content-Base: rtsp://10.45.12.141:554/h264/ch1/main/av_stream/
Content-Length: 574

v=0
o=- 1658918226996159 1658918226996159 IN IP4 10.45.12.141
s=Media Presentation
e=NONE
b=AS:5050
t=0 0
a=control:rtsp://10.45.12.141:554/h264/ch1/main/av_stream/
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:5000
a=recvonly
a=x-dimensions:1920,1080
a=control:rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1
a=rtpmap:96 H265/90000
a=fmtp:96 sprop-sps=QgEBAWAAAAMAsAAAAwAAAwB7oAPAgBDlja5JMvTcBAQEAg==; sprop-pps=RAHA8vA8kAA=
a=Media_header:MEDIAINFO=494D4B48010300000400050000000000000000000000000000000000000000000000000000000000;
a=appversion:1.0

這里客戶端發(fā)送describe時，一般服務器會進行用戶鑒權，如果未攜帶Authorization鑒權信息，或者認證失敗，服務器會返回錯誤號為401的響應，客戶端接收到401響應時，需要根據(jù)已知的用戶鑒權信息，生成Authorization，再次發(fā)送describe，如果認證成功，服務器返回攜帶有SDP的響應信息。
有關SDP協(xié)議的詳細解釋，請參照我的另一篇文章：
h264和h265視頻流SDP描述詳解

有關服務器端SDP描述，這里提醒一下，fmtp要根據(jù)碼流的真實信息填寫，不要隨意填寫，在網(wǎng)頁無插件播放時，越來越多的播放插件對這個字段要求很嚴格，因為網(wǎng)頁客戶端解碼時，一般通過此字段來初始化解碼庫，所以此字段的填寫，需要注意，要根據(jù)真實的編碼參數(shù)來編寫。

1.3.3 SETUP方法

此方法根據(jù)流媒體服務器返回的SDP描述信息，進行流媒體傳輸通道的建立，如果sdp描述多個媒體源，客戶端可根據(jù)需要建立媒體傳輸鏈路，play方法后，服務器根據(jù)setup建立的媒體流傳輸通道發(fā)送媒體流，一般有RTP over udp和RTP over tcp兩張流的傳輸方式，其setup有一定的區(qū)別。

RTP OVER UDP抓包實例：

SETUP rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1 RTSP/1.0
CSeq: 5
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="c4c4e29b1620211e44ec28b077e2eb52", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="ac52cf287fe4aa6be5bb168bc9d01446"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=63538-63539

RTSP/1.0 200 OK
CSeq: 5
Session:       1279114011;timeout=60
Transport: RTP/AVP;unicast;client_port=63538-63539;server_port=8312-8313;ssrc=3cc5faf7;mode="play"
Date:  Wed, Jul 27 2022 10:37:07 GMT

首先客戶端側，SETUP的path路徑，加上了trackID=1,表示建立的時trackID=1的媒體源的碼流傳輸通道，通過上文SDP描述可知，此路時編碼類型為H265，payloadtype=96的視頻源，這里要注意，一個setup只能給一種媒體源建立流傳輸通道。如果服務器需要認證，setup也需要帶上認證信息Authorization，Transport字段表示客戶端通過何種方式申請建立媒體流傳輸通道，這里RTP/AVP表示通過UDP方式;unicast表示單播方式(也支持組播，比較少用，這里不做介紹)，如果為UDP方式，則有client_port字段，client_port=63538-63539表示客戶端測此路碼流的RTP端口為UDP63538，RTCP端口為UDP63539；這里注意建立RTP碼流傳輸通道時，RTP和RTCP要成對出現(xiàn)，一般碼流端口號為RTCP=RTP+1
服務器響應時，如果支持客戶端的傳輸方式，則Transport字段中，RTP/AVP;unicast；client_port=63538-63539;要與客戶端申請的消息保持一致，增加server_port字段，表示服務器發(fā)送RTP/RTCP的UDP端口，可選增加ssrc標識。這里要注意，服務端回復setup時，將會生成一個session ID.后續(xù)消息必須帶有此Session字段。

RTP OVER TCP抓包實例：

SETUP rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1 RTSP/1.0
CSeq: 5
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="59db6d7ba1acb14582356c8bb8e61ce8", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="129818708e48cd0326f8b6f1b19613a3"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

RTSP/1.0 200 OK
CSeq: 5
Session:       2095163832;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=24e4e500;mode="play"
Date:  Fri, Aug 26 2022 14:35:46 GMT

RTP通過TCP傳輸時，與UDP方式在SETUP方法上有一定的區(qū)別，主要是Transport頭，RTP/AVP/TCP表示RTP流通過TCP傳輸，當此值出現(xiàn)時，其沒有client_port字段，出現(xiàn)interleaved字段，interleaved=0-1，表示streamid，前文已經(jīng)介紹了，當碼流通過TCP傳輸時，與RTSP共用一個TCP鏈路，所以其不需要建立新的連接，為了區(qū)分RTP、RTCP及RTSP協(xié)議，需要增加包頭標識，這里采用TCPHEAD頭字段，tcphead為四個字節(jié)，格式如下：
| magic number | channel number | embedded data length | data |

magic number： 1 byte value of hex 0x24（$），標識傳輸?shù)氖菙?shù)據(jù)不是rtsp協(xié)議
channel number： 1 byte value to denote the channel，信道ID，標識流的類型
embedded data length ：2 bytes to denote the embedded data length，流長度
data: 表示RTP/RTCP包數(shù)據(jù)

當TCP接收到的包開頭為24時，可以判定其為RTP或者RTCP，通過streamid來卻分，setup方法中interleaved=0-1，標識RTP的streamid=0；RTCP的streamid=1
tcphead抓包實例如下：
流媒體協(xié)議之RTSP詳解

第一個24000014標識此包為RTP包長度為0x14，解析時只需要根據(jù)streamid及長度讀取完整的RTP幀，去掉四字節(jié)頭，通過RTP方式解析即可。由于TCP時流式傳輸，需要連續(xù)根據(jù)24標識判斷。

1.3.4 PLAY方法

PLAY消息是告訴服務器端可以使用在SETUP消息中所指定的傳輸機置開始傳送數(shù)據(jù)。需要指出的是，客戶端不應該發(fā)送任何PLAY請求直到所有的SETUP消息被成功解析。PLAY消息會在range中指定媒體的播放時間，服務器在接到PLAY消息后會由range中指定的開始點開始發(fā)送媒體數(shù)據(jù)直到range中指定的結束點，PlAY可帶有scale和speed字段用于點播速度控制。對于實時流range一般為Range: npt=0.000

PLAY rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ RTSP/1.0
CSeq: 6
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="59db6d7ba1acb14582356c8bb8e61ce8", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="0eef224891c12e902ca9185c70f969cc"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Session: 2095163832
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 6
Session:       2095163832
RTP-Info: url=rtsp://10.45.12.141:554/h264/ch1/main/av_stream/trackID=1;seq=29458;rtptime=2518517708
Date:  Fri, Aug 26 2022 14:35:46 GMT

play方法需要帶上Session字段表示統(tǒng)一會話，此Session由setup時服務端返回，客戶端發(fā)送play方法后，即可準備接收碼流，服務器接收到play后，即可打開碼流發(fā)送通道，發(fā)送碼流；這里要注意服務器在給出play響應時，最好帶有RTP-Info字段描述將要發(fā)送碼流的RTP信息，比如第一包RTP的seq和rtptime，客戶端可以根據(jù)此字段進行解復用

1.3.5 TEARDOWN方法

客戶端發(fā)起表示停止媒體占用，并釋放相關資源，其實例如下：

TEARDOWN rtsp://10.45.12.141:554/h264/ch1/main/av_stream/ RTSP/1.0
CSeq: 7
Authorization: Digest username="admin", realm="IP Camera(C7627)", nonce="e3dfa4549e00a1d53c0e9f28c3348e2c", uri="rtsp://10.45.12.141:554/h264/ch1/main/av_stream/", response="0c530cba910c33ea3ef7a554dda8d0b2"
User-Agent: LibVLC/3.0.12 (LIVE555 Streaming Media v2016.11.28)
Session: 391346974

這里teardown一般會停止RTSP會話及視頻傳輸通道，服務器接收到此方法時，釋放相關資源

1.3.6 其他方法

PAUSE方法：錄像回放時會用到，用以暫停流媒體傳輸
SET_PARAMETER/GET_PARAMETER，此方法基本沒啥用，一般用來作為心跳使用，也是用option來維持心跳

1.4 RTSP推流方式說明

有關RTSP推流方式，當前用到的越來越少，在媒體分發(fā)領域有用到，這里做一個簡單的介紹。
RTSP推流流程如下：
流媒體協(xié)議之RTSP詳解

抓包實例如下：

OPTIONS rtsp://10.45.12.141:554/live/0001 RTSP/1.0
CSeq: 1
User-Agent: znv
 
RTSP/1.0 200 OK
Server: EasyDarwin/7.3 
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD
 
ANNOUNCE rtsp://10.45.12.141:554/live/0001 RTSP/1.0
Content-Type: application/sdp
CSeq: 2
User-Agent: znv
Content-Length: 325
 
v=0
o=- 0 0 IN IP4 127.0.0.1
s=Media Server
c=IN IP4 192.168.1.108
t=0 0
a=tool:libavformat 57.71.100
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; sprop-parameter-sets=Z2QAHqw0ygsBJ/wFuCgoKgAAB9AAAYah0MALFAALE9d5caGAFigAFieu8uFA,aO48MA==; profile-level-id=64001E
a=control:streamid=0
RTSP/1.0 200 OK
Server: EasyDarwin/7.3 (Build/17.0325; Platform/Win32; Release/EasyDarwin; State/Development; )
Cseq: 2
 
SETUP rtsp://10.45.12.141:554/live/0001/trackid=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;mode=record
CSeq: 3
User-Agent: znv
 
RTSP/1.0 200 OK
Server: EasyDarwin/7.3 
Cseq: 3
Cache-Control: no-cache
Session: 132169028622239
Date: Tue, 13 Nov 2018 02:49:48 GMT
Expires: Tue, 13 Nov 2018 02:49:48 GMT
Transport: RTP/AVP/TCP;unicast;mode=record;interleaved=0-1
 
RECORD rtsp://10.45.12.141:554/live/0001 RTSP/1.0
Range: npt=0.000-
CSeq: 4
User-Agent:znv
Session: 132169028622239
 
RTSP/1.0 200 OK
Server: EasyDarwin/7.3 
Cseq: 4
Session: 132169028622239
RTP-Info: url=rtsp://192.168.1.108:554/live.sdp/live.sdp

RTSP推流，一般作為流媒體代理，應用CDN等場景，推流由客戶端發(fā)起，視頻由客戶端推送給服務器端，因此流媒體描述需要由客戶端通知到服務器，通過ANNOUNCE方法完成，其SDP描述與DESCRIBE一致，傳輸開始時，由客戶端發(fā)送RECORD方法，然后由客戶端推送rtp流到服務器。

有關RTP/RTCP詳細描述可參照：
H264碼流RTP封裝方式詳解
H265碼流RTP封裝方式詳解
RTP/RTCP協(xié)議文章來源地址http://www.zghlxwxcb.cn/news/detail-454509.html

到了這里，關于流媒體協(xié)議之RTSP詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！

本文來自互聯(lián)網(wǎng)用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如若轉載，請注明出處：如若內(nèi)容造成侵權/違法違規(guī)/事實不符，請點擊違法舉報進行投訴反饋，一經(jīng)查實，立即刪除！

分享到：

領支付寶紅包贊助服務器費用

ZLMediaKit流媒體服務器 RTSP推流時候的堆棧
先直接看圖這是ffmpeg向流媒體服務器推流時候的堆棧引入C++ 11之后? 堆棧會顯得特別繁復冗余看起來也沒有以前沒有C++11之前那樣簡單明了? ?太復雜了標記下??很多函數(shù)名字被我改了因為原來的看起來同名函數(shù)太多了 C++11 和lambada 匿名函數(shù) 讓看堆棧成了地獄模式?
2023年04月20日
瀏覽(29)
基于OpenCV設計的流媒體播放器(RTSP、RTMP)
隨著互聯(lián)網(wǎng)的普及和發(fā)展，流媒體技術已成為日常生活中不可或缺的一部分。流媒體播放器作為流媒體技術的重要組成部分，其性能和功能直接影響到用戶的觀影體驗。本文介紹使用OpenCV和Qt設計一款流媒體播放器，專門用于播放直播視頻流，例如RTSP、RTMP。該播放器只播放實
2024年02月03日
瀏覽(39)
RTSP向ZLM流媒體服務器的推流和拉流鑒權
本篇博客的測試環(huán)境： Windows 10 + Qt 5.12.2 MSVC。由于項目中使用了RTSP協(xié)議，為了防止別人知道我們的流地址隨便就能播放觀看我們的視頻，所以就使用鑒權篩掉一些不合適的請求。在鑒權之前呢，需要準備一下： ZLM流媒體服務器，是從ZLMediaKit中server中編譯出來的，MediaServ
2024年02月03日
瀏覽(21)
LiveNVR監(jiān)控流媒體Onvif/RTSP功能-服務接收RTSP推流RTSPServer可以拉轉配置到通道中視頻直播
目前不是所有的直播推流設備都支持RTSP取流，有的只能輸出直播流，有的只能支持RTSP的推流。那么，項目中如何把 rtsp推流配置到通道中。示例：rtsp://192.168.2.135:1554/stream_1 192.168.2.135 是部署LiveNVR服務器的IP，您自己用的時候換成自己服務器的IP 1554 是基礎配置配置的RTSP服務
2024年02月01日
瀏覽(29)
從零搭建自己的公網(wǎng)RTSP、RTMP、FLV、HLS、WS-FLV、WS-RTSP流媒體服務器解決方案
環(huán)境準備操作系統(tǒng)：內(nèi)存：2G以上 CPU: 雙核2.0GHz以上下載并安裝SkeyeVSS綜合安防視頻云流媒體服務下載SkeyeVSS 下載地址：http://www.openskeye.cn/download/vss.html?id=c24a0a06-6d38-45a5-8623-a1fa3f406ab1 安裝SkeyeVSS Windows系統(tǒng)安裝雙擊下載的windows平臺SkeyeVSS_Server_Setup_Vx.x.xx_buildxxxxxxxx.exe安裝包
2023年04月17日
瀏覽(27)
LiveNVR監(jiān)控流媒體Onvif/RTSP功能-視頻流水印如何疊加視頻水印疊加動態(tài)圖片疊加視頻流時間示例
監(jiān)控視頻平臺播放視頻監(jiān)控的時候，除了滿足正常視頻播放外，有時還需要方便標記或者防盜用等添加視頻水印。有些視頻在原始攝像頭端就可以添加OSD水印，這種方式最好。但是有些原始視頻沒有水印，但是平臺端播放的時候又希望有水印，下面介紹下LiveNVR Onvif/RTSP流媒體
2024年02月13日
瀏覽(97)
LiveNVR監(jiān)控流媒體Onvif/RTSP功能-概覽負載統(tǒng)計展示取流中、播放中、錄像中點擊柱狀圖快速定位相關會話
實時展示取流中、播放中、錄像中等使用數(shù)目取流中：當前拉流到平臺的實時通道數(shù)目播放中：當前觀看直播和回放的在線人數(shù)之和錄像中：當前正在云端錄像(服務器集中錄像)的通道數(shù)目，開啟錄像是編輯通道配置錄像保留(天）點擊柱狀圖，可以查看對應的會話信息, 包
2024年04月15日
瀏覽(32)
LiveNVR監(jiān)控流媒體Onvif/RTSP功能-支持云端錄像監(jiān)控視頻集中存儲錄像回看錄像計劃配置NVR硬件設備錄像回看
LiveNVR可接入傳統(tǒng)監(jiān)控行業(yè)里面的高清網(wǎng)絡攝像機的RTSP直播流，及 RTMP、HTTP-FLV、M3U8等其它直播流，實現(xiàn)互聯(lián)網(wǎng)直播分發(fā)；可分發(fā)多種格式流，HTTP-FLV/WS-FLV/RTMP/RTSP/WebRTC/HLS。支持GB28181注冊級聯(lián)到第三方國標平臺；同時能實時云端存儲、錄像計劃、檢索、時移回放，也可以查看
2024年04月12日
瀏覽(30)
LiveNVR監(jiān)控流媒體Onvif/RTSP功能-安全控制HTTP接口鑒權開啟禁止游客訪問開啟后401 Unauthorized如何播放調(diào)用接口
如果是內(nèi)網(wǎng)集成，可以把接口鑒權取消勾選保存。公網(wǎng)使用時候，這里建議勾選。僅僅勾選接口鑒權時候，游客還可以訪問視頻廣場頁面，播放視頻，如果需要更安全的控制，勾選上禁止游客訪問調(diào)用接口的時候，或播放視頻流的時候，遇到返回401的狀態(tài)碼，表示沒有權
2024年02月16日
瀏覽(32)
LiveNVR Onvif/RTSP流媒體軟件接入監(jiān)控攝像頭后如何獲取直播流地址進行大屏展示、播放端拉流、網(wǎng)頁播放監(jiān)控視頻等...
LiveNVR的安防監(jiān)控的視頻直播，可以按標準的Onvif/RTSP協(xié)議接入監(jiān)控設備，也可以通過?？怠⒋笕A、天地偉業(yè)等廠家私有SDK接入監(jiān)控，實現(xiàn)web頁面的播放和錄像回放。可以分發(fā)HTTP-FLV、WS-FLV、WebRTC、RTMP、HLS(M3U8)、RTSP等多中視頻流 2.1.1、接口說明 http://192.168.2.135:10800 是示例的i
2024年02月16日
瀏覽(30)

<style id="idjya"></style>

<noscript id="idjya"><dfn id="idjya"></dfn></noscript>

<noscript id="idjya"><cite id="idjya"><input id="idjya"></input></cite></noscript>