• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            牽著老婆滿街逛

            嚴(yán)以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            RTMP 協(xié)議學(xué)習(xí)總結(jié)

            轉(zhuǎn)載自:http://blog.chinaunix.net/uid-17102734-id-3986995.html

            RTMP協(xié)議是一個(gè)互聯(lián)網(wǎng)TCP/IP五層體系結(jié)構(gòu)中應(yīng)用層的協(xié)議。RTMP協(xié)議中基本的數(shù)據(jù)單元稱為消息(Message)。當(dāng)RTMP協(xié)議在互聯(lián)網(wǎng)中傳輸數(shù)據(jù)的時(shí)候,消息會(huì)被拆分成更小的單元,稱為消息塊(Chunk)。

            1 消息

            消息是RTMP協(xié)議中基本的數(shù)據(jù)單元。不同種類的消息包含不同的Message Type ID,代表不同的功能。RTMP協(xié)議中一共規(guī)定了十多種消息類型,分別發(fā)揮著不同的作用。例如,Message Type ID在1-7的消息用于協(xié)議控制,這些消息一般是RTMP協(xié)議自身管理要使用的消息,用戶一般情況下無需操作其中的數(shù)據(jù)。Message Type ID為8,9的消息分別用于傳輸音頻和視頻數(shù)據(jù)。Message Type ID為15-20的消息用于發(fā)送AMF編碼的命令,負(fù)責(zé)用戶與服務(wù)器之間的交互,比如播放,暫停等等。消息首部(Message Header)有四部分組成:標(biāo)志消息類型的Message Type ID,標(biāo)志消息長(zhǎng)度的Payload Length,標(biāo)識(shí)時(shí)間戳的Timestamp,標(biāo)識(shí)消息所屬媒體流的Stream ID。消息的報(bào)文結(jié)構(gòu)如下圖所示。

            2 消息塊
            在網(wǎng)絡(luò)上傳輸數(shù)據(jù)時(shí),消息需要被拆分成較小的數(shù)據(jù)塊,才適合在相應(yīng)的網(wǎng)絡(luò)環(huán)境上傳輸。RTMP協(xié)議中規(guī)定,消息在網(wǎng)絡(luò)上傳輸時(shí)被拆分成消息塊(Chunk)。消息塊首部(Chunk Header)有三部分組成:用于標(biāo)識(shí)本塊的Chunk Basic Header,用于標(biāo)識(shí)本塊負(fù)載所屬消息的Chunk Message Header,以及當(dāng)時(shí)間戳溢出時(shí)才出現(xiàn)的Extended Timestamp。消息塊的報(bào)文結(jié)構(gòu)如下圖所示。



            3 消息分塊

            在消息被分割成幾個(gè)消息塊的過程中,消息負(fù)載部分(Message Body)被分割成大小固定的數(shù)據(jù)塊(默認(rèn)是128字節(jié),最后一個(gè)數(shù)據(jù)塊可以小于該固定長(zhǎng)度),并在其首部加上消息塊首部(Chunk Header),就組成了相應(yīng)的消息塊。消息分塊過程如下圖所示,一個(gè)大小為307字節(jié)的消息被分割成128字節(jié)的消息塊(除了最后一個(gè))。

            RTMP傳輸媒體數(shù)據(jù)的過程中,發(fā)送端首先把媒體數(shù)據(jù)封裝成消息,然后把消息分割成消息塊,最后將分割后的消息塊通過TCP協(xié)議發(fā)送出去。接收端在通過TCP協(xié)議收到數(shù)據(jù)后,首先把消息塊重新組合成消息,然后通過對(duì)消息進(jìn)行解封裝處理就可以恢復(fù)出媒體數(shù)據(jù)。

            2.1 Chunk Basic Header [1-3字節(jié)]
            HeaderType+ChannelID組成,其中ChannelID的大小決定了整個(gè)Chunk Basic Header的大小
            2.1.1  

            ID

            和消息塊的類型,消息塊類型決定了消息包頭的編碼格式,長(zhǎng)度完全

            HeaderType(fmt):決定了Chunk Message Header的編碼方式和大小,在第一個(gè)字節(jié)的高兩位
            Bits Chunk Message Header Length
            00   12 bytes
            01   8 bytes
            10   4 bytes
            11   1 byte
            2.1.2 ChannelID:
            ChannelID 用途
            02              Ping 和ByteRead通道
            03              Invoke通道 我們的connect() publish()和自字寫的NetConnection.Call() 數(shù)據(jù)都是在這個(gè)通道的
            04              Audio和Vidio通道
            05 06 07     服務(wù)器保留,經(jīng)觀察FMS2用這些Channel也用來發(fā)送音頻或視頻數(shù)據(jù)
            2.2 Chunk Message Header
            以最大fmt =00 length(Chunk Message Header) == 12 為例
            Chunk Message Header的結(jié)構(gòu)是:timestamp,message_length,message_type,msg_stream_id
            其中message_type是一個(gè)枚舉變量:
            type為1,2,3,5,6的時(shí)候是協(xié)議控制消息
            type為4的時(shí)候表示 User Control Messages [Event_type + Event_Data] Event_type有Stream Begin
            Stream End...
            type為8,音頻數(shù)據(jù)
            type為9,視頻數(shù)據(jù)
            type為18 元數(shù)據(jù)消息[AMF0]
            type為20 命令消息 Command Message(RPC Message)
            These messages are sent to perform some operations like connect, createStream, publish, play, pause on the peer.
            命令消息主要分成兩種NetConnection和NetStream。
            connect,call,close,createStream命令可以在NetConnection中發(fā)送。
            coonect(name,TranscationID,Command Object<name-value> pair)
            play,publish,seek,pause等命令可以在NetStream中發(fā)送。
            2.3 Ext Time Stamp
            2.4數(shù)據(jù)
            RTMP流媒體播放過程
            RTMP協(xié)議規(guī)定,播放一個(gè)流媒體有兩個(gè)前提步驟:第一步,建立一個(gè)網(wǎng)絡(luò)連接(NetConnection);第二步,建立一個(gè)網(wǎng)絡(luò)流(NetStream)。其中,網(wǎng)絡(luò)連接代表服務(wù)器端應(yīng)用程序和客戶端之間基礎(chǔ)的連通關(guān)系。網(wǎng)絡(luò)流代表了發(fā)送多媒體數(shù)據(jù)的通道。服務(wù)器和客戶端之間只能建立一個(gè)網(wǎng)絡(luò)連接,但是基于該連接可以創(chuàng)建很多網(wǎng)絡(luò)流。

            播放一個(gè)RTMP協(xié)議的流媒體需要經(jīng)過以下幾個(gè)步驟:握手,建立連接,建立流,播放。RTMP連接都是以握手作為開始的。建立連接階段用于建立客戶端與服務(wù)器之間的“網(wǎng)絡(luò)連接”;建立流階段用于建立客戶端與服務(wù)器之間的“網(wǎng)絡(luò)流”;播放階段用于傳輸視音頻數(shù)據(jù)。
            參考:http://blog.csdn.net/leixiaohua1020/article/category/1362941
            RTMP協(xié)議中文版
            http://wenku.baidu.com/link?url=Lc4gR-FLeCkHCMM1NL-FcAUtKFTRaFn0tcdoqcid6Dtvu_Q2wlSQ-GMY711Ptc_TdeG2KU0E9e-aHddFVZJSMwt2CujY2p7AdHg8Vr15HuG
            RTMP協(xié)議英文版
            http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_1.0.pdf
            開源項(xiàng)目 RTMP Dump
            http://rtmpdump.mplayerhq.hu/

            posted on 2014-05-31 20:13 楊粼波 閱讀(1617) 評(píng)論(0)  編輯 收藏 引用


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            91久久九九无码成人网站| 国产Av激情久久无码天堂| 久久综合狠狠综合久久激情 | 亚洲日韩中文无码久久| 久久综合亚洲色HEZYO社区| 性做久久久久久久久| 青青热久久国产久精品 | 性高湖久久久久久久久| 手机看片久久高清国产日韩| 久久久久无码专区亚洲av| 久久久久亚洲精品中文字幕 | 91精品国产91久久久久久| 久久香蕉一级毛片| 国产精品免费久久久久影院| 99久久精品免费观看国产| 亚洲一区二区三区日本久久九| 中文字幕亚洲综合久久2| 久久久久亚洲av毛片大| 亚洲欧洲久久久精品| 91麻豆国产精品91久久久| 久久久久亚洲精品天堂| AV无码久久久久不卡网站下载| 色综合久久中文综合网| 久久久综合香蕉尹人综合网| 香蕉aa三级久久毛片| 亚洲欧美日韩中文久久| 久久国产亚洲精品麻豆| 久久嫩草影院免费看夜色| 一本久久a久久精品vr综合| 丁香五月网久久综合| 久久久精品国产亚洲成人满18免费网站 | 99久久亚洲综合精品成人| 久久青青国产| 久久久久99精品成人片欧美| 色综合久久最新中文字幕| 伊人久久大香线蕉综合5g| 国产精品久久久久jk制服| 久久久久亚洲av毛片大| AV狠狠色丁香婷婷综合久久| 久久亚洲精品无码观看不卡| 色欲av伊人久久大香线蕉影院|