[gst-devel] GStreamer plug-ins for OpenMAX IL, code for review

[Contreras, Felipe]

> Hi,
> 
> On 9:38:19 pm 28/11/2006 "Felipe Contreras" <felipe.contreras at gmail.com>
> wrote:
> 
> > >  Next problem is the mp3-decoder does not work. Apart from not
> > >  finding the decoder, the plugin should also error out here (abort
> > > the processing).
> > >  $ gst-launch filesrc location=song.mp3 ! omxdec_mp3 ! omxsink_alsa
> > >  Setting pipeline to PAUSED ...
> > >  Component OMX_Mp3Decoder not found, sorry...
> > >  Pipeline is PREROLLING ...
> > >
> In gstomxaudioenc.c the mp3encoder is hardcoded to be
>   .omx_component = "OMX_AmrEncoder",
> but from my openmax registry the name appears to be "OMX.st.ffmpeg.mp3dec".
> 
> $ cat $HOME/.omxregistry
> OMX.st.alsa.alsasink ==> /usr/lib/omxilcomponents//libomxalsa.so
> OMX.volume.component ==> /usr/lib/omxilcomponents//libomxvolcontrol.so
> OMX.st.ffmpeg.mp3dec ==> /usr/lib/omxilcomponents//libomxffmpeg.so
> 
> I have the impression the wrapper contain a hard-coded list of
> omx-components they wrap, regardless of wheter those components are
> available or not. Wouldn't it be possible to do this dynamically?

Actually the wrapper doesn't know anything about the components; the client, in
this case the GStreamer plug-in, is the one that has the hard-coded component
names.

I was thinking on making a property on the GStreamer elements, it's not
complicated at all.

> > >  This even crashes :(
> > >  $ GST_DEBUG="*:2" gst-launch videotestsrc ! omxenc_h263 !
> > >  ffdec_h263 ! xvimagesink
> > >  0:00:00.222504000  9811 0x8051a18 WARN    GST_PLUGIN_LOADING
> > >  gstplugin.c:261:gst_plugin_register_func: plugin
> > "/home/ensonic/buzztard/lib/gstreamer-0.10/libgstbml.so" failed to
> > >  initialise Setting pipeline to PAUSED ...
> > >  Component OMX_VideoEncoder not found, sorry...
> > >  Pipeline is PREROLLING ...
> > >  0:00:00.665092000  9810 0x81f2be8 ERROR         omx_videoenc
> > >  gstomxvideoenc.c:792:gst_gomx_videoenc_sink_setcaps:<omxench2630>
> > >  bad resolution 320x240
> > >  0:00:00.665316000  9810 0x81f2be8 WARN               basesrc
> > >  gstbasesrc.c:1614:gst_base_src_loop:<videotestsrc0> error:
> > >  Internal data flow error.
> > >  0:00:00.665430000  9810 0x81f2be8 WARN               basesrc
> > >  gstbasesrc.c:1614:gst_base_src_loop:<videotestsrc0> error:
> > >  streaming task paused, reason not-negotiated (-4)
> > >  ERROR: from element /pipeline0/videotestsrc0: Internal data flow
> > >  error. Additional debug info:
> > >  gstbasesrc.c(1614): gst_base_src_loop (): /pipeline0/videotestsrc0:
> > >  streaming task paused, reason not-negotiated (-4)
> > >  ERROR: pipeline doesn't want to preroll.
> > >  Setting pipeline to NULL ...
> > >  Segmentation fault
> >
> > Thanks for pointing that out. In fact the mp3 decoder is in early
> > stages of development and is probably the only one that is not
> > properly working with the TI implementation. So I guess it also
> > wouldn't work with the omxil one.
> >
> > But yes, it should not crash if the component doesn't exist. Our
> > wrapper still needs error handling, better logging and other important
> > things.
> 
> Yes I noticed that I don't have those openmax codecs you wrap, so it should
> not register any of those elements.

It might be possible to do that, but not if we retrieve the name of the OpenMAX
component from an element's property.

> > >  I think its a good start, but needs some work on the robustness.
> > >  Now we need a decission about where development should take place?
> > >  Would a freedesktop.org cvs repository be okay for ti?
> > >  If so shall we import the current sources? Or do you use CVS
> > >  internally and we could use that as a basis?
> >
> > I agree.
> >
> > We could use any repository and import the current sources. Personally
> > I would prefer git, or Subversion, but any would do. Do you guys plan
> > to move from CVS to something different?
> >
> I think svn would be possible on freenode.org. The gomx project could also
> become a sf.net project.

We would prefer an account on the GStreamer repositories, just like gst-ffmpeg,
but if that's not possible we will setup it in SF.

-- 
Felipe Contreras
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20061204/2a418880/attachment.htm>