• <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>

            RTMP協議 - Chunk

            KEY : Message / Chunk / Stream

            Rtmp中,一個Message通常是分割成多個Chunk進行傳輸的.每個Chunk通常包含有1~12個字節的頭部(該部分與完整的協議不是十分符合).

            因為Rtmp是基于TCP協議的,所以在Rtmp傳輸過程中, Chunk頭部會根據實際情況使用簡化的頭部(12字節的頭部是完整的頭部,8/4/1字節的頭部是根據實際情況簡化的).

            . Chunk頭部的簡化規則

                  說明:以上的"------"為6bit的ChunkId

            1 . 00------頭部

            在傳輸開始,的第一個Chunk頭部通常使用(00------)格式,包含完整的頭部信息,依次包含:時間戳,Message長度,Message類型1B,StreamId1B. 這些信息在程序中是需要保留的.以便后面簡化的頭部,可根據該頭部完善信息.

            2 . 01------頭部

            當發送多個相關的Message時,Chunk的頭部通常使用(01------)開始, 后面追加StreamId,Message類型和Message長度三個字段,這些字段與前一個Chunk的信息保持一致.例如,當交錯的發送Video/Audio Message,它們屬于同一個StreamId,但其他字段都發生了變化.

            3 . 10------頭部

            當由一個Message拆分成的連續的兩個Chunk的時間戳發生了變化時(尤其是Video/Audio Message),例如,一個Video Message中前一個Chunk和下一個Chunk的時間戳或時間戳增量不一致,后面的Chunk頭部會以(10------)開始, 再追加一個3字節的時間戳字段即可.

            4 . 11------頭部

            當一個Message過長,需要由多個連續的Chunk進行發送時,Chunk的頭部通常會以(11------)開始, 沒有其他附加字段,所有相關字段與前一個Chunk保持一致.

             

            . 關于ChunkId和StreamId


            1 . StreamId的使命

            一個StreamId通常用以完成某些特定的工作. 如使用Id為0的Stream來完成客戶端和服務器的連接和控制,用Id為1的Stream來完成Stream的控制和播放等工作.

            2 . ChunkId的使命

            一個ChunkId通常會完成某個特定的工作. 比如說系統保留的ChunkId為2的就只是用于完成對Stream的控制. 在該通道上,服務器和客戶端可以對Stream的具體屬性進行設置和交互.如創建一個Stream,告知Stream結束,設定Stream的帶寬,設定Chunk大小,終止Message等.這里對Stream的控制不是針對某個Stream的,而是全局的.

            再比如,使用ChunkId8對播放進行控制.客戶端發送"play"命令,服務器也會通過ChunkId8這個通道告知客戶端播放的狀態,如告知客戶端播放開始,播放完成等信息.服務器使用ChunkId5進行媒體數據的傳送,如果客戶端需要針對這些數據對服務器應答,也要使用該通道.

            3 . ChunkId和StreamId的關系

            ChunkId和StreamId的關系目前并不明了,但通常情況下某一個ChunkId會在固定的StreamId中完成相應的工作. 比如ChunkId2對Stream的相關屬性進行控制,這些控制的消息必須在StreamId0中完成.也就是說ChunkId2和StreamId0指定了服務器和客戶端對Stream控制的以個對話通道.

            posted on 2012-10-31 17:09 Apollo Fang 閱讀(761) 評論(0)  編輯 收藏 引用 所屬分類: Protocol

            導航

            隨筆分類

            隨筆檔案

            最新評論

            亚洲v国产v天堂a无码久久| 久久久久亚洲AV片无码下载蜜桃 | 亚洲香蕉网久久综合影视| 国产精品欧美久久久久天天影视| 四虎影视久久久免费| 国产激情久久久久影院老熟女| 久久99精品久久久久久| 久久精品无码一区二区三区免费| 国内精品久久久久久久影视麻豆 | 午夜肉伦伦影院久久精品免费看国产一区二区三区 | 青草影院天堂男人久久| 久久久久亚洲精品天堂久久久久久| 久久男人AV资源网站| 国产成人无码精品久久久性色| 亚洲乱亚洲乱淫久久| 久久精品国产精品亚洲| 午夜精品久久久久久中宇| 久久毛片免费看一区二区三区| 99久久久国产精品免费无卡顿| 免费精品久久久久久中文字幕| 色欲久久久天天天综合网精品| 色综合合久久天天综合绕视看| 精品综合久久久久久98| 欧美伊香蕉久久综合类网站| 久久久无码精品亚洲日韩京东传媒| 国产成人精品久久亚洲| 国产人久久人人人人爽| 亚洲国产另类久久久精品| 久久精品无码一区二区三区免费| 国产高清国内精品福利99久久| 久久精品国产亚洲AV无码娇色| 欧洲性大片xxxxx久久久| 亚洲国产天堂久久综合网站| 麻豆精品久久精品色综合| 色婷婷综合久久久久中文| 国产免费久久精品99re丫y| 久久久久久久波多野结衣高潮| 无码精品久久久天天影视| 久久久久久久女国产乱让韩| 亚洲日本va午夜中文字幕久久| 一本一道久久综合狠狠老 |