Event processing in the filter embedded in the graph

[Vittorio]

Hello,
can the GrapheditPlus help to automate the creation of the event handlers as well? The querying of the available events and properties would be a great addendum to querying of interfaces.

[Dee Mon]

Hi Vittorio,
In current version you can see event log for each graph. However I don't see how one could query of available events. Interfaces like IMediaEvent can tell if some events already happened and what they are, but how to know what events can possibly happen in the future?

[Vittorio]

Of course you don't have any chance to query the events implemented by a concret filter. But you still could dump upon request some categories of it. BTW great improvements would be:
1. The possibility to search for some specific filter e.g. by it's friendly name or other criterion like media formats (can be queried) or media types negotiable with the next filter pin
2. If I try to render the pin in a filter which requires that another pin is connected first program reports "running out of memory" error. You could offer in such cases at least a null-filter for the pin which must be bound first and then try to render another pin. Easy to reproduce with any filter offering both "Capture" and "Still" pins. The error happens if I try to render the "still" pin ( I'm aware that this order in a program code would be wrong) before the "capture"-one. If I first attach the "capture" to a null-filter everything works fine.
3. The code you generate is partially incompatible with the Visual Studio 2008, The main procedure in console applications is now called e.g. _tmain.

I'm experienced another problem with teh generated code.  I create the trivial combination of WEB CAm -> AVI decoder -> Renderer. Thsi is teh default one when asking for rendering the Capture-pin of the camera. For whatever reasons the catching of media events  in the application window freezes the display. The picture appears for a couple of second and goes again. Any idea?

[Dee Mon]

But you still could dump upon request some categories of it.

How?

Thanks for the suggestions!
#1 is quite reasonable and will be implemented.
#2 is very filter-specific, I'm not sure we should generalize this behavior.
#3 will be changeable via code templates.

Sorry, no idea about your webcam problem. This might be cam-specific..

[Vittorio]

The point 2 is the documented behaviour, s. http://msdn.microsoft.com/en-us/library/ms787483(VS.85).aspx, the pin category PIN_CATEGORY_STILL

I've detected one problem. If I set up media type for a pin I don't have any chance to set it back again to ANY unless I restart the graphplus. This can lead to the situation where the filters can't be connected until I restart teh programm and recerate the graph. Or have I overseen something?

[Dee Mon]

Thanks for the link!

As for mediatype setting problem, you're right, there's no way now to unset it back except deleting this filter and inserting it back (this is easier than restarting whole app). I should add "any type" to the list of variants.

[Vittorio]

Would be very helpful. This would mean no real development effort for you.
A couple of improvement proposals more:

• A great feature would be the automatic rebuild of the filter list on remove or add of new relevant PnP devices. The same problem: to involve a new device I must restart the programm
• After you have used the Intelligent Connect ("Render Pin" functionality in the programm) you often get filters you don't have any idea about. Would be very helpful to expand and synchronize the filter list automatically on click at this filter. The developer could then find out to which category this filter belongs and where to look for it next time.
• Very helpful would be the option "IAMStreamConfig::GetFormat" for determining of what format has been negotiated with the next filter in the chain.
  
• Great help would be embedding of all options changes like "format type" made inthe graph later in the generated program code. In some cases the format change can be required to be able to enforce some preferred forms of graphs generated by Intelligent Connect functionality.

[Dee Mon]

Thanks again! You're generating very good ideas!
#1 & #2 are surely going to be implemented.
#3: since there's the next filter, you can just click on the connection and see its format. Isn't it enough?
#4: SetFormat actions are already reflected in the generated code in the current version. Am I missing something?

I guess you should expect to see a new version next week.

[Vittorio]

Thank you for compliment 
3 and 4 you are right. I'm blind. The implementation is absolutely sufficient.
I've detected the reason of the problem I described in one of my previous posts. The screen gets refreshed a couple of times only and remains blank after that.

We are actually missing a message pump. The thread that creates the video window must dispatch the window messages. Since the default window is created for us by the video renderer automatically according to the templates you are using the thread is in that case the one calls the graph manager to do it.

IMediaEvent::GetEvent() blocks without dispatching anything and then goes Sleep(). But for examplee the IMediaEvent::WaitForCompletion()
dispatches the messages. Otherwise you will need to wait and dispatch yourself using a message- or event-based approach:

http://msdn.microsoft.com/en-us/library/ms787243(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms787582(VS.85).aspx