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

[Sérgio Agostinho]

Why are you going for GST_MESSAGE_ASYNC_DONE instead
of  GST_MESSAGE_STATE_CHANGED?
Notice the example they give in the documentation
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstMessage.html#gst-message-parse-state-changed
You have access to the object's (unique) name.

Cheers

2015-09-18 18:48 GMT+02:00 Stirling Westrup <swestrup at gmail.com>:

>
>
> On Thu, Sep 17, 2015 at 5:16 PM, Sérgio Agostinho <
> sergio.r.agostinho at gmail.com> wrote:
>
>> 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
>>
>
> That's not very practical. The "Async Done" message that gets to my
> bus-handler just has "pipeline" as its source, so I have no idea WHICH bin
> has finished a state change. The reason I'm using worker threads to modify
> the pipeline is because I can easily be adding 4 or 5 new output legs at
> the same time, in parallel.
>
> It looks like I could set the enclosing bin to have the message-forward
> property, but then I would need to do it for several other enclosing bins
> as well, and the final GST_MESSAGE_ELEMENT I would get would have all
> relevant info buried 3 or 4 layers deep. Is there an easier way?
>
>
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>
>
> --
> 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/20150919/f80c452e/attachment.html>