We now allow for the possibility of the RTCP audio/video synchronization being

incorrect.  (I encounted a stream for which this was the case.)  Now, if
audio and video are out-of-sync by >60 seconds, we assume that the RTCP
sync is incorrect, and we don't discard any packets.


git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12008 b3059339-0415-0410-9bf9-f77b7e298cf2

1 files changed, 7 insertions, 1 deletions

diff --git a/libmpdemux/demux_rtp.cpp b/libmpdemux/demux_rtp.cpp
index 5366cb8097..8bd5d38732 100644
--- a/libmpdemux/demux_rtp.cpp
+++ b/libmpdemux/demux_rtp.cpp
@@ -305,8 +305,14 @@ extern "C" int demux_rtp_fill_buffer(demuxer_t* demuxer, demux_stream_t* ds) {
     // audio and video streams get this far apart.)
     // (We don't do this when streaming over TCP, because then the audio and
     // video streams are interleaved.)
+    // (Also, if the stream is *excessively* far behind, then we allow
+    // the packet, because in this case it probably means that there was
+    // an error in the source's timestamp synchronization.)
     const float ptsBehindThreshold = 1.0; // seconds
-    if (ptsBehind < ptsBehindThreshold || rtspStreamOverTCP) { // packet's OK
+    const float ptsBehindLimit = 60.0; // seconds
+    if (ptsBehind < ptsBehindThreshold ||
+	ptsBehind > ptsBehindLimit ||
+	rtspStreamOverTCP) { // packet's OK
       ds_add_packet(ds, dp);
       break;
     }