[Bug 690420] Random lock-up in GstDiscoverer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=690420
  GStreamer | gst-plugins-base | 1.x

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED

--- Comment #10 from Sebastian Dröge <slomo at circular-chaos.org> 2013-05-23 21:32:56 UTC ---
Maybe instead of this NO_RESYNC flag that was added, instead decodebin should
just have used gst_element_set_locked_state(TRUE) on the parser as long as it
was handling its state manually, and after it was done with that pass it back
to GstBin again with gst_element_set_locked_state(FALSE). If I'm not missing
anything this would have exactly the same behaviour of the NO_RESYNC flag for
the original bug, but without causing the bug mentioned in comment 9:

Thread 1 would add the parser, set it to READY and PAUSED, etc (with having the
parser in locked state), while Thread 2 is waiting to be able to shut down
typefind (which it only can after Thread 1 left the streaming thread of
typefind). Then locked state of the parser is unset, thread 1 goes out of the
streaming thread of typefind.
Then thread 2 is shutting down typefind finally, continuing the iterator and
seeing that it changed (the parser was added since it was waiting when changnig
typefind's state!), resync, shut down typefind, shut down *all* data flow. And
then return to GstDecodeBin's state change function without any dataflow
happening anymore.


I will experiment with that tomorrow.

-- 
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.