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

            一路走來(lái),只有C++和香煙最實(shí)在!

            Just Dive Into!

            C++博客 首頁(yè) 新隨筆 聯(lián)系 聚合 管理
              11 Posts :: 0 Stories :: 29 Comments :: 0 Trackbacks

            Chunk Msg Header

            Chunk Msg Header的長(zhǎng)度是可變的,Chunk Msg Header可變的原因是為了壓縮傳輸?shù)淖止?jié)數(shù),把一些相同類型的chunkhead去掉一些字節(jié),換句話說(shuō)就是四種類型的包頭都可以通過(guò)一定的規(guī)則還原成11個(gè)字節(jié),這個(gè)壓縮和還原在RTMP協(xié)議中稱之為復(fù)用/解復(fù)用。

            那我們以11個(gè)字節(jié)的完整包頭來(lái)解釋Chunk Msg Header,如圖所示

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

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

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

            Timestamp3bytes

            對(duì)于type 0chunk,絕對(duì)時(shí)間戳在這里表示,如果時(shí)間戳值大于等于0xffffff16777215),該值必須是0xffffff,且時(shí)間戳擴(kuò)展字段必須發(fā)送,其他情況沒(méi)有要求。

            message length:3bytes

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

            message type  id:1byte

            Message的類型ID,具體的值將在后文專門(mén)來(lái)討論。

            message stream id:4bytes

            message stream id的字節(jié)序是小端序,這個(gè)字段是為了解復(fù)用而設(shè)計(jì)的,RTMP文檔上說(shuō)的相當(dāng)?shù)哪:?/span>

             

            message stream ID可以使任意值,不同的消息流復(fù)用成相同的chunk stream,基于它們的ID能夠解復(fù)用。于chunk stream 是相關(guān)的,這個(gè)字段是一個(gè)不透明的值沒(méi)有整明白什么意思,我的理解就是用來(lái)標(biāo)識(shí)和服務(wù)器連接的flash端的序號(hào)。

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

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

            +         timestamp    delta      +            message length         + message type  id +             

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

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

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

                                       +         timestamp    delta      +         

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


                    0 bytes的chunk head,這種類型的chunk從前一個(gè)chunk得到值信息,當(dāng)一個(gè)單個(gè)消息拆成多個(gè)chunk時(shí),這些chunk除了第一個(gè)以外,其他的都應(yīng)該使用這種類型,

            chunk的長(zhǎng)度:

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


             

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

            Feedback

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

            # re: RTMP協(xié)議詳解(三)[未登錄](méi) 2010-03-10 00:05 peter
            請(qǐng)問(wèn)你的服務(wù)器和 rtmpd 有什么不同啊?  回復(fù)  更多評(píng)論
              

            # re: RTMP協(xié)議詳解(三) 2010-03-10 20:09 Richard Liu
            @peter
            rtmpd是我實(shí)現(xiàn)時(shí)主要參考的代碼,不過(guò)rtmpd的功能更多,我只是實(shí)現(xiàn)了一部分的功能,主要是和公司的的業(yè)務(wù)相結(jié)合的一部分,關(guān)注的是直播的那一塊的應(yīng)用  回復(fù)  更多評(píng)論
              

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

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

            請(qǐng)問(wèn)如果時(shí)間戳值大于等于0xffffff(16777215),擴(kuò)展時(shí)間戳字節(jié)怎么排放呢?

            我實(shí)現(xiàn)的RTMP時(shí)間戳一大于0xffffff, flash player 就斷開(kāi)連接了。假如時(shí)間戳為0x12345678,那3字節(jié)時(shí)間戳:0xff 0xff 0xff, 4字節(jié)擴(kuò)展時(shí)間戳:0x12 0x34 0x 56 0x78,其它字段沒(méi)變化。

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

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

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

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

            # re: RTMP協(xié)議詳解(三) 2010-09-19 17:59 codebumb
            請(qǐng)教一下,對(duì)于audio數(shù)據(jù)包應(yīng)該怎么發(fā)呢?audio的一些編碼參數(shù)什么怎么告訴client呢?是通過(guò)metadata嗎?我下了一份rtmp的官方文檔,好像對(duì)這塊只是簡(jiǎn)略的提到一點(diǎn)。  回復(fù)  更多評(píng)論
              

            # re: RTMP協(xié)議詳解(三) 2011-08-29 16:12 lujiaming_brm
            您好,請(qǐng)問(wèn)一個(gè)地方。
            我修改了rtmpdump中的rtmpsrv程序。
            發(fā)現(xiàn)使用一個(gè)Red5的客戶端可以播放FLV文件。
            但是如果開(kāi)第二個(gè)Red5的客戶端就無(wú)法播放FLV文件。
            但是網(wǎng)絡(luò)抓包存在,
            而且第二個(gè)Red5的客戶端也會(huì)收到OnMetaData的。
            就是播放不了后續(xù)的音視頻流。

            另外我發(fā)現(xiàn)Red5的客戶端在播放的時(shí)候,會(huì)出現(xiàn)這個(gè)錯(cuò)誤:
            Asynchronous code error - ReferenceError: Error #1069
            這個(gè)要如何避免???
              回復(fù)  更多評(píng)論
              

            # re: RTMP協(xié)議詳解(三) 2011-08-29 17:11 vliuchao
            建議你使用rtmpd這個(gè)服務(wù)器,也是開(kāi)源的, rtmpsrv我沒(méi)用過(guò),你說(shuō)的那種情況我猜測(cè)是由于rtmpsrv對(duì)streamID的管理或者socket的管理有問(wèn)題,
            Asynchronous code error - ReferenceError: Error #1069
            這個(gè)我也不是很清楚,你說(shuō)的red5的客戶端我用過(guò)其實(shí)就是一個(gè)輸出調(diào)試信息的flash控件,這個(gè)錯(cuò)誤可能是rtmpsrv實(shí)現(xiàn)rtmp協(xié)議有些消息沒(méi)有響應(yīng)吧@lujiaming_brm
              回復(fù)  更多評(píng)論
              

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

            我下載了那個(gè)rtmpd的代碼,make之后,使用red5的客戶端連接之后,發(fā)現(xiàn)rtmpd直接關(guān)閉了連接了。

            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

            但是我閱讀代碼發(fā)現(xiàn),main函數(shù)中的循環(huán),就是簡(jiǎn)單的read_client之后,write_client。而且write_chunk也寫(xiě)得十分簡(jiǎn)單。甚至根本就沒(méi)有對(duì)于視頻流0x9和音頻流0x8的處理。
            難道是您修改了rtmpd的代碼,加入了對(duì)于視頻流0x9和音頻流0x8的處理么。

            另外,如果可以通過(guò)QQ幫助我一下,
            我的郵箱是lujiaming_brm@163.com。如果可以,能否把您的QQ號(hào)發(fā)給我。
            謝謝了。  回復(fù)  更多評(píng)論
              

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

            # re: RTMP協(xié)議詳解(三) 2013-11-25 13:25 藝搜天下
            總結(jié)得相當(dāng)不錯(cuò),支持下。
            by www.elesos.com 站長(zhǎng)  回復(fù)  更多評(píng)論
              


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


            久久亚洲精品无码AV红樱桃| 久久精品成人国产午夜| 国产亚洲精久久久久久无码77777| 亚洲精品第一综合99久久| 久久人妻AV中文字幕| 久久久精品国产sm调教网站| 国产精品视频久久久| 久久e热在这里只有国产中文精品99 | 漂亮人妻被中出中文字幕久久| 久久男人中文字幕资源站| 老男人久久青草av高清| 人妻无码αv中文字幕久久| 久久夜色tv网站| 中文字幕无码久久久| 精品国产乱码久久久久久郑州公司 | 亚洲欧美日韩中文久久| 久久永久免费人妻精品下载| 狠狠色噜噜狠狠狠狠狠色综合久久| 久久精品国产精品青草| 久久久久免费视频| 色婷婷综合久久久久中文一区二区 | 亚洲国产精品成人久久| 久久精品国产亚洲77777| 99久久人人爽亚洲精品美女 | 精品无码久久久久久午夜| 国产精品成人99久久久久| 人妻无码αv中文字幕久久琪琪布| 久久精品国产亚洲AV嫖农村妇女 | 99久久精品免费| 久久久噜噜噜久久中文字幕色伊伊 | 无码国内精品久久综合88| 丰满少妇人妻久久久久久| 日本精品一区二区久久久| 国内精品伊人久久久久av一坑 | 精品久久一区二区三区| 亚洲国产精品嫩草影院久久| 国产情侣久久久久aⅴ免费| 伊人久久大香线蕉综合5g| 久久天堂电影网| 青草国产精品久久久久久| 热综合一本伊人久久精品|