KrisJ

Is it possible to save a filter graph and later recreate it by loading it in from file.

I have two applications. One that configures a device and its relevant cross bars (TV Capture Solution) and a second application should utilise those settings.

Just wondered if this was possible.

Many thanks in advance.


Re: DirectShow Development Saving and Reading Filter Graphs


Re: DirectShow Development Saving and Reading Filter Graphs

Fredrik Bergstrom

Well, I think that he means all the other settings, not just the setup of the Graph. For example settings for a certain filter in the graph.

Most of the filters store the settings in the registry, but I guess that this is custom for each one.

I'm also a bit curious if there would be a way to store for example, tv-tuner settings that was setup in a capture device property dialog.

Otherwise the saving and reading of the exact filter graph works, but the documentation states that this should not be used in end-user applications.




Re: DirectShow Development Saving and Reading Filter Graphs

LGS

Umm, I don't believe that's correct.

While filters may save their defaults to the registry, it would make no sense for them to save the active settings to the registry. How could a filter support multiple instances The filters I've read and the filters I've written don't save anything to the registry except their registration info at install time.

Also, a read of the specs for GRF files (http://msdn.microsoft.com/library/default.asp url=/library/en-us/wcemultimedia5/html/wce50conDirectShowGraphFileFormat.asp) shows that filters can save their data to the file. This matches my own observations that at least some filters DO save their settings to the file.

Obviously not all filters will support this. I believe a filter needs to support IPersistStream if it wants to be able to save its settings, so it could be that the specific tuner the OP is referring to may not save the settings he wants.

As for the docs that say don't use this in end-user apps, there may actually be some logic there. It doesn't take much for the Load of a GRF file to fail. For example, if you plug your capture device into a different USB port than you did when you saved the graph, the Load will fail. And it will most likely fail if you try to copy the GRF file to another computer.

So, will this solution suit the OP's needs It might, depending on precisely what he is trying to do. It is also the only way I am aware of to save graphs. So if this solution doesn't suit his needs, there is no other (simple) way that I am aware of to accomplish what he is after.





Re: DirectShow Development Saving and Reading Filter Graphs

Mike Wasson-MSFT

Yes, that's right.

If a filter supports IPersistStream, it can write its settings to the .grf file.

The reason why .grf files are not recommended for end-user apps, is that loading the graph can fail for so many reasons (your example is a good one). Whatever logic the app used to create the graph in the first place, it is better off using the same logic again. (If loading the .grf file failed, you would need to fall back on that anyway.)

For the OP's scenario, it's probably best to implement your own persistence scheme and save out the settings you need (e.g, crossbar routing info) and restore them manually. Not as elegant but more reliable.

----------------------------------------------------------------------------
Mike Wasson, DirectShow SDK Documentation
This posting is provided "AS IS" with no warranties, and confers no rights. You assume all risk for your use.

(c) 2006 Microsoft Corporation. All rights reserved.






Re: DirectShow Development Saving and Reading Filter Graphs

OrfWare

I'm investigating the IPersistStream interface.
My original idea was to store into some files the status of many capture devices (each in its own graph), then the next time the app wil lstart, read that config files and build anew the graphs starting from the capture device's filter.

After reading this thread,I'm wondering if it would be appropriate in my case to save the whole graphs in .grf files.
The .grf files will not move to other machines, and the case of graphs unable to load because of removed capture devices is acceptable - in that case the application shows a monoscope and requests a user's action (for instance, re-plug a webcam and retry).
Any hint/opinion
Thanks for your attention.




Re: DirectShow Development Saving and Reading Filter Graphs

OrfWare

Boys, I do miss the old mailing list, don't I




Re: DirectShow Development Saving and Reading Filter Graphs

Chris P.

Yes, the forums suck Wink

If you plan on keeping everything on the same machine loading .grf files might be ok. But as stated previously you won't know the reason if something fails. It could fail because the capture device is unavailable, you're out of VMR renderer's, the decoder got unregistered - who knows. But as a quick and somewhat dirty solution, yes it will work.






Re: DirectShow Development Saving and Reading Filter Graphs

OrfWare

Thanks for your answer Chris.

The idea of being working on a "quick and dirty" solution scares me a bit ^___^

The application I'm writing is a multichannel frame analyzer - that is, it uses graphs like capture filter +[color space converter] + sample grabber + null renderer (or similar). Being unable of building a graph is part of the game, since it can happen a camera isn't connected at startup, or something like this. In that case the user is prompted to take an action - plug the camera, for instance. Or unplug it and replug it, as sometimes is needed with certain "top of the line" webcams... After that, the app tries once again to load the graph. Of course, if the problem persists, the user can take an action to build anew the graph (thus losing the stored config).

Saving .grf files wasn't my firs choice. In the beginning the idea was to save elsewhere the parameters of the capture device - name, resolution, framerate etc. - and to re-build the graph each time starting from there.
It worked well with webcams, but with more sophisticated frame grabbers the number of parameters to consider increased, and also I had no chance to access all the grabber features using standard interfaces. So I decided to let the user config the grabber via the filter's and pin's property pages. Then the problem was how to save the state of the grabber, and that brought me to the IPersistStream interface.
At that point I saw no reason not to save the whole graph.

I'm not trying to convince anyone - including myself! - but I'd simply like to know opinions on this design.

Thanks for your attention




Re: DirectShow Development Saving and Reading Filter Graphs

Chris P.

Both methods will achieve the part of the goal in reference to persistant information. The only thing you will miss out on is useful error data when the graph cannot load.