are gstreamer elements thread safe?

[Farkas Levente]

hi,
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 th pipeline and bus), then the elements behavior are
deterministic and proper? 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.
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?
while in 0.10 the caps renegotiation is not working how does it planed
in 0.11/1.0? 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.
regards.

--
  Levente                               "Si vis pacem para bellum!"
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

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


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel