> 1) AFAIK: in order that a pipeline could change from prerrolling to
> playing, the sink must receive at least one buffer. If you have an OMX
> sink in tunnel with a previous element the pipeline will never leave
> the prerolling state.

Well, it _does_ leave the pre-rolling state, I don't know why. I'll have
to investigate.
 
At the moment it does preroll because we return statechange_succes when the sink is requested to move to paused state. (in stead of returning the required statechange in progress). This is not correct though (prerolling done is stated too soon),
the correct idea was that the first arriving buffer in the omx sink would be a marked buffer that would trigger an event that lets GST know the prerolling completed. Unfortunately, its not in the code yet. But its similar to how we deal with the EOS event with a tunneled OMX sink.