queue: Fix race when calculating cur_level.time
authorStian Selnes <stian@pexip.com>
Wed, 14 Sep 2016 12:23:56 +0000 (14:23 +0200)
committerSebastian Dröge <sebastian@centricular.com>
Thu, 20 Oct 2016 11:14:20 +0000 (14:14 +0300)
On the first buffer, it's possible that sink_segment is set but
src_segment has not been set yet. If this is the case, we should not
calculate cur_level.time since sink_segment.position may be large and
src_segment.position default is 0, with the resulting diff being larger
than max-size-time, causing the queue to start leaking (if
leaky=downstream).

One potential consequence of this is that the segment event may be
stored on the srcpad before the caps event is pushed downstream, causing
a g_warning ("Sticky event misordering, got 'segment' before 'caps'").

https://bugzilla.gnome.org/show_bug.cgi?id=773096

plugins/elements/gstqueue.c

index e8f7f89..97aa0c0 100644 (file)
@@ -546,7 +546,7 @@ update_time_level (GstQueue * queue)
   GST_LOG_OBJECT (queue, "sink %" GST_STIME_FORMAT ", src %" GST_STIME_FORMAT,
       GST_STIME_ARGS (sink_time), GST_STIME_ARGS (src_time));
 
-  if (sink_time >= src_time)
+  if (sink_time >= src_time && queue->newseg_applied_to_src)
     queue->cur_level.time = sink_time - src_time;
   else
     queue->cur_level.time = 0;