[Bug 769394] appsink callback race condition

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Jake Foytik <jake.foytik at ipconfigure.com> ---
Actually, we've been using appsink in this way for quite some time (changing
the appsink callbacks in the RUNNING state). I'm surprised we haven't seen an
issue with this sooner. It is nice having the ability for another thread to
connect up to the appsink without having to disturb the parent pipeline. 

If we were to only allow the callbacks to be set in the NULL or READY state,
how would the gst_app_sink_set_callbacks() function behave? Have it post an
error/warning and immediately return? Or, have this function return a bool
indicating if the callbacks were actually set?

For now, to get around the issue in regards to our application, I've created a
patch that adds a mutex for the callback operations (wherever they are executed
or set), which appears to fix the problem. I can post that patch if you like.
Else, I can work on making a patch for the other approach.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.