99久久久久,熟女乱伦AV一区二区三区,91探花中文字幕 ,亚洲欧在线视频

  • 
    
  • <ul id="wqk02"></ul>
    <blockquote id="wqk02"><tfoot id="wqk02"></tfoot></blockquote>
    
    
    • <del id="wqk02"><tfoot id="wqk02"></tfoot></del>

      深圳市凱茉銳電子科技有限公司深圳市凱茉銳電子科技有限公司

      新聞中心

      News

      HTTP協(xié)議/RTSP協(xié)議/RTMP協(xié)議的區(qū)別

      來源:深圳市凱茉銳電子科技有限公司2020-06-20

      RTSP、 RTMP、HTTP的共同點(diǎn)、區(qū)別


      共同點(diǎn):


      1:RTSP RTMP HTTP都是在應(yīng)用應(yīng)用層。


      2:理論上RTSP RTMPHTTP都可以做直播和點(diǎn)播,但一般做直播用RTSP RTMP,做點(diǎn)播用HTTP。做視頻會(huì)議的時(shí)候原來用SIP協(xié)議,現(xiàn)在基本上被RTMP協(xié)議取代了。



      區(qū)別:


      1:HTTP: 即超文本傳送協(xié)議(ftp即文件傳輸協(xié)議)。


      HTTP:(Real Time Streaming Protocol),實(shí)時(shí)流傳輸協(xié)議。


      HTTP全稱Routing Table Maintenance Protocol(路由選擇表維護(hù)協(xié)議)。


      2:HTTP將所有的數(shù)據(jù)作為文件做處理。http協(xié)議不是流媒體協(xié)議。


      RTMP和RTSP協(xié)議是流媒體協(xié)議。


      3:RTMP協(xié)議是Adobe的私有協(xié)議,未完全公開,RTSP協(xié)議和HTTP協(xié)議是共有協(xié)議,并有專門機(jī)構(gòu)做維護(hù)。


      4:RTMP協(xié)議一般傳輸?shù)氖莊lv,f4v格式流,RTSP協(xié)議一般傳輸?shù)氖莟s,mp4格式的流。HTTP沒有特定的流。


      5:RTSP傳輸一般需要2-3個(gè)通道,命令和數(shù)據(jù)通道分離,HTTP和RTMP一般在TCP一個(gè)通道上傳輸命令和數(shù)據(jù)。


      RTSP、RTCP、RTP區(qū)別


      1:RTSP實(shí)時(shí)流協(xié)議

      作為一個(gè)應(yīng)用層協(xié)議,RTSP提供了一個(gè)可供擴(kuò)展的框架,它的意義在于使得實(shí)時(shí)流媒體數(shù)據(jù)的受控和點(diǎn)播變得可能??偟恼f來,RTSP是一個(gè)流媒體表示 協(xié)議,主要用來控制具有實(shí)時(shí)特性的數(shù)據(jù)發(fā)送,但它本身并不傳輸數(shù)據(jù),而是必須依賴于下層傳輸協(xié)議所提供的某些服務(wù)。RTSP可以對(duì)流媒體提供諸如播放、暫 停、快進(jìn)等操作,它負(fù)責(zé)定義具體的控制消息、操作方法、狀態(tài)碼等,此外還描述了與RTP間的交互操作(RFC2326)。


      2:RTCP控制協(xié)議

      RTCP控制協(xié)議需要與RTP數(shù)據(jù)協(xié)議一起配合使用,當(dāng)應(yīng)用程序啟動(dòng)一個(gè)RTP會(huì)話時(shí)將同時(shí)占用兩個(gè)端口,分別供RTP和RTCP使用。RTP本身并 不能為按序傳輸數(shù)據(jù)包提供可靠的保證,也不提供流量控制和擁塞控制,這些都由RTCP來負(fù)責(zé)完成。通常RTCP會(huì)采用與RTP相同的分發(fā)機(jī)制,向會(huì)話中的 所有成員周期性地發(fā)送控制信息,應(yīng)用程序通過接收這些數(shù)據(jù),從中獲取會(huì)話參與者的相關(guān)資料,以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息,從而能夠?qū)Ψ?wù)質(zhì)量進(jìn) 行控制或者對(duì)網(wǎng)絡(luò)狀況進(jìn)行診斷。


      RTCP協(xié)議的功能是通過不同的RTCP數(shù)據(jù)報(bào)來實(shí)現(xiàn)的,主要有如下幾種類型:


      SR:發(fā)送端報(bào)告,所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報(bào)的應(yīng)用程序或者終端,發(fā)送端同時(shí)也可以是接收端。(SERVER定時(shí)間發(fā)送給CLIENT)。

      RR:接收端報(bào)告,所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報(bào)的應(yīng)用程序或者終端。(SERVER接收CLIENT端發(fā)送過來的響應(yīng))。

      SDES:源描述,主要功能是作為會(huì)話成員有關(guān)標(biāo)識(shí)信息的載體,如用戶名、郵件地址、電話號(hào)碼等,此外還具有向會(huì)話成員傳達(dá)會(huì)話控制信息的功能。

      BYE:通知離開,主要功能是指示某一個(gè)或者幾個(gè)源不再有效,即通知會(huì)話中的其他成員自己將退出會(huì)話。

      APP:由應(yīng)用程序自己定義,解決了RTCP的擴(kuò)展性問題,并且為協(xié)議的實(shí)現(xiàn)者提供了很大的靈活性。


      3:RTP數(shù)據(jù)協(xié)議

      RTP數(shù)據(jù)協(xié)議負(fù)責(zé)對(duì)流媒體數(shù)據(jù)進(jìn)行封包并實(shí)現(xiàn)媒體流的實(shí)時(shí)傳輸,每一個(gè)RTP數(shù)據(jù)報(bào)都由頭部(Header)和負(fù)載(Payload)兩個(gè)部分組成,其中頭部前12個(gè)字節(jié)的含義是固定的,而負(fù)載則可以是音頻或者視頻數(shù)據(jù)。

      RTP用到的地方就是 PLAY ,服務(wù)器往客戶端傳輸數(shù)據(jù)用UDP協(xié)議,RTP是在傳輸數(shù)據(jù)的前面加了個(gè)12字節(jié)的頭(描述信息)。

      RTP載荷封裝設(shè)計(jì)本文的網(wǎng)絡(luò)傳輸是基于IP協(xié)議,所以最大傳輸單元(MTU)最大為1500字節(jié),在使用IP/UDP/RTP的協(xié)議層次結(jié)構(gòu)的時(shí)候,這 其中包括至少20字節(jié)的IP頭,8字節(jié)的UDP頭,以及12字節(jié)的RTP頭。這樣,頭信息至少要占用40個(gè)字節(jié),那么RTP載荷的最大尺寸為1460字 節(jié)。以H264 為例,如果一幀數(shù)據(jù)大于1460,則需要分片打包,然后到接收端再拆包,組合成一幀數(shù)據(jù),進(jìn)行解碼播放。


      直播應(yīng)用中,RTMP和HLS基本上可以覆蓋所有客戶端觀看,

      HLS主要是延時(shí)比較大,RTMP主要優(yōu)勢(shì)在于延時(shí)低。



      一、應(yīng)用場(chǎng)景


      低延時(shí)應(yīng)用場(chǎng)景包括:

       .  互動(dòng)式直播:譬如美女主播,游戲直播等等

          各種主播,流媒體分發(fā)給用戶觀看。用戶可以文字聊天和主播互動(dòng)。

       .  視頻會(huì)議:我們要是有出差在外地,就用視頻會(huì)議開內(nèi)部會(huì)議。

          其實(shí)會(huì)議1秒延時(shí)無所謂,因?yàn)槿思抑v完話后,其他人需要思考,

          思考的延時(shí)也會(huì)在1秒左右。當(dāng)然如果用視頻會(huì)議吵架就不行。

       .  其他:監(jiān)控,直播也有些地方需要對(duì)延遲有要求,

          互聯(lián)網(wǎng)上RTMP協(xié)議的延遲基本上能夠滿足要求。


      二、RTMP和延時(shí)

      1. RTMP的特點(diǎn)如下:

      1) Adobe支持得很好:

        RTMP實(shí)際上是現(xiàn)在編碼器輸出的工業(yè)標(biāo)準(zhǔn)協(xié)議,基本上所有的編碼器(攝像頭之類)都支持RTMP輸出。

        原因在于PC市場(chǎng)巨大,PC主要是Windows,Windows的瀏覽器基本上都支持flash,

        Flash又支持RTMP支持得非常好。

      2) 適合長(zhǎng)時(shí)間播放:

        因?yàn)镽TMP支持的很完善,所以能做到flash播放RTMP流長(zhǎng)時(shí)間不斷流,

        當(dāng)時(shí)測(cè)試是100萬秒,即10天多可以連續(xù)播放。

        對(duì)于商用流媒體應(yīng)用,客戶端的穩(wěn)定性當(dāng)然也是必須的,否則最終用戶看不了還怎么玩?

        我就知道有個(gè)教育客戶,最初使用播放器播放http流,需要播放不同的文件,結(jié)果就總出問題,

        如果換成服務(wù)器端將不同的文件轉(zhuǎn)換成RTMP流,客戶端就可以一直播放;

        該客戶走RTMP方案后,經(jīng)過CDN分發(fā),沒聽說客戶端出問題了。

      3)延遲較低:

        比起YY的那種UDP私有協(xié)議,RTMP算延遲大的(延遲在1-3秒),

        比起HTTP流的延時(shí)(一般在10秒以上)RTMP算低延時(shí)。

        一般的直播應(yīng)用,只要不是電話類對(duì)話的那種要求,RTMP延遲是可以接受的。

        在一般的視頻會(huì)議應(yīng)用中,RTMP延時(shí)也能接受,原因是別人在說話的時(shí)候我們一般在聽,

        實(shí)際上1秒延時(shí)沒有關(guān)系,我們也要思考(話說有些人的CPU處理速度還沒有這么快)。

      4) 有累積延遲:

        技術(shù)一定要知道弱點(diǎn),RTMP有個(gè)弱點(diǎn)就是累積誤差,原因是RTMP基于TCP不會(huì)丟包。

        所以當(dāng)網(wǎng)絡(luò)狀態(tài)差時(shí),服務(wù)器會(huì)將包緩存起來,導(dǎo)致累積的延遲;

        待網(wǎng)絡(luò)狀況好了,就一起發(fā)給客戶端。

        這個(gè)的對(duì)策就是,當(dāng)客戶端的緩沖區(qū)很大,就斷開重連。


      2. HLS低延時(shí)

      主要有人老是問這個(gè)問題,如何降低HLS延遲。

      HLS解決延時(shí),就像是爬到楓樹上去捉魚,奇怪的是還有人喊,看那,有魚。

      你說是怎么回事?

      我只能說你在參與謙哥的魔術(shù)表演,錯(cuò)覺罷了。

      如果你真的確信有,請(qǐng)用實(shí)際測(cè)量的圖片來展示出來,參考下面延遲的測(cè)量。


      3. RTMP延遲的測(cè)量

      如何測(cè)量延時(shí),是個(gè)很難的問題,

      不過有個(gè)行之有效的方法,就是用手機(jī)的秒表,可以比較精確的對(duì)比延時(shí)。

      經(jīng)過測(cè)量發(fā)現(xiàn),在網(wǎng)絡(luò)狀況良好時(shí):

      RTMP延時(shí)可以做到0.8秒左右。

       . 多級(jí)邊緣節(jié)點(diǎn)不會(huì)影響延遲(和SRS同源的某CDN的邊緣服務(wù)器可以做到)

       . Nginx-Rtmp延遲有點(diǎn)大,估計(jì)是緩存的處理,多進(jìn)程通信導(dǎo)致?

       . GOP是個(gè)硬指標(biāo),不過SRS可以關(guān)閉GOP的cache來避免這個(gè)影響.

       . 服務(wù)器性能太低,也會(huì)導(dǎo)致延遲變大,服務(wù)器來不及發(fā)送數(shù)據(jù)。

       . 客戶端的緩沖區(qū)長(zhǎng)度也影響延遲。

         譬如flash客戶端的NetStream.bufferTime設(shè)置為10秒,那么延遲至少10秒以上。

      4. GOP-Cache

      什么是GOP?就是視頻流中兩個(gè)I幀的時(shí)間距離。

      GOP有什么影響?

      Flash(解碼器)只有拿到GOP才能開始解碼播放。

      也就是說,服務(wù)器一般先給一個(gè)I幀給Flash。

      可惜問題來了,假設(shè)GOP是10秒,也就是每隔10秒才有關(guān)鍵幀,

      如果用戶在第5秒時(shí)開始播放,會(huì)怎么樣?

      第一種方案:等待下一個(gè)I幀,

      也就是說,再等5秒才開始給客戶端數(shù)據(jù)。

      這樣延遲就很低了,總是實(shí)時(shí)的流。

      問題是:等待的這5秒,會(huì)黑屏,現(xiàn)象就是播放器卡在那里,什么也沒有,

      有些用戶可能以為死掉了,就會(huì)刷新頁面。

      總之,某些客戶會(huì)認(rèn)為等待關(guān)鍵幀是個(gè)不可饒恕的錯(cuò)誤,延時(shí)有什么關(guān)系?

      我就希望能快速啟動(dòng)和播放視頻,最好打開就能放!

      第二種方案:馬上開始放,

      放什么呢?

      你肯定知道了,放前一個(gè)I幀。

      也就是說,服務(wù)器需要總是cache一個(gè)gop,

      這樣客戶端上來就從前一個(gè)I幀開始播放,就可以快速啟動(dòng)了。

      問題是:延遲自然就大了。

      有沒有好的方案?

      有!至少有兩種:
      編碼器調(diào)低GOP,譬如0.5秒一個(gè)GOP,這樣延遲也很低,也不用等待。
      壞處是編碼器壓縮率會(huì)降低,圖像質(zhì)量沒有那么好。

      5. 累積延遲
      除了GOP-Cache,還有一個(gè)有關(guān)系,就是累積延遲。
      服務(wù)器可以配置直播隊(duì)列的長(zhǎng)度,服務(wù)器會(huì)將數(shù)據(jù)放在直播隊(duì)列中,
      如果超過這個(gè)長(zhǎng)度就清空到最后一個(gè)I幀:

      當(dāng)然這個(gè)不能配置太小,
      譬如GOP是1秒,queue_length是1秒,這樣會(huì)導(dǎo)致有1秒數(shù)據(jù)就清空,會(huì)導(dǎo)致跳躍。

      有更好的方法?有的。
      延遲基本上就等于客戶端的緩沖區(qū)長(zhǎng)度,因?yàn)檠舆t大多由于網(wǎng)絡(luò)帶寬低,
      服務(wù)器緩存后一起發(fā)給客戶端,現(xiàn)象就是客戶端的緩沖區(qū)變大了,
      譬如NetStream.BufferLength=5秒,那么說明緩沖區(qū)中至少有5秒數(shù)據(jù)。


      處理累積延遲的最好方法,是客戶端檢測(cè)到緩沖區(qū)有很多數(shù)據(jù)了,如果可以的話,就重連服務(wù)器。
      當(dāng)然如果網(wǎng)絡(luò)一直不好,那就沒有辦法了。

      凱茉銳4K模組攝像機(jī)-CM-8420-SHE  20倍光學(xué)變焦,16倍數(shù)字變焦 829萬逐行掃描1/1.8”CMOS 最大分辨率可達(dá)3840X2160,可以人臉偵測(cè)、

      區(qū)域入侵偵測(cè)、越界偵測(cè)、進(jìn)入?yún)^(qū)域偵測(cè)、離開區(qū)域偵測(cè)、徘徊偵測(cè)、人員聚集偵測(cè)、物品遺留偵測(cè)、物品拿取偵測(cè)、音頻異常偵測(cè)、移動(dòng)偵測(cè)

      更多深圳凱茉銳電子科技產(chǎn)品情況,請(qǐng)?jiān)L問本公司產(chǎn)品網(wǎng)址:http:///


      相關(guān)資訊

      專業(yè)工程師

      24小時(shí)在線服務(wù)提交需求快速為您定制解決方案

      13798538021