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

            一路走來,只有C++和香煙最實在!

            Just Dive Into!

            C++博客 首頁 新隨筆 聯系 聚合 管理
              11 Posts :: 0 Stories :: 29 Comments :: 0 Trackbacks

            Chunk Msg Header

            Chunk Msg Header的長度是可變的,Chunk Msg Header可變的原因是為了壓縮傳輸的字節數,把一些相同類型的chunkhead去掉一些字節,換句話說就是四種類型的包頭都可以通過一定的規則還原成11個字節,這個壓縮和還原在RTMP協議中稱之為復用/解復用。

            那我們以11個字節的完整包頭來解釋Chunk Msg Header,如圖所示

            ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

            +                    timestamp          +            message length         + message type  id +                message stream id     +

            ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

            Timestamp3bytes

            對于type 0chunk,絕對時間戳在這里表示,如果時間戳值大于等于0xffffff16777215),該值必須是0xffffff,且時間戳擴展字段必須發送,其他情況沒有要求。

            message length:3bytes

            Message的長度,注意這里的長度并不是跟隨chunk head其后的chunk data(Payload)的長度,而是前文提到的一條信令或者一幀視頻數據或音頻數據的長度。前文提到過信令或者媒體數據都稱之為Message,一條Message可以分為一條或者多條chunk。

            message type  id:1byte

            Message的類型ID,具體的值將在后文專門來討論。

            message stream id:4bytes

            message stream id的字節序是小端序,這個字段是為了解復用而設計的,RTMP文檔上說的相當的模糊,

             

            message stream ID可以使任意值,不同的消息流復用成相同的chunk stream,基于它們的ID能夠解復用。于chunk stream 是相關的,這個字段是一個不透明的值沒有整明白什么意思,我的理解就是用來標識和服務器連接的flash端的序號。

            長度是7 byteschunk head,該類型不包含stream ID,該chunkstreamID和前一個chunkstream ID是相同的,變長的消息,例如視頻流格式,在第一個新的chunk以后使用這種類型,注意其中時間戳部分是相對時間,為何上一個絕對時間之間的差值 如圖所示:

            ++++++++++++++++++++++++++++++++++++++++++++++++++++++

            +         timestamp    delta      +            message length         + message type  id +             

            ++++++++++++++++++++++++++++++++++++++++++++++++++++++

                    3 bytes的chunk head,該類型既不包含stream ID 也不包含消息長度,這種類型用于stream ID和前一個chunk相同,且有固定長度的信息,例如音頻流格式,在第一個新的chunk以后使用該類型。如圖所示:

                                       ++++++++++++++++++++

                                       +         timestamp    delta      +         

                                       ++++++++++++++++++++


                    0 bytes的chunk head,這種類型的chunk從前一個chunk得到值信息,當一個單個消息拆成多個chunk時,這些chunk除了第一個以外,其他的都應該使用這種類型,

            chunk的長度:

            chunk的長度初始長度固定為128個字節,但是這個值并不是不可變的,在客戶端和服務端建立連接以后,客戶端和服務端都可以通過發送信令的方式來通知對端修改chunk的長度,理論上來說可以修改chunk的最長長度為65536。這里chunk的長度是指chunk的數據部分的長度,即chunk data(payload)的長度,如果一條Message的數據長度超過了chunk的長度,就必須把Message分割成多條chunk,即如果一條視頻類型Message長度為2000個byte,chunk長度為1500,則該Message將會分割成兩條chunk,第一條的chunk data長度為1500,第二條的chunk data長度為500。當然這兩條chunk的chunk head肯定是不同的,其中第二條chunk的chunk head就是0字節的。


             

            posted on 2009-12-30 00:15 Richard Liu 閱讀(12464) 評論(14)  編輯 收藏 引用

            Feedback

            # re: RTMP協議詳解(三) 2010-03-03 16:39 roger
            good!期待第四期  回復  更多評論
              

            # re: RTMP協議詳解(三)[未登錄] 2010-03-10 00:05 peter
            請問你的服務器和 rtmpd 有什么不同啊?  回復  更多評論
              

            # re: RTMP協議詳解(三) 2010-03-10 20:09 Richard Liu
            @peter
            rtmpd是我實現時主要參考的代碼,不過rtmpd的功能更多,我只是實現了一部分的功能,主要是和公司的的業務相結合的一部分,關注的是直播的那一塊的應用  回復  更多評論
              

            # re: RTMP協議詳解(三) 2010-03-10 20:10 Richard Liu
            @roger
            第四期估計等閑的時候再出了哦  回復  更多評論
              

            # re: RTMP協議詳解(三) 2010-07-03 10:18 shelley
            "Timestamp:3bytes
            對于type 0的chunk,絕對時間戳在這里表示,如果時間戳值大于等于0xffffff(16777215),該值必須是0xffffff,且時間戳擴展字段必須發送,其他情況沒有要求。"

            請問如果時間戳值大于等于0xffffff(16777215),擴展時間戳字節怎么排放呢?

            我實現的RTMP時間戳一大于0xffffff, flash player 就斷開連接了。假如時間戳為0x12345678,那3字節時間戳:0xff 0xff 0xff, 4字節擴展時間戳:0x12 0x34 0x 56 0x78,其它字段沒變化。

            在時間戳值大于等于0xffffff(16777215)的情況下,還有什么需要修改的么?  回復  更多評論
              

            # re: RTMP協議詳解(三) 2010-07-21 15:47 小武
            高人, 指點下當發送VIDEO DATA 的時候,數據包是怎么封裝的吧。
            報文的頭部我大概知道,但是數據部分怎么封裝呢?比如我直接讀取一個.H264的文件。如何封裝?QQ23520813.可詳談。   回復  更多評論
              

            # re: RTMP協議詳解(三) 2010-08-20 21:25 Richard Liu
            @shelley
            @shelley
            參考一下RTMP的我協議如果大于0xfffffff直接把在0xffffff后面加上差值就可以,四個字節,比如說0xffffff+2后面四個字節就是2撒  回復  更多評論
              

            # re: RTMP協議詳解(三) 2010-08-20 21:29 Richard Liu
            @小武
            一個H。264的數據包封裝的時候 首先一定要確保客戶端收到的第一個視頻數據包是H。264的序列頭,其他的好像沒有什么要求吧,其他的就一幀一幀的數據發就可以了,還有就是要分辨H。264每一幀的文件是什么幀,I幀和中間幀的包頭不一樣的,參考一下FLV的文件格式就可以了  回復  更多評論
              

            # re: RTMP協議詳解(三) 2010-09-19 17:59 codebumb
            請教一下,對于audio數據包應該怎么發呢?audio的一些編碼參數什么怎么告訴client呢?是通過metadata嗎?我下了一份rtmp的官方文檔,好像對這塊只是簡略的提到一點。  回復  更多評論
              

            # re: RTMP協議詳解(三) 2011-08-29 16:12 lujiaming_brm
            您好,請問一個地方。
            我修改了rtmpdump中的rtmpsrv程序。
            發現使用一個Red5的客戶端可以播放FLV文件。
            但是如果開第二個Red5的客戶端就無法播放FLV文件。
            但是網絡抓包存在,
            而且第二個Red5的客戶端也會收到OnMetaData的。
            就是播放不了后續的音視頻流。

            另外我發現Red5的客戶端在播放的時候,會出現這個錯誤:
            Asynchronous code error - ReferenceError: Error #1069
            這個要如何避免???
              回復  更多評論
              

            # re: RTMP協議詳解(三) 2011-08-29 17:11 vliuchao
            建議你使用rtmpd這個服務器,也是開源的, rtmpsrv我沒用過,你說的那種情況我猜測是由于rtmpsrv對streamID的管理或者socket的管理有問題,
            Asynchronous code error - ReferenceError: Error #1069
            這個我也不是很清楚,你說的red5的客戶端我用過其實就是一個輸出調試信息的flash控件,這個錯誤可能是rtmpsrv實現rtmp協議有些消息沒有響應吧@lujiaming_brm
              回復  更多評論
              

            # re: RTMP協議詳解(三) 2011-08-30 11:34 lujiaming_brm
            @vliuchao
            謝謝您的回復。
            那請問一下,除了red5的客戶端,您平時都是使用什么客戶端工具測試的呢??能否推薦一個呢??

            我下載了那個rtmpd的代碼,make之后,使用red5的客戶端連接之后,發現rtmpd直接關閉了連接了。

            11:28:27:875 - Using Adobe Windows Flash Player 10,3,183,5
            11:28:38:656 - Connecting to rtmp://192.168.6.75/oflaDemo
            11:28:38:656 - NetConnection.Connect.Closed

            但是我閱讀代碼發現,main函數中的循環,就是簡單的read_client之后,write_client。而且write_chunk也寫得十分簡單。甚至根本就沒有對于視頻流0x9和音頻流0x8的處理。
            難道是您修改了rtmpd的代碼,加入了對于視頻流0x9和音頻流0x8的處理么。

            另外,如果可以通過QQ幫助我一下,
            我的郵箱是lujiaming_brm@163.com。如果可以,能否把您的QQ號發給我。
            謝謝了。  回復  更多評論
              

            # re: RTMP協議詳解(三) 2011-11-11 09:06 fanxin
            @lujiaming_brm
            有沒有rtmpd源碼。fpeter@126.com
            thanks!  回復  更多評論
              

            # re: RTMP協議詳解(三) 2013-11-25 13:25 藝搜天下
            總結得相當不錯,支持下。
            by www.elesos.com 站長  回復  更多評論
              

            久久se精品一区精品二区国产| 夜夜亚洲天天久久| 久久精品国产男包| 久久香综合精品久久伊人| 91久久国产视频| 久久笫一福利免费导航 | 69国产成人综合久久精品| 久久香蕉综合色一综合色88| 欧美久久一区二区三区| 久久精品人成免费| 欧美久久久久久午夜精品| 久久精品国产网红主播| 无码任你躁久久久久久老妇| 99久久婷婷国产综合亚洲| 一本色道久久88综合日韩精品| 99久久99这里只有免费的精品| 久久精品国产欧美日韩99热| 亚洲狠狠久久综合一区77777 | 亚洲中文精品久久久久久不卡| 99久久成人18免费网站| 久久久精品国产sm调教网站| 国产免费久久精品99re丫y| 青青热久久综合网伊人| 久久国产精品成人片免费| 国产69精品久久久久观看软件| 国产激情久久久久影院老熟女免费| 久久综合精品国产二区无码| 亚洲精品乱码久久久久久不卡| 国内精品久久久久影院网站| 99国产精品久久久久久久成人热| 精品国产99久久久久久麻豆 | 国产精品女同久久久久电影院| 久久福利资源国产精品999| 精品一久久香蕉国产线看播放| 精品一区二区久久| 狠狠狠色丁香婷婷综合久久五月| 色8久久人人97超碰香蕉987| 无码人妻精品一区二区三区久久 | 性做久久久久久免费观看| 久久www免费人成精品香蕉| 一本久久a久久精品综合夜夜|