gst_element_set_state_func() currently only updates the target state of the element itself, if there is a pending state and it's either smaller/equal than the new state, or the next state is the same as the new state.

These basically mean that currently an async state transition is happening while the new state is set, and we go to the same or a higher state.


Now consider the following scenario:
1) bin is in PLAYING and all child elements know that
2) app sends flushing seek, state is lost
3) bin records that, goes current=next=pending=PAUSED, target still PLAYING and no child elements get notified
4) app sets state to PAUSED
5) gst_element_set_state() only updates the target state of the bin but not the childs (last state change they saw is PAUSED->PLAYING from before)
6) at some point the async state change is finished
7) bin is happy because target=current=pending and all good

If you carefully followed this, the child elements saw as very last state change PAUSED->PLAYING. That is, they think they are actually PLAYING it this point.


For most elements this doesn't matter as PLAYING and PAUSED are the same for them. For rtspsrc it has a very big impact though: the pipeline (and sinks!) are PAUSED after all this, but rtspsrc told the server that we're PLAYING after the seek (because that's all it knows) and the server sends us data until all queues are full and memory is exhausted or other bads things happen.