streamsynchronizer: don't send gap events with huge bogus durations when advancing...

When the input buffers for a stream don't have a duration set,
timestamp_end might still be GST_CLOCK_TIME_NONE. When advancing
EOSed streams via GAP events (with other streams not yet EOS), we
would then use the invalid timestamp_end to calculate the duration
of the gap. This in turn would make baseaudiosink abort, because it
would try to allocate memory for a trizillion samples.

So if buffers don't have a duration set, assume a duration of
one second for stream catch-up purposes, just so we can still
continue to catch up in those cases. And make sure that
timestamp_end is valid before doing calculations with it.

http://bugzilla.gnome.org/show_bug.cgi?id=678530

diff --git a/gst/playback/gststreamsynchronizer.c b/gst/playback/gststreamsynchronizer.c
index 9967a07..0f1c982 100644 (file)
--- a/gst/playback/gststreamsynchronizer.c
+++ b/gst/playback/gststreamsynchronizer.c
@@ -565,6 +565,11 @@ gst_stream_synchronizer_sink_chain (GstPad * pad, GstObject * parent,
 
     /* Advance EOS streams if necessary. For non-EOS
      * streams the demuxers should already do this! */
+    if (!GST_CLOCK_TIME_IS_VALID (timestamp_end) &&
+        GST_CLOCK_TIME_IS_VALID (timestamp)) {
+      timestamp_end = timestamp + GST_SECOND;
+    }
+
     for (l = self->streams; l; l = l->next) {
       GstStream *ostream = l->data;
       gint64 position;
@@ -578,7 +583,8 @@ gst_stream_synchronizer_sink_chain (GstPad * pad, GstObject * parent,
         position = ostream->segment.start;
 
       /* Is there a 1 second lag? */
-      if (position != -1 && position + GST_SECOND < timestamp_end) {
+      if (position != -1 && GST_CLOCK_TIME_IS_VALID (timestamp_end) &&
+          position + GST_SECOND < timestamp_end) {
         gint64 new_start;
 
         new_start = timestamp_end - GST_SECOND;