[gstreamer-bugs] [Bug 621289] [RFC] Dynamic element factories

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=621289
  GStreamer | gstreamer (core) | unspecified

--- Comment #2 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-06-11 14:10:24 UTC ---
Some links:
http://www.linuxtv.org/downloads/plumbers2008/hverkuil_v4l2.pdf
http://lwn.net/Articles/352622/

benjamin, how does it relate to the state-change or caps?

Lets assume you have /dev/mc0. You open that, enumerate the hardware and you
learn that the device is called HyperCam and has a Sensor, a Scaler plus 5
postprocessing effects. You can queury formats, linking constraints etc.

Now if /dev/mc0 is provided by a usb device it disappear as you unplug it. If
you plug three of them you get /dev/mc0, /dev/mc1 and /dev/mc2 - all of them
possibly with different capabilities.

So if we have a gstv4l2mc plugin, How and when would that register
element-factories to the registry? The gst_plugin_add_dependency() dependency
mechanism can probably be used for tracking /dev/mcX. It means that plugin_init
would open all of them and register all factories. It needs to be robust enough
to handle those disappearing anyway. If a new one is plugged at runtime of an
app, it won't be recognised (maybe the app will have to watch /dev/mc and run
gst_update_registry()). In this case gstv4l2mc_plugin_init needs to be careful
to not re-register existing GTypes ...

-- 
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.