gst_element_set_state failure and bus messages

[Carlos Rafael Giani]

On 08/08/2014 12:19 AM, Tim Müller wrote:
> On Tue, 2014-07-29 at 11:50 +0200, Carlos Rafael Giani wrote:
>
> Hi,
>
>> I saw something strange the other day with state changes with GStreamer
>> 1.2.0. During a test, I intentionally used filesrc with an invalid
>> filename. As expected, the state change from READY to PAUSED failed. As
>> part of the cleanup operation that followed, I called
>> gst_element_set_state() again, this time setting the pipeline to the
>> NULL state. This returned GST_STATE_CHANGE_SUCCESS , so the state change
>> finished immediately. Perhaps the pipeline is automatically set to NULL
>> if a state change fails?
> No, the pipeline is not automatically set to NULL state if a state
> change fails.
>
>> Either way, I also noticed that the bus watch did not get any kind of
>> message that the state was changed to NULL.
> This is expected default behaviour. When you set the pipeline to NULL
> state, the pipeline's bus gets set to flushing, which means all messages
> on it will get discarded, including the 'state-change from READY to
> NULL' message.
>
>> This caused problems, because some final cleanup operations rely on
>> seeing a state change to NULL in the bus watch.
> You can set the "auto-flush-bus" property on the pipeline to FALSE, in
> which case you will get to see that message. You just need to take care
> to clean up any pending messages on the bus yourself as needed.

Ok, thats fine, I'll keep the automatic bus flush on. I just needed to 
know that this behavior is by design, so I can construct my application 
accordingly.

>> Is this some kind of exception? If state change fails, it is implicitely
>> set to NULL, and no state change messages will occur? Or perhaps this is
>> just a bug? I will test with a newer GStreamer version today.
>> Also, if a state change finishes immediately (that is, returns
>> GST_STATE_CHANGE_SUCCESS instead of GST_STATE_CHANGE_ASYNC), will it
>> still produce bus watch statechange messages?
> No, expected behaviour if I understand you correctly.
>

Okay, but what about set_state() returning immediately? I mean, in 
general, if the pipeline is in state A, I switch it to state B using 
set_state, and it returns SUCCESS, the state change was completed, 
correct? I mean, it is not progressing in the background, otherwise 
set_state() would have returned GST_STATE_CHANGE_ASYNC . But if it 
returned SUCCESS, will there still be a message on the bus? If not, I 
will handle the SUCCESS case separately. This is important to ensure 
that no state change is missed.