Any DirectShow gurus?
-
Is anyone here a guru of DirectShow? (I'd rather ask some complex questions to someone with a ready answer than wade through Microsoft's absolutely horrible documentation on this.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Is anyone here a guru of DirectShow? (I'd rather ask some complex questions to someone with a ready answer than wade through Microsoft's absolutely horrible documentation on this.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
What are you trying to accomplish? I'm not a guru, but I've done quite a bit.
Chris Richardson
-
What are you trying to accomplish? I'm not a guru, but I've done quite a bit.
Chris Richardson
As fortune would have it, since my posting, several questions were resolved by running a simple test that showed our embedded hardware simply couldn't do what the bosses originally requested. However, we're moving on to plan B, which still leaves some open questions. The main one is whether there is a straightforward method of capturing video straight to memory (no preview)? (A secondary one is how you get the DirectShow BaseClasses and apps to compile with VS 2005 without warnings.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
As fortune would have it, since my posting, several questions were resolved by running a simple test that showed our embedded hardware simply couldn't do what the bosses originally requested. However, we're moving on to plan B, which still leaves some open questions. The main one is whether there is a straightforward method of capturing video straight to memory (no preview)? (A secondary one is how you get the DirectShow BaseClasses and apps to compile with VS 2005 without warnings.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Glad to hear you got part of your problem sorted out :) 1. Assuming you are doing this from code, yes there is. Disconnect the preview pin after rendering the graph but before running it. 1a. Get the filter graph from the capture graph builder. (ICaptureGraphBuilder[2]::GetFiltergraph) 1b. Get the capture source filter by one of a number of methods (IFilterGraph::EnumFilters, IFilterGraph::FindFilterByName) 1c. Enumerate the filter's output pins and disconnect the preview pin. (IBaseFilter::EnumPins). *OR* 1a. Write your own filter that can attach to the preview pin, and make it not do a preview, but instead just keep the media samples in memory or do whatever you want to do with them. 1b. Insert this filter into the filter graph before rendering it, and it will be connected to the preview pin automatically. Note that the preview pin is the only pin that will be connected by default. The capture pin should use the DirectShow convention of a tilde prefix on the pin name to note that it does not want to be connected. I'm not sure how your current setup is doing things, so I'm not quite sure how to answer. 2. I don't have VS 2005, only 2003 and VC6, but I know it can be compiled with 2005 (I helped someone do that). If you are talking about the warnings having to do with functions not having return types and some other ones, just change the code in the base classes, though I suppose you probably already tried this. It's been about a year since I had to do this, so I don't recall everything I changed. I think you also have to change the directory order under Toos->Options->Projects->VC++ Directories->Show Directories for: "Include Files", and make sure either the DX ones come first or the VS ones come first. I can no longer remember the order required for 2005. Here is one link I ran across: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=183304&SiteID=1[^] If you have any more questions or if I wasn't clear about this stuff, feel free to ping me back and I will try to help.
Chris Richardson