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

            牽著老婆滿街逛

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

            jrtplib 分包處理

            轉載自:http://blog.csdn.net/sxcong/article/details/3736354

            聽說jrtplib寫的不錯,終于找到時間下來看看。
            下載,直接用VC6編譯,很容易。
            然后打開VC,建立工程,測試examples下那幾個收發程序,的確用起來很簡單。想想以前都是自己封裝UDP,現在的程序員真幸福。
            不過,在發送視頻數據時出了問題,跟蹤進去看了一下,里面設置最大幀數據長度為1400。于是自己設置最大為32X1024,跟進去還不行。
            原來是內部沒有分包處理,超過上限就不允許發了。
            隨便搜了一個,有個叫SmartView的視頻會議源碼,是改寫jrtplib的RTPSession的SendPacket,在這里分包。很不錯的想法。
            不過又一想,jrtplib,本身是做為lib提供的,雖然可以改寫其代碼,但肯定與作者初衷不符。
            于是找到利用這個庫的同作者寫的開源項目emiplib,夠復雜的,把ffmpeg也集進來了。先不管,直接搜索關鍵字RTPSession和SendPacket,發現他發
            送的是自己封裝的一個類MIPRTPSendMessage,其父類是MIPMessage。看到這想都不用想,作者肯定是在發送之前先進行了處理,形成了自己定義格式的Message再發送。
            收到后在形成MIPRTPRecvMessage。這應該是是最正規的寫法。
            不過,想想這個庫,雖然沒用過,但很多年前就聽人說過,肯定考慮過這些問題。沒有文件,就仔細看頭文件,終于發現了SendPacketEx這個函數,一大堆英文說明,
            剛才沒仔細看:
                /** Sends the RTP packet with payload /c data which has length /c len.
                 *  The packet will contain a header extension with identifier /c hdrextID and containing data 
                 *  /c hdrextdata. The length of this data is given by /c numhdrextwords and is specified in a 
                 *  number of 32-bit words. The used payload type, marker and timestamp increment will be those that
                 *  have been set using the /c SetDefault member functions.
                 */
                 這回看清楚了吧,對,就是那個hdrextdata,是分包的數據,是長度,hdrextID是其ID。這樣,發送數據的時候,先分好包,再調用SendPacketEx就行了。
                 
                 發送沒問題了,再說接收。也不看類結構了,參考亞歷山大方法,直接搜索recvfrom。在
                 RTPUDPv4Transmitter::PollSocket這里找到了,然后緊接就是RTPRawPacket *pack;pack = RTPNew(....
                 很好,收到后先封裝成了RTPRawPacket。但是,最終和用戶打交道的是RTPPacket,于是看它的頭文件,一眼就看到:
                     /** If a header extension is present, this function returns the extension identifier. */
                uint16_t GetExtensionID() const                                                        { return extid; }

                /** Returns the length of the header extension data. */
                uint8_t *GetExtensionData() const                                                    { return extension; }
                
                /** Returns the length of the header extension data. */
                size_t GetExtensionLength() const                                                    { return extensionlength; }
                
                對頭,這就是我們需要的。
                但是,這三個值是怎么出現的呢?回頭再看從RTPRawPacket-->RTPPacket.
                 處理的過程看起來比較復雜,就先找外面的回調,應該在ProcessPolledData里面。
                 然后,看到了ProcessRawPacket(...),參數都不用看,從函數名就知道這是我們想要了解的東西了。其實不知道這個也沒關系,我們只需要調用上面那三個函數
                 就可以在外面重新組包了。
                 
                 兩瓶酒的時間分析結束。不過只是聽說這個庫寫的不錯,隨手記下來看看,實在沒興趣動手用代碼來實現了。有哪位兄弟能寫出代碼附上就好了。

            posted on 2013-09-03 14:36 楊粼波 閱讀(2507) 評論(0)  編輯 收藏 引用

            久久综合久久久| 精品久久久久中文字幕一区| 2021最新久久久视精品爱 | 国产成人久久AV免费| 国产精品毛片久久久久久久| 久久精品一区二区影院| 久久亚洲日韩看片无码| 久久婷婷国产麻豆91天堂| 午夜精品久久久久久影视riav| 国产精品久久久久影视不卡| 久久亚洲国产成人影院网站 | 久久免费视频网站| 国产精品亚洲综合久久| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 色综合合久久天天综合绕视看| 久久久久亚洲AV无码专区网站 | 国产香蕉久久精品综合网| 久久国产精品成人免费| 青青草原综合久久大伊人| 国产精品美女久久久网AV| 久久Av无码精品人妻系列| 久久精品国产99国产精品导航| 岛国搬运www久久| 国产国产成人久久精品| 国产精品免费看久久久| 色偷偷88888欧美精品久久久| 久久久午夜精品| 综合久久一区二区三区 | 亚洲人成网站999久久久综合| 91精品国产91久久久久久| 久久国产精品-久久精品| 久久夜色精品国产亚洲| 日韩欧美亚洲综合久久影院d3| 久久国产精品成人免费| 伊人久久大香线蕉影院95| 亚洲精品高清久久| 国产精品无码久久四虎| 久久国产成人精品国产成人亚洲| 久久国产成人午夜AV影院| 色天使久久综合网天天| 97香蕉久久夜色精品国产|