State Change *always* times out, then immediately succeeds!

Sérgio Agostinho sergio.r.agostinho at gmail.com
Thu Sep 17 14:16:24 PDT 2015


I would probably use a mutex that gets unlocked once you receive the state
change message of your bin in the pipeline bus.

1 - lock
2 - add the bin to the tee
3 - lock - this will block, until you get the unlock from the state change
message.
4 - unlock again

Cheers

2015-09-17 22:24 GMT+02:00 Stirling Westrup <swestrup at gmail.com>:

> I have a worker thread which is attempting to add another output bin to an
> output tee on a playing pipeline. When it changes the output bin's state
> (via gst_element_sync_state_with_parent), it gets a TRUE result, and if I
> do nothing else, the newly added output works correctly.
>
> However, if I call gst_element_get_state to wait for the transition to
> finish, it *always* times out, no matter how long the timeout. My Logs show
> that the state change only ever completes AFTER gst_element_get_state has
> returned.
>
> I can only imagine that some sort of lock is being held somewhere which is
> preventing the state change to complete while the worker thread is waiting.
>
> Is there any good way to wait upon the state change that DOES work? I
> really do need to know when the new part of the pipeline is actually in the
> new state.
>
> --
> Stirling Westrup
> Programmer, Entrepreneur.
> https://www.linkedin.com/e/fpf/77228
> http://www.linkedin.com/in/swestrup
> http://technaut.livejournal.com
> http://sourceforge.net/users/stirlingwestrup
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150917/5f7c8fcf/attachment.html>


More information about the gstreamer-devel mailing list