Preroll
-------

A sink element can only complete the state change to PAUSED after a buffer
has been queued on the input pad or pads. This process is called prerolling
and is needed to fill the pipeline with buffers so that the transition to
PLAYING goes as fast as possible with no visual delay for the user.

Preroll is also crucial in maintaining correct audio and video synchronsation
and ensuring that no buffers are dropped in the sinks.

After receiving a buffer (or EOS) on a pad the chain/event function should
wait to render the buffers or in the EOS case, wait to post the EOS
message.

Several things can happen that require the preroll lock to be unlocked. This
include state changes or flush events.


Committing the state
--------------------

When going to PAUSED and PLAYING a buffer should be queued in the pad. We also
make this requirement for going to PLAYING since a flush event in the PAUSED
state could unqueue the buffer again.

The state is commited in the following conditions:

 - a buffer is received on a sinkpad
 - an EOS is received on a sinkpad.

We require the state change to be commited in EOS as well since an EOS means
by definition that no buffer is going to arrive anymore.


Unlocking the preroll
---------------------

The following conditions unlock the preroll:

 - a state change
 - a flush event

When the preroll is unlocked by one of these events, a return value of
GST_FLOW_WRONG_STATE is to be returned to the peer pad.
 

Result of the preroll
---------------------

After the preroll is unlocked, the element can be in the following states:

 - in a state that disallows it to process the data (flushing, pad inactive)
 - in a state that allows it to process the data.