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

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
This commit is contained in:
Tim-Philipp Müller 2012-11-26 18:41:07 +00:00
parent 601aabdf9c
commit 7c89a7298a

View file

@ -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;