[gstreamer-bugs] [Bug 621289] [RFC] Dynamic element factories
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Mon Jun 14 14:20:10 PDT 2010
https://bugzilla.gnome.org/show_bug.cgi?id=621289
GStreamer | gstreamer (core) | unspecified
--- Comment #12 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-06-14 21:20:06 UTC ---
(In reply to comment #11)
> you should not start probing hardware in the plugin_init IMO. Better do it like
> we do everywhere else: unconditionally register elements with a defined API
> that may or may not work depending on the hardware that is available.
Then we need to keep this open until we have a better idea. You cannot register
such elements, as there is no defined list of possible ones. The hardware the
v4l media controller API targets is a combination of capture hardware + a image
signal processor. Such ISP have loadable firware images (those might be static
and/or monotitic). Features realised on the ISP can be almost anything. In
practise the theoreticaly available feature don't change often. Thus such a
plugin could localy cache and aggregate the features. plugin_init would only
rescan if it finds new nodes. Having features registererd to gstreamer and the
device beeing unplugged can be gracefully handled. The local cache would
probably need an expiration policy to handle hardware that is never replugged.
Still this would mean probing hardware in plugin_init (like we probe ladspa
plugins in plugin_init).
--
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the Gstreamer-bugs
mailing list