videomixer: Do not send flush_stop when receiving a seek

There is no reason to send a flush-stop when receiving a seek event.
In the case of a flushing seek, we could eventually want to, but in
the code path were we check if the seek is "flushing", we have the
following comment that makes sense:

"we can't send FLUSH_STOP here since upstream could start pushing data
after we unlock mix->collect.
We set flush_stop_pending to TRUE instead and send FLUSH_STOP after
forwarding the seek upstream or from gst_videomixer_collected,
whichever happens first."

https://bugzilla.gnome.org/show_bug.cgi?id=684237
This commit is contained in:
Thibault Saunier 2013-05-05 20:25:20 +01:00
parent 85b6852deb
commit 718f9004d0

View file

@ -1406,13 +1406,6 @@ gst_videomixer2_src_event (GstPad * pad, GstObject * parent, GstEvent * event)
gst_videomixer2_reset_qos (mix);
result = gst_videomixer2_push_sink_event (mix, event);
if (g_atomic_int_compare_and_exchange (&mix->flush_stop_pending, TRUE,
FALSE)) {
GST_DEBUG_OBJECT (mix, "pending flush stop");
gst_pad_push_event (mix->srcpad, gst_event_new_flush_stop (TRUE));
}
break;
}
case GST_EVENT_NAVIGATION: