<div dir="ltr"><div>Hi Tim,</div><div><br></div><div>Now things make a lot more sense to me. I totally missed that properties are only supposed to be changed in the null state.</div><div>I will add the appropriate locking code to my plugin.</div><div><br></div><div>Best regards,</div><div>Alexander<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 7, 2022 at 3:44 PM Tim-Philipp Müller <<a href="mailto:t.i.m@zen.co.uk">t.i.m@zen.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Mon, 2022-03-07 at 13:23 +0100, Alexander Hedges via gstreamer-devel wrote:</div><div><br></div><div>Hi Alexander,</div><div><br></div><div>Short version: GStreamer elements don't really care about main loops and application threads, you can have as many application threads as you like, and you can do GStreamer things from multiple application threads if you must.</div><div><br></div><div>From a GStreamer element point of view it's mostly about "streaming thread" vs. "other threads".</div><div><br></div><div>For a plain filter element the streaming thread would typically be the thread of whichever element upstream is driving the current pipeline branch, e.g. a source element or parser/demuxer in pull mode or a queue/jitterbuffer element, for example.</div><div><br></div><div>GStreamer elements have some locking that is taken automatically, in particular there is a "stream lock" on each pad that is taken automatically when a buffer is pushed into an element/onto a pad, or a serialized event (like CAPS, TAG, SEGMENT, STREAM_START, FLUSH_STOP).</div><div><br></div><div>That automatically makes sure, for example, that an element is not going to reconfigure itself based on a CAPS event in a sink pad event function while it's at the same time processing a buffer in the same pad's chain function.</div><div><br></div><div>For properties, the locking in our code base tends  a bit all over the place. By default element properties can only be set when the element is in NULL state, which means no streaming is going on and all pads are flushing so would just drop any data or events that  come in. Because of that, often there is no locking for such properties, since it's not really needed, and setting these properties while the element is up and running would be a programming error, although we don't strictly enforce that.</div><div><br></div><div>Properties that can be changed at runtime usually have locking in place to make sure they're not changed while the streaming thread is using them.</div><div><br></div><div>Hope that answers some of your questions.</div><div><br></div><div>Cheers</div><div> Tim</div><div><span></span></div></div>
</blockquote></div>