[gstreamer-bugs] [Bug 350477] [Registry] Provide a way for plugins to delegate the 'changes' behaviour

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=350477

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #22 from Felipe Contreras  2008-02-27 14:26 UTC -------
The OpenMAX case is a little different. I haven't really decided which is the
best way to approach this, but probably it will stay in the current state.

Right now different OpenMAX IL implementations can be loaded at run-time, and
each one of these can have different components. IMO it would be overkill to
try to map all of the possible omx components, so instead what I'm doing is
creating elements per standard component. These standard components are defined
in the spec, examples include mp3 decdoder, h264 encoder, vorbis decoder, etc.

However, some mechanism to map GStreamer elements should be devised, for
example:

gst_name=omx_mp3dec_mad
gst_class=GstOmxMp3Dec /* this can be guessed with OpenMAX IL facilities. */
omx_name=OMX.st.audio_decoder.mp3.mad
omx_library=libomxil.so.0

In this situation gst-openmax would require the registry to be updated when the
previous information changes. The omx_name/library are only useful to
gst-openmax, and gst_name/class are needed for GStreamer registry.

There are ways this how this could work but those are more esoteric.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=350477.