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

            導航

            隨筆分類

            隨筆檔案

            最新評論

            久久久久久精品成人免费图片| 久久国产精品成人免费| 久久天天躁狠狠躁夜夜av浪潮| 久久国产福利免费| 亚洲国产精品无码成人片久久| 久久精品国产亚洲AV香蕉| 精品久久久久中文字幕一区| 久久综合视频网站| 91精品国产9l久久久久| 久久精品国产亚洲av瑜伽| 亚洲欧美日韩久久精品第一区| 狠狠色丁香婷婷综合久久来| 欧美成人免费观看久久| 精品国际久久久久999波多野| 久久最新精品国产| 亚洲AV无一区二区三区久久| 99久久伊人精品综合观看| 亚洲国产精品久久久天堂 | 久久综合九色欧美综合狠狠 | 成人久久综合网| 国产欧美久久久精品影院| 国产午夜免费高清久久影院| 一级做a爰片久久毛片毛片| 精品国产一区二区三区久久久狼 | 青青草原综合久久大伊人精品| 久久精品三级视频| 超级碰久久免费公开视频| 久久人人爽人人爽人人AV东京热| 久久久99精品成人片中文字幕| 精品久久久久中文字幕日本| 久久久久国产精品嫩草影院| 亚州日韩精品专区久久久| 国产精品一区二区久久精品无码| 国产精品视频久久久| 久久精品国产99久久无毒不卡| 久久天天婷婷五月俺也去| 久久久久久国产a免费观看不卡| 久久99免费视频| 99久久精品国产一区二区蜜芽| 日韩精品国产自在久久现线拍| 午夜不卡888久久|