<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28"> <TITLE>RE: [gst-devel] GStreamer plug-ins for OpenMAX IL, code for review</TITLE> </HEAD> <BODY>  > Hi, > > On 9:38:19 pm 28/11/2006 "Felipe Contreras" <felipe.contreras@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 </BODY> </HTML>