I do apologize to all who helped me in past with my attempts to replace VFW with DirectShow.
This may be too repetitious, sorry.
I got as far as implementing COM and displaying AVI file, but I just cannot get the DirectShow to display video. My “problem” is that DirectShow “SDK” appears to be DIFFERENT with each new MS IDE release. At one point (DirectShow SDK 8.1) it looks as I need to build a base DirectShow library from scratch. But I have not tried that , not yet.
I feel as MS does not understand the basic concept of C language extensibility, at least it looks that way when it comes to DirectShow.
I took a peak on Gstreamer, but it seems dead and without decent support for Windows.
So the main question for now – are there another true = independent of IDE , “C” video libraries out there?
I'll admit I have not looked at CxImage lately, but it was pretty dead years ago.
Thanks for your continuing support.
I am sorry to hear that, but I don't mind even though I tried to give you a few pointers earlier.
Where are you at now with the Visual Studio version?
I am not having any problems with my DirectShow projects on VS2010 even though I cannot seem to convince it to use the paths for v7.1 of the Windows SDK instead of the v7.0A paths.
I am using OpenCV for the actual video frame processing.
The “problem” with OpenCV – it is build on VFW (!) which everybody here discouraged me to use since it is “obsolete”. OpenCV does not use VFW callbacks, as intended, but the image is captured in plain loop which in my opinion defeats the event driven system philosophy big time.
I am still using VC++ because my base application is build on MFC and in VS MFC is either nonexistent or cost $.
I am happy with VC++ MFC. The main reason I started to look for something else to do the video capture is I use VFW directly - single frame capture and it is very unreliable and I get blank screen MOST of the time.
I have not found anybody knowledgeable enough to resolve this reliability problem. I did try to fix it using “number of bytes used” ( I may not be using correct term here) and it is never the same so I cannot tell when the frame “bitmap” is actually empty.
I have not tried “streaming image” instead of capturing single frame.
Just for kicks I may try that approach next.
Thanks for your support.
I was under the impression that OpenCV used DirectShow for capturing. I was just looking at DirectShow with OpenCV[^], which suggests to me that if you do try to set it up like this, you would still have the DirectShow linking problems you have been fighting. Sorry.
I certainly do not suggest you use VFW. The DVR product I have been involved with the past many years, used VFW back when we were running on Windows 98. There were issues, but it did work for capturing video continuously from multiple cameras. Once we moved onto Windows 2000, we had a driver developed for our capture cards and we never looked back at VFW again.
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
I should have told you that I am looking into / using this tutorial series, sorry.
I got sidetracked looking for the DirectShow 8.1 and the GraphEdit application.
Other than that I feel it is most intelligent tutorial on the COM / DirectShow available and I should be able to integrate it with samples from the DirectShow 8.1. (This is where I “discovered” Gstreamer ).
But I feel most of the folks using anything but VC 6.0 do not know about it!
Many thanks for all your help, appreciate it.
Just spent hours downloading and setting up DXSDK June2010 especially advertized as “for XP”!
There is zip about DirectShow in it, except some ready to run “samples”.
I would not call it S(Development)K.
I do understand that companies developing software, been there done that, are run by marketeers who need a DIFFERET name for generically SAME product.
This is main reason why this DirectX 8.1 SDK's specifically its DirectShow part was so hard to find.
But I am really happy with it.
And I really believe that DirectX 8.1 is missed by VS developers and would be a good resource for them, especially after the DXSDK fiasco. Too bad it is indirectly advertized as VC++ “only”.
The DXSDK June2010 takes over 1GB HDD space (not that I care) and for all practical purposes is only good as HELP resource.
DirectShow is one of the worse libraries ever created by Microsoft. If you can afford it, you can cut corners with LeadTools. At one point, years ago, I looked at MediaLooks. It's probably worth a try. There's also Qt's Phonon library (which I know nothing about other than it exists.)
One of my favorite statements was spoken in “theory of information” lecture.
Our elderly professor stated that “ for information to exist, it must be something new, change must be indicated”.
Using this simple definition stating the quality of DirectShow is no longer an information.
The real issue with MS is they just cannot put anything together, mainly because the guy who wrote the first paragraph in this jewel is no longer contracting for them.
I had few “aw s..t” moments with implementing DirectShow, but the worst part is that it is literary scattered in many “SDKs” and for us greenhorns it seldom makes sense.
For example - I ended up rendering the stream and than setting up the display's window.
To me it should be the other way around, but I have not tried that or been successful analyzing why it works that way. And I just hate “it works, but I have no clue why” feelings.
One does not learn much this way , using this “just copy it any pray” approach.
And the other “gripe” - why do so many so called experts write software without using the function / method or whatever COM calls it (!) return values?
Anyway, ISamplerGrabber – here I come.
I have declared one static fstream file under header.h
static ofstream myfile_logs("D:\\Elec...");
myfile_logs << "verify...";
//end of main .cpp
myfile_logs << "calculate Mem";
//end of cal_mem
When i run this program, on opening the log file
i get only
"calculate Mem" text displayed
the control does come to verify_data but the file is not appended or updated with verify.. text
The log file seems to work only for commonFunc.cpp
how to have this log file appended for multiple cpps?
You have created two separate streams, one in main.cpp and one in commonFunc.cpp. Even though they both use the same filename they will not be synchronised. You should create a function that manages the file and does all the logging, and call that from the other parts of your program.
The static doesn't do what you're assuming. In a class it makes it "global" (shared by all instances) but at namespace scope it makes the variable private to the compilation unit. Every file that includes your header has it's own stream.