are gstreamer elements thread safe?

[Tim-Philipp Müller]

On Sun, 2011-07-03 at 11:40 +0200, Farkas Levente wrote:

> while we use many elements, pipelines ans threads in our program we'd
> like to know that gstreamer elements are thread safe by design? i mean
> if we've a running pipeline and we set one element's properties from
> another thread (not the pipeline and bus), then the elements behavior are
> deterministic and proper?

It very much depends on the exact element(s) and the properties, there
is no general answer.

There is a (fairly new) flag though to mark properties that can be
changed in PLAYING state. If that is set, you can be fairly sure it's
fine.

e.g. gst-inspect theoraenc will show:

  bitrate : Compressed video bitrate (kbps)
            flags: readable, writable, changeable in NULL, READY, PAUSED
or PLAYING state
            Integer. Range: 0 - 16777215 Default: 0 Current: 0

Elements only care about streaming thread and 'any other thread', so
there's nothing special about your setup. The application thread is
almost always 'any other thread'.

It's generally not hard to fix up these things if you discover an
element that doesn't support this properly, patches welcome.


> what happened if the property setting happened during the element
> process in it's chain function? if it's use it's properties in the
> chain and it's value different in the begining of the chain as in the
> middle of the chain? eg. set vorbisenc quality while it's encoding a
> frame? because if the elements itself is not thread safe we can't do
> anything from outside (ie. can't lock/unlock) other than pause and play
> the stream again which is many case not possible.

You should fix the element then.


> and the same question arise when we develop our own element should
> we've to care about the property settings and chain function thread
> safety?

Yes, you should.


> while in 0.10 the caps renegotiation is not working

Don't think this is true as a general statement. Whether caps
renegotiation works or doesn't, depends a lot on the elements involved
and what upstream elements do or don't do. Without more context, it's
hard to say whether it should work in your case or not.


> how does it planed in 0.11/1.0?

Wim's "GStreamer 0.11 status" e-mails to the mailing list provide an
overview. The design docs in the 0.11 branch have more details.


> since if we can set the caps during the play state the same problem can
> happened all over the pipeline. or is there any global locking
> mechanism for this? thanks in advance.

No idea what you mean by this.

 Cheers
  -Tim