RTSPデバッグの問題が発生しました
多くの、多くの移植方法についてRTSPオープンソースコードなので、あまり説明をしません。私は主に、移行中に発生した問題を見落とすためにいくつかの簡単についてのあなたに来ます。
A、32ビットおよび64ビットシステムの互換性の問題
現在では、ほとんどの組み込みシステムでは、32ビットですが、いくつかの64のない不足はありません。だから、移行中に、私たちは特に注意する必要があります。ここで、システムは、データバイト、32ビット、64ビットサイズの種類によって占有されています。
32位：
int型4バイト
long int型は4つのバイト
長い長い8つのバイト
ポインタ4つのバイト
64位：
int型4バイト
long int型8つのバイト
長い長い8つのバイト
ポインタ8つのバイト
移行時には、我々はネットワークバイトオーダー変換ステップを持っています。このようなパッケージ、SSRCやタイムスタンプ、必要バイト変換、ここでは特別な注意ので。デバッグでは、我々は、変換前と変換後の値をプリントアウトすることができ、善悪の分析。もちろん、あなたはまた、分析waresharkをキャプチャする情報が正確である見ることができます。
第二に、プレイタイムスタンプの問題
1、H.264のタイムスタンプ：
タイムスタンプ= 90000 /フレームレート*（フレーム番号 - 参照フレーム番号）。//参照フレーム番号、我々は一般的に見つけるには、などのキーフレームの前に参照フレームであります
2、AACスタンプ：
（ - > AAC PCM）、スタンプユニットとして一般に1024で、我々はそれが適切1024符号化関数にコードのサンプルを必要とするためAACは、特殊です。
タイムスタンプ= 1024 *（フレーム番号 - 参照フレーム番号）//我々は同様にオーディオ規格として前のレコードオーディオの参照フレーム番号などのビデオキーフレームを見つけます
オーディオデータパケットは、ポイント1024 PCMオーディオエンコードのソースデータをサンプリングしたデータです。
第三に、オーディオとビデオは、通常のデバッグを再生されません
1、最初の一般的なデバッグビデオ、ビデオデバッグOKは、その後、オーディオデバッグを追加した後
まず、すべてのオーディオおよびビデオソースのかどうかOKかを決定するために、第二のRTPパッケージOK（システム桁に注意を払うには、この時間）かどうかを判断するために、リンクが正常に確立された場合は、ネットワークパケットキャプチャを確認するために、SDP情報が合理的です。
タイムスタンプを持つ2、単一のビデオ再生、動画再生レートが表示されない場合は、遅すぎる、または早すぎるケイトン、最も可能性の高い問題
特定のタイムスタンプ値を見ることがきちんとされ、パケットシーケンス場合、パケット損失があるかどうか、確認するために継続的なパケットキャプチャがあります。
3、オーディオとビデオのオーディオの追加は例外が発生した原因となる場合。二つの理由があるかもしれません
一つの理由：
問題のオーディオとビデオの再生タイムスタンプ。
原因二：
ビデオフレームを送信する際に、中間フレームがオーディオに挿入され、デコーダの結果は正しくデコードできません。（私は本当にこの推論に同意しない、私は、ビデオフレームキャプチャを見つけ、理論的には、オーディオとビデオの送信が異なるポートを介して行われるため、という問題のRTSPサーバのバージョンを疑う。しかし、実際のデバッグが、それは問題の登場です限り、オーディオとビデオの再生が異常発生線でカットされるように）
大きなビデオフレームので、一般的にサブパケット送信を複数必要とします。300のパケットであるIフレームのような、突然以降に、1つのオーディオフレームによってキューをジャンプするパケット200を送信するときは、再生が解決できないので、受信側の残り100を送信し続けます。
溶液：シングルスレッドプロセスのオーディオおよびビデオ送信、両者は、オーディオおよびビデオを送信するマルチスレッド、それぞれ、ビデオフレームを防止するために、ロックに追加されるべき割込みです。
その後、いくつかの個人的な感情や経験、私たちは一緒に改善し、一緒に分析、議論を歓迎します。
