[Bug 678402] Device discovery/listing replacement for GstPropertyProbe

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=678402
  GStreamer | gst-plugins-base | git

--- Comment #56 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2013-11-22 01:38:42 UTC ---
Changes since last patchset:
- fixed Since: docstrings
- Replaced GPtrArray with GList in API
- fixed gst_registry_chunks_{load,save}_feature() to use 'dmf' instead of 'tff'
- in gstdevice.c: moved include gst_private.h before any other glib/gst header
- renamed gst_device_get_device_name to .._get_display_name(), also renamed the
matching property to "display-name"
- documented that _probe never blocks
- GstBus in Monitor and GlobalMonitor moved to private struct
- replaced gst_device_monitor_device_added/removed with add/remove and keep
list in GstDeviceMonitor itself. Only call _probe in the subclass if its not
running.
- Renamed gst_device_monitor_probe() to _get_devices(), same for the global one
- Now parenting the GstDevice to the DeviceMonitor that created it while they
are kept in the list.. But not for those that are from _get_devices (since the
enduser owns them). I guess for the user it's the same, they just unref them
all.
- Now keeping track of start/stop count in GstDeviceMonitor, so it can be
shared. Need to call _stop() as many times as _start() was called to really
stop
- Separated the device message into device-added and device-removed
- Made GstDeviceMemory into a singleton, the GstDeviceMonitorFactory already
returns the same one
- Don't emit all possible devices on _start(), the user should do _start();
_get_devices() to get the initial ones

The metadata keys are actually used, they are used like for GstElementFactory.
I'm actually reusing the GstElement keys. Should we make a second copy of the
defines?

The more I think about it, the more I think that having separate "tags" instead
of a path or hierarchy for the "klass" system is a good idea. Using flags
though probably isn't, I guess matching strings should be enough. So
pulsemonitor would declare "Audio/Source/Sink", but the GstDevice it would
produce would only have "Audio/Source" or "Audio/Sink", could even have
"Audio/Sink/Headphones" vs "Audio/Sink/Speakers". We should define a canonical
list of tags in the doc. We'd probalby have a DVD drive be "DVD/CD/Drive" and a
Bluray drive be "DVD/CD/Bluray/Drive", but the disk would only be
"CD/CDAudio/Audio/Disk" or "CD/CDROM/Disk" or "DVD/DVDVideo/Video/Disk" ? The
drive monitor might have
"CD/DVD/Bluray/Disk/Drive/CDROM/CDAudio/Audio/Video/etc/etc/etc".

The "global" monitor would then have a  _set_classes_filter(gchar*) function.
One could pass for example "Video/Disk", and then it would return any GstDevice
that's a DVD or Bluray or CDVideo.

I'm not sure what to for the case where we have both pulsemonitor and
alsamonitor, in that case, we probably only want one monitor loaded. Maybe
using ranks? So we would order monitors by rank and only picks those with the
top rank, and only go to the second rank if _start() failed for every top-rank
ones, etc. And maybe somehow let the application select which monitors go into
the global one?

Left todo:
- New name for GstGlobalDeviceMonitor
- Write doc
- Implement device class filtering (tags or hierarchy?)
 - Merge source and sink monitors
- Add listing to gst-inspect
- Add device listing/monitoring command-line tool

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