[html]view plain
copy
今天發現乙個奇怪的問題，用上位機的linphone客戶端撥打下位機的sip客戶端能夠正常工作，但是反過來就出問題了。 抓包發現linphone傳送了大量的ip fragmentation 資料報，google才知道，當發現的資料大於mtu時就發產生ip分片的資料報。rtp打包時不是已經進行了分片操作了嗎？正常情況應該不會出現這種情況才對。
linphone對h264進行rtp打包在rfc3984.c中進行，打包函式如下：
[cpp]view plain
copy
void
rfc3984_pack(rfc3984context *ctx, msqueue *naluq, msqueue *rtpq, uint32_t ts)
}
看來程式中定義了兩種打包模式，看看兩種模式有什麼區別
[cpp]view plain
copy
static
void
rfc3984_pack_mode_0(rfc3984context *ctx, msqueue *naluq, msqueue *rtpq, uint32_t ts)
send_packet(rtpq,ts,m,end);
} }
[cpp]view plain
copy
/*process nalus and pack them into rtp payloads */
static
void
rfc3984_pack_mode_1(rfc3984context *ctx, msqueue *naluq, msqueue *rtpq, uint32_t ts)else
else
ms_debug("sending previous msg as single nal"
);
send_packet(rtpq,ts,prevm,false);
prevm=null;
prevsz=0;
} }
if(sz<(ctx->maxsz/2))else
else
} }else
else
} } if
(prevm)
}
模式0竟然沒有rtp打包分片操作，而是直接send出去了，難怪ip協議自動進行了分片處理。於是想到，將rtp打包模式設定為1應該就可以了，後來發現可以直接通過sdp中的packetization-mode指定rtp打包模式。專案中出現的奇怪問題是因為，linphone預設使用了模式1打包，而下位機傳送的sdp資訊中沒有指定packetization-mode。 在正位的傳送的sdp中將packetization-mode指定為1，問題就解決了
H 264 中的相關問題
幀內解碼時，在解碼端，首先通過當前巨集塊左邊 上邊已經解碼完成的巨集塊使用當前巨集塊的 模式 模式計算過程請參見我的 h.264 本群原創資料 目錄中 得到當前巨集塊的畫素 值。然後通過對碼流進行解碼得到當前巨集塊的畫素殘差。最後將殘差和 值加在一起就得到重構的畫素值。如果當前巨集塊的左邊或者右邊的...
H 264 中的相關問題
幀內解碼時，在解碼端，首先通過當前巨集塊左邊 上邊已經解碼完成的巨集塊使用當前巨集塊的 模式 模式計算過程請參見我的 h.264 本群原創資料 目錄中 得到當前巨集塊的畫素 值。然後通過對碼流進行解碼得到當前巨集塊的畫素殘差。最後將殘差和 值加在一起就得到重構的畫素值。如果當前巨集塊的左邊或者右邊的...
H 264效能優化
h.264 優化 2007 05 24 2 20 h.264的dsp實現流程分為三個階段 第乙個階段產生和評估c 第二個階段優化和評估c 第三個階段編寫和評估線性彙編。每個階段完成任務如下 第一階段 首先，產生c 並進行時間評估。一般情況下，這個階段的 效能很低。如果經過評估後，仍然滿足不了實時要求...