[Bug 769394] appsink callback race condition

[GStreamer (GNOME Bugzilla)]

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

--- Comment #4 from Jake Foytik <jake.foytik at ipconfigure.com> ---
The race condition can be prevented by protecting the set_callbacks() function
with a lock, and protecting the segments where callbacks.eos(),
callbacks.new_preroll(), and callbacks.new_sample() are checked and called. 

Our use-case is that we have a capture/archive pipeline that records streams
from a camera. We have an RTSP server that can proxy video from the capture
pipeline. It connects to the capture pipeline through an appsink that is
created when the capture pipeline is created (we do not dynamically add/remove
this appsink). So when a client requests a proxy stream, the RTSP server adds a
reference to the appsink and sets the callbacks to start receiving data from
the appsink (this is done without changing the state of the appsink). The
uncontrolled nature of this is fine since the RTSP server just wants the latest
stream data as soon as possible. 

Our motivation for this approach was to keep interactions with the capture
pipeline as light as possible, since we do not want to disturb the capture
process. That said, I am not opposed to changing the way we interact with the
appsinks if it is fundamentally wrong :)
I suppose the better approach would be to use a blocking pad-probe, change the
appsink to the READY state, set the callbacks, then set it back to PLAYING?

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