不正なタイムスタンプ計算を修正するにはどうすればよいですか？ [OpenRtspClient]

Question

私のRTSP SourceのRTCPSRは、H.264ストリームの計算されたタイムスタンプの一部では信頼性が低く、頻繁に大きな負のジャンプが発生します。

ここに、デバッグログの例を示します。それが101006.6130から-4193861.6830にどのようにジャンプし、その方法を続けるかを見てください。

101619 : 5cd3c38 Sample 63682 bytes time 100605.6130 to 100605.6131 latency 1264447034.4738 
101715 : 5cd3c38 Sample 74194 bytes time 100706.6130 to 100706.6131 latency 1264447039.4738 
101815 : 5cd3c38 Sample 72484 bytes time 100804.6130 to 100804.6131 latency 1264447038.4738 
101923 : 5cd3c38 Sample 95679 bytes time 100906.6130 to 100906.6131 latency 1264447031.4738 
102023 : 5cd3c38 Sample 93004 bytes time 101006.6130 to 101006.6131 latency 1264447031.4738 
102134 : 5cd3c38 Sample 91388 bytes time -4193861.6830 to -4193861.6829 latency 1260152052.1778 
102222 : 5cd3c38 Sample 90912 bytes time -4193738.1730 to -4193738.1729 latency 1260152088.6878 
102328 : 5cd3c38 Sample 105902 bytes time -4193636.1730 to -4193636.1729 latency 1260152083.6878 
102430 : 5cd3c38 Sample 106334 bytes time -4193537.1730 to -4193537.1729 latency 1260152081.6878 
102520 : 5cd3c38 Sample 107120 bytes time -4193437.1730 to -4193437.1729 latency 1260152090.6878 

だから、私の質問は：

どのように私はLive555メディアのlibを使用してこの問題を解決することができますか？私は をRTCPの情報、または推奨される解決策を無視し、 をどのようにしてLive555に適用できますか？

Answer 1

live555はクライアント専用ですか？ は変更されていませんソースコード？あなたの質問のログ情報はどこから来たのですか？

一般的に、常には、ストリームの先頭にかなり近いタイムスタンプを1回のジャンプがあるでしょう：最初のRTCP SRはタイムスタンプをリセットクライアントをその時点でクライアントによって受信されたときに発生します。これは、オーディオとビデオの両方のRTPタイムスタンプがそれぞれランダムなオフセットで始まるため、クライアントが複数のストリームを同期できるようにするために必要です。 RTCP SRには、RTPからNTPタイムスタンプへのマッピングが含まれています。これにより、クライアントはタイムスタンプを同期させることができます。タイムスタンプが負になるという事実は、RTPタイムスタンプとNTPタイムスタンプの両方が符号なしであるので問題ではない。

Live555がこの同期を処理するため、開始時刻にかなり近いタイムスタンプでジャンプが表示されることがあります。 RTCP同期の前に受信したすべてのサンプルを無視するか、RTCP同期の前と後の両方に、より複雑なオフセットマッピングをゼロにすることができます。 live555 RtpSource::hasBeenSynchronizedUsingRTCP()メソッドを呼び出すことで、同期が行われたかどうかを確認できます。

複数のジャンプが表示されている場合は、別の問題が発生する可能性があります。その場合は、RTSPサーバー、RTSPクライアントなどの詳細を追加して質問を編集してください。

Answer 2

RTCP SRの実装は本当にわかりません。その結果、私は100605.xxxxが表す単位を知らない。しかし、もし私がそれがストリームの90 kHzのクロック値のPTS/DTS値から派生していると思えば、私はそれを仮定します。

これが当てはまる場合、このようなクロックタイマーは2^33ビットでリサイクルされることはよく知られています。これはクロックのラッパルーンと呼ばれます。これが符号付き数値として出力された場合、これは正の値になります。このようなラップアラウンドは、Clockの特定の値の後に正確に発生します。

確かに、最高値と最低値が常に同じまたは類似の範囲にあることを検証する。

他の可能性は不連続と呼ばれ、ソースタイムベースが突然（おそらく何らかのフォールトのために）シフトするときに発生します。