mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-27 12:11:13 +00:00
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:
parent
601aabdf9c
commit
7c89a7298a
1 changed files with 7 additions and 1 deletions
|
@ -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;
|
||||
|
|
Loading…
Reference in a new issue