[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 #50 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2013-11-07 13:03:28 UTC ---
> If we want to add additional information later, we can always create
> subclasses, I don't think this is required now.

Agreed.


> > medium status / type on a disc drive, mount/unmount or eject operations.
> > video source or sink one might want to query available video norms (..)
> 
> Most of those things could just be properties? Operations like eject might make
> sense, but nothing prevents us from adding GstDevice subclasses later.

Yeah, but then you have properties on anonymous GstDevice subclasses that can't
be inspected in gst-inspect, and will be documented in weird locations in the
docs, if at all. But yes, we can figure that out later.


> We could make the "klass" into a "path".. Use use a g_str_prefix() has a
> filter. So we could have klasses like "/Source/Video/Camera/V4l2/" which would
> match "/Source/" or "/Source/Video/". And I guess we could put the klass into
> both the filter and the gstdevice itself..

Right, that was the idea. 


> That clashes a bit with your other suggestion.. if you have a single monitor
> for both pulsesrc and pulsesink, what klass would it be ?

We could attach multiple paths/klasses to a monitor, or just make it a
comma-separated list of paths/klasses.


> I guess if probing is impossible it might return some kind of template caps. I
> think even probed caps can possibly be a superset of what is actually possible
> right now.

One might want to differentiate the two cases, because applications will likely
assume that if they use a capsfilter that is compatible with the probed caps,
stuff will work. Can still figure this out later of course, was just wondering.


> > we should get rid of that stuff (along with the long name, description
> > and author) until we have a use case for it IMHO (KISS).
> 
> I'd like to keep long name/desc/author so we can add an option to list monitors
> to gst-inspect. But metadata can do, I guess we can re-add it later.

We can list them in gst-inspect even without a long name, description or
author. Those things only make sense for elements IMHO, where you want to show
things to users in a GUI and have them select them. Anyway, not so important.


> I'm not a super fan of the name. I don't think Probe is good either (as it's
> not only probing!). Maybe the Global one could be a GstAggregatedDeviceMonitor
> ?

Agreed that DeviceProbe is not very good either. I prefer Global to Aggregated.
I suppose GstDeviceMonitorMonitor is out too ? ;-) Will see if other people
have some ideas.


> > Making it a singleton doesn't mean you can't have individual filters.
> 
> You mean have a:
> GstBus * gst_singleton_global_device_monitor_add_filter(caps, klass,
> filter_func, user_data); ?
> This kind of API makes it harder to extend the filtering later. If the
> Aggregator is an object, then more functions/properties can be added later for
> more types of filtering.

One could make a filter helper object if you think we need to make filtering
more extensive in future. I suspect in practice apps and libraries will just do
any additional filtering in their own functions anyway though. You could also
require the caller to pass/set a bus instead of returning one (not that that's
directly related).


> I'm not sure what the benefits of having a singleton are ?

It just seemed the most natural setup to me. The benefits are that you only
ever have one monitor instantiated for each API type, which means you avoid
unnecessary threads/connections/overhead when you have multiple libs and the
app all monitoring devices. I'm not married to the idea though.


> Why have a single one? Maybe it makes sense to have each user create it's own
> "monitor aggregator" with appropriate filters, but that the actual monitors
> each be singleton that is running as long as any aggregator is running.
> 
> It might make sense if each monitor is a singleton though, if we only do the
> filtering in the "global" one. Maybe this could be done with some help from the
> factory (having a flag that makes the factory always return the same one if
> possible).

Right, that would achieve the same.


> You mean have one monitor for sinks and sources ? I could be convinced of that,
> but it doesn't match well with the hierarchical model well as mentioned
> earlier.

See remarks above, I don' think a monitor needs to have only one single
klass/path, it can cover multiple ones.


> > > >  - what about medium/disc inserted/ejected?
> I would have the disk show up as it's own GstDevice, of a type different from
> the drive device.

I think that's a bit weird, but I guess it would work.

> I think GstDevice objects property should never change. Changing properties
> means applications need to remember the old ones and do diffs, and that's painful.

Why does it mean apps have to remember the old ones? Usually they will just
update their internal state to the new one and not care about the old value,
no?

Not sure if the goal of device object properties never changing will be
practical, but we can see how it goes I guess.


> > > >  - is 'operation' the right word here? maybe it should be DEVICE_EVENT ?
> > > (...) 
> Yeah, maybe we need a better name than operation or event.

Still think making it separate message is easiest, but maybe we can find a
better name too.

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