Wireshark WikiのRTP エントリには、(編集)サンプル キャプチャなど、多くの情報が記載されています。あなたはそれを探索することができ、それはあなたの質問のいくつかに答えるかもしれません. RTP で動作するコードを作成する場合、Wireshark は監視/デバッグに役立ちます。
編集マーカー ビットに関する最初の質問については、このFAQが役立つかもしれません。また、フレーム (I、P、B) の検出は、ペイロードに依存します。MPEG で I、P、B がどのように検出されるかを示す別の質問があります。h263 -over-rtp.pcapには、H.263 の I および P フレームの例があります。
これは古い質問ですが、良い質問だと思います。
I、P、および B フレームについて言及しているように、2012 年には H.264 over RTP について言及している可能性があります。
[ rfc6184 ] 1によると、マーカー ビットはフレームの最後のパケットに設定されるため、実際にマーカー ビットは 1 フレームの終わりのインジケーターとして使用でき、シーケンス内の次のパケットが次のパケットの開始になります。フレーム。
この rfc によると、フレームのすべてのパケットも同じ RTPTIME を持つため、RTPTIME の変化は、前のフレームの終了と新しいフレームの開始の別の指標になります。
パケットが失われると、事態はさらに複雑になります。たとえば、パケット 5 と 6 が失われ、これらがフレーム 1 の最後のパケットであり、フレーム 2 の最初のパケットであるとします。フレーム 1 のマーカー ビットを含むパケットを取得したことがないため、フレーム 1 を破棄することはわかっていますが、フレーム 2 が全体であるかどうかをどのように知ることができますか。失われた 2 つのパケットはどちらもフレーム 1 の一部だったのでしょうか、それとも 2 番目のパケットはフレーム 2 の一部だったのでしょうか?
rfc6184 は、断片化された NAL ユニットの最初のパケットに存在する開始ビットを定義します。NAL ユニットがフラグメント化されていない場合、定義上、パケットを取得すると NAL ユニット全体が取得されます。これは、完全な NAL ユニットを取得したかどうかを知ることができることを意味します。残念ながら、フレームには複数の NAL ユニット (複数のスライスなど) が含まれる可能性があり、最初の NAL ユニットが失われる可能性があるため、これはフレーム全体を保証するものではありません。私はこの問題の解決策を持っていませんが、今後 10 年以内に解決策を提供してくれる人がいるかもしれません。