RTSP サーバーを作成しました。RTP/UDP 経由で h246/AAC ストリーム データを送信します。ビデオの RTP 送信パケット間隔は 30 ミリ秒、オーディオは 20 ミリ秒です。タイムスタンプは flv タグから抽出されます (私のサーバーは flv ファイルからビデオとオーディオのデータを取得します)。ビデオ プレーヤーで最初の数フレームが失われます。その結果、オーディオはビデオよりも数秒進んでいます。どうしてこれなの?サーバー側でストリーミングする前に一時停止する必要がありますか?
1 に答える
いくつかの可能性があります:
UDP は信頼性の低いプロトコルです。RTP シーケンス番号をチェックして、これが該当するかどうか、およびドロップされたフレームの数とフレームを確認できます。UDP パケット損失を最小限に抑えるには、クライアントの UDP 受信バッファー サイズを増やすことが役立ちます。Linux での実行方法の例を次に示します。もちろん、Windowsでも同じことができます。
クライアントは、IDR フレームを受信した後にのみ、ビデオを正しくデコードできます。その時点まで、ビデオを正しくデコードできません。新しいクライアントにストリーミングする最初のフレームは IDR フレームですか (まだ失われる可能性があることに注意してください)。
いずれにせよ、ビデオ プレーヤー アプリケーションには別の問題があるように思えます。フレームがドロップされた場合でも、プレーヤーはオーディオとビデオのバッファリングと同期を担当し、パケット損失に関係なくこれを実行できるはずです。
純粋に参考情報として、RTSP を介して (したがって TCP を介して) インターリーブされた RTP/RTCP を実装することもできます。そうすれば、コマ落ちを心配する必要はありません。live555メディア ストリーミングライブラリやVLCなどのライブラリがこれをサポートしています。
一時停止についての最後の質問に答えるには: いいえ、それはそれとは何の関係もありません。RTSP は純粋にシグナリング プロトコルです。トランスポート (UDP) 層でパケット損失が発生します。