[Gstreamer-openmax] Discussion on the hardware accelerator solution in GstOpenMAX project.

Frederik Vernelen frederik.vernelen at gmail.com
Tue Aug 5 07:00:26 PDT 2008


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20080805/c25844ce/attachment.htm>


More information about the Gstreamer-openmax mailing list