[Bug 705835] queue: Sticky event misordering: 'caps' before 'stream-start'

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=705835
  GStreamer | gstreamer (core) | 1.0.6

--- Comment #1 from Sebastian Rasmussen <sebras at hotmail.com> 2013-08-16 21:19:56 UTC ---
Our assumption is that the queue element fails to dequeue any internally
enqueued serialized events (and buffers?) when it is going READY->NULL. The
queue element source code does not implement any change-state function and so
it seems to confirm the bug (unless there is trickery going on with the pad
(de)activation function which seems to be able to dequeue events too, but it is
unknown when the (de)activation function should be called and under what
circumstances it does dequeuing).

The queue element goes through these state changes:

NULL1->READY1->PLAYING1->READY2->NULL2->READY3->PLAYING2->READY4->NULL3

The sticky events on the sinkpad and srcpad were printed after having reached
NULL2 and NULL3 (after the two gst_element_set_state (pipeline, GST_STATE_NULL)
above). No events were sticking to the pads. The queue's source code shows that
any serialized events are enqueued in the internal queue.

In the bug report above "Flushing the queue" refers to dequeuing the internally
enqueued serialized events. We test-implemented a change-state function which
dequeues the enqueued events when going READY->NULL and this makes it
impossible for us to reproduce the warning.

At the moment I am not convinced that dequeuing the elements in a change-state
function is 100% due to being unfamiliar with the code. I haven't understood
the activation function.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.