[Gstreamer-openmax] gst-openmax: "Pipeline doesn't want to pause."

[John Bivens]

Hi Felipe,

Felipe Contreras wrote:
> On Thu, Aug 27, 2009 at 06:15:28PM +0200, ext John Bivens wrote:
>> Hello,
> 
> Hi John,
> 
>> John Bivens wrote:
>>> Hello,
>>>
>>> (This is my first post to this list, so please let me know if I
>>> [unintentionally] break any rules...)
>>>
>>> A little background: I currently have some openmax libraries from a
>>> third-party supplier (unfortunately binary-only, non-free software).  I
>>> would like to integrate them into the GStreamer framework using
>>> gst-openmax on an ARM11 system based on Wind River Linux.
>>>
>>> I have cross-compiled the GStreamer framework, various GStreamer
>>> plugins, and gst-openmax.  I have also altered the element_table in
>>> gstomx.c to utilize th third-party libraries and reference the proper
>>> component names.  So far, so good -- I think.
>>>
>>> When attempting to run a fakesrc through one of the openmax libraries
>>> and back out to a fakesink, I get the following error:
>>>
>>> # gst-launch fakesrc ! omx_h264dec ! fakesink
>>> Setting pipeline to PAUSED ...
>>> ERROR: Pipeline doesn't want to pause.
>>> Setting pipeline to NULL ...
>>> FREEING pipeline ...
>> By way of strace and a few debug prints, I have found that our
>> third-party supplier has implemented the OpenMAX specification a bit
>> differently.  It seems the problem with the pipeline not pausing was
>> actually an issue with a parameter being required for OMX_Init().  So I
>> have gotten past this issue and am now working my way through the rest
>> of their changes.  I suppose I should have dug a little more deeply
>> before posting my question.
> 
> Good. Working with OpenMAX IL that's usually the reason for things not
> working as they should: the implementation doesn't follow the spec
> properly. Ideally you would push your vendor to fix their
> implementation, but most probably first you'll have to implement some
> workarounds.
> 
> If you think those workarounds can somehow be safe for other
> implementations please send the patches to the mailing list.
> 
> Cheers.
> 

Thanks for your reply.  I certainly will if manage to get something useful.