[Gstreamer-openmax] Discussion on the hardware accelerator solution in GstOpenMAX project.
Victor Manuel Jáquez Leal
ceyusa at gmail.com
Tue Aug 5 07:14:01 PDT 2008
Wow! quite clever
I'm starting to like the implementation... :D
On Tue, Aug 5, 2008 at 4:00 PM, Frederik Vernelen
<frederik.vernelen at gmail.com> wrote:
>> 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.
More information about the Gstreamer-openmax