如何修復不正確的時間戳計算？ [OpenRtspClient]

我的RTSP Source的RTCPSR對於計算的H.264流的時間戳中的一些經常導致大的負跳轉不可靠。如何修復不正確的時間戳計算？ [OpenRtspClient]

以下是調試日誌的示例。看看它是如何從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？

來源

2011-12-16 Novalis

是否使用LIVE555專門的客戶端？用未修改源代碼？問題中的日誌信息來自哪裏？

一般來說，會有總是在時間戳相當接近流的開始一個跳躍：當通過在該點上的客戶端復位時間戳客戶端接收到的第一RTCP SR發生這種情況。這是非常必要的，因爲客戶端可以同步多個流，因爲音頻和視頻中的RTP時間戳都以隨機偏移開始。 RTCP SR包含從RTP到NTP時間戳的映射，允許客戶端同步時間戳。由於RTP和NTP時間戳都是未簽名的，因此時間戳跳轉爲負數並不重要。

Live555處理這種同步，這就是爲什麼你可能會看到一個相當接近開始的時間戳的跳轉。您可以選擇忽略RTCP同步之前接收的所有采樣，也可以執行更復雜的偏移映射，以使RTCP之前的同步和之後的值均爲零。您可以通過調用live555 RtpSource::hasBeenSynchronizedUsingRTCP()方法來檢查是否發生了同步。

但是，如果您看到多個跳轉，那麼您可能會遇到不同的問題。 ;在這種情況下，請通過添加更多的細節，比如使用RTSP服務器，RTSP客戶端等

來源

2011-12-19 07:59:18 Ralf

我修改LIVE555打開RTSP代碼...使其更加面向對象和多線程可用enviromented ......問題是，多數民衆贊成一些[並非所有]我的RTSP服務器[這是IP攝像機]即使不採取-發送任何RTCP信息...所以RtpSource :: hasBeenSynchronizedUsingRTCP（）永遠不會是真的... – Novalis 2011-12-19 09:05:28

順便說一下，當我連接我的rtsp源碼到解碼器並渲染它時，因爲我不給任何時間戳值給媒體樣本......但是當嘗試記錄我必須給時間戳然後記錄文件包含所有幀但錯誤的時間戳... – Novalis 2011-12-19 09:07:39

我真的不知道RTCP SR執行編輯你的問題因此我不知道100605.xxxx代表的單位。但是，如果我假設一般如果我相信它們是從流的90 kHz時鐘值的PTS/DTS值派生的。

如果這是真的，衆所周知，這樣的時鐘定時器在2^33比特處自行回收。這被稱爲時鐘的WRAPAROUND。如果這是打印爲有符號的數字 - 這將成爲積極的。這種環繞將在一定的Clock值之後發生。

驗證確實最高和最低值總是處於相同或相似的範圍內。

其他這樣的可能性被稱爲不連續性當源時基突然轉移（可能由於某種故障）時出現。

來源

2011-12-26 12:39:00

如何修復不正確的時間戳計算？ [OpenRtspClient]

回答

相關問題