Monitor graph objects by creating in wrapper COM objects for graph and filters [further suggestions welcome]

[GoogleCodeExporter]

I'd like to have this feature in the programm:

Optional (enabled in Options menu) ability to create wrapper objects for filter 
graph and filters within the graph to log calls to the graph and filters 
objects (perhaps in an analyzer style window).

The monitoring filter graph object would wrap the normal filter graph object 
via COM aggregation. When filters are added to the graph each of the filters 
would be wrapped in a monitoring wrapper COM object via COM aggregation and the 
wrapper would be inserted into the graph.

The graph and filter wrapper objects would expose a custom internal COM 
interface to control logging. The wrappers would write logging information to a 
central log to be viewed later/live by the user. Would need to experiment to 
find a method of logging which only adds manageable overhead to performance and 
locking contention to graph operations.

Would need to code this carefully to avoid deadlocks as graph and filter calls 
can occur on many different threads. 

This feature would definitely need to be optional as it will cause performance 
overhead.

The feature is important for me because:

Detailed debugging of graph and filter problems.

The feature is important for other users because:

Detailed debugging of graph and filter problems (for experienced rather than 
new DirectShow users).

Original issue reported on code.google.com by mike.cop...@gmail.com on 27 Nov 2013 at 5:05

[GoogleCodeExporter]

That would be an awesome features. I think with an SQLite-InMemory DB the 
overhead and threading issues should be OK. Wrapping the FilterGraph should be 
no problem, but would a filter-wrapper, also wrap the pins?

Original comment by cgraef...@gmail.com on 27 Nov 2013 at 10:06

[GoogleCodeExporter]

The SQLite angle sounds interesting though I'm not familiar with its 
performance and threading characteristics.

I don't think this approach could be used to wrap pins (at least not in all 
instances). Filters usually create pins directly rather than via COM calls. In 
most cases when pins call their parent filters they do it via direct reference 
rather than using COM so those filter calls couldn't be logged either.

By contrast filters are added to the filter graph, and filters informed of 
their containing graph with a COM call that could be intercepted.

I haven't thought through all the angles on this yet but thought I'd put the 
idea out there and think on it some more. It could turn out to be impractical.

Original comment by mike.cop...@gmail.com on 27 Nov 2013 at 11:30

• Changed title: Monitor graph objects by creating in wrapper COM objects for graph and filters [further suggestions welcome]

[GoogleCodeExporter]

Another useful possibility enabled by closer monitoring: 

Color connection lines according to the thread handle used for streaming to 
show how many streaming threads are operating in a given graph. Other useful 
information - how many samples have been received, samples/sec.

An alternative way of achieving this would be to use an internal filter that 
saves the thread handles used to deliver samples (and perhaps other sample 
information) so it can be queried and displayed by the application.  Perhaps 
this function could be added to the time measure filter. The thread handle 
could even be displayed in the text of the the time measure box itself and 
refreshed periodically (along with frame rate perhaps).

To make a filter-based version of this feature practical there would need to be 
a quick UI for of inserting this or other filters in every filter connection in 
the graph that doesn't already contain it.

It would be good if there were some visual queues for analysis filters like the 
analyzer and time measure filters to make the graph easier to read when there 
are lots of analysis filters. Perhaps they could be displayed in a different 
style of box - smaller box, less prominent border, more muted background color. 
At the moment there are only 4 different filter background colors - 
unknown/unconnected, standard, WDM and DMO.

Original comment by mike.cop...@gmail.com on 3 Dec 2013 at 4:59

[GoogleCodeExporter]

I used to do a similar trick in past to analyze specific filter behavior (not 
just wrapping all filters at once and gathering their runtime stats all 
together). 

The way to do it is to make a sort of a wrapper filter implementing not only 
main filter interfaces, but also pins as well. COM aggregation is insufficient 
here to cover the filter entirely and be a man-in-the-middle for all filter and 
pin calls. That would be special filter impementation also taking care of pins. 

The culprit here is that one has to cover pin and also impersonate peer pins to 
capture their calls. For example, when real pin is connecting to another pin, 
this magic filter needs pass a wrapper interface for the pin it covers and then 
on the other side when it receives peer connection pin interface - it needs to 
be either already wrapper interface of the peer filter, or an on-the-fly 
wrapper of the real peer pin interface to be passed to internal real pin. That 
is, it is a bit tricky and while doable for simple filters like transform 
filters, I am afraid it gets way more complicated when it comes to filters with 
dynamic pins, with non IMemInputPin pins like those with DXVA, with pull model 
source pins, with sink pins - almost everything needs to be wrapped.

Original comment by rylt...@gmail.com on 7 Jan 2014 at 9:27