VB6 - DirectShow WebCam Minimal Code

There are a number of possible APIs in Windows for previewing and capturing from webcams. One of the most popular for its broad support on Windows versions and its relative ease of use when requirements are simple is the AviCap/Video for Windows API.

But a downside of VfW is that the driver model Windows uses to support video capture devices changed after the end of 16-bit Windows (Win3.1, etc.). This means several things, but most commonly frustrating is that instead of mapping multiple webcams as device 1, 2, ... 9 they work through a compatibility layer thats maps one of them as device 1.

This can make selecting the webcam to use difficult to impractical. And using more than one webcam at a time doesn't seem possible.

The usual answer has been: "Use DirectShow instead of VfW."


DirectShow vs. VB6

One problem with using DirectShow is that Microsoft seemed to have lost enthusiasm after providing only a partial implementation. The parts of DirectShow (also called ActiveMovie) we did get a VB6-friendly API for are implemented in the Quartz.dll which should be part of Windows in any recent version (and perhaps even back to most "late" Windows 95 versions like 95B or OSR2.x).

You can still do a lot of things using just what we have, but the finer points of using DirectShow in VB6 require a 3rd party DLL to wrap a few more DirectShow C++ interfaces.


This "Minimal Approach" to VB6, DirectShow, and WebCams

What I have done here is to try to stretch things as far as I could manage.

Here is what you can do:

• Choose among your webcams and display a live preview image.
• "Snap" and display a still image from the webcam feed.

Here is what you can't do:

• Get a "friendly" list of just the usable webcams.
• Control the capture resolution/dimensions or other capture settings or even raise the built-in dialogs to let the user do so.

The Demo

What I wanted to accomplish was to see how far I could get with the two tasks we can perform without using any 3rd party libraries.


Form1

This is the main UI Form, which uses Form2 as a dialog when requested via its menu ("Add new camera...").

There is a lot more code there than I'd like that does nothing except manage the menu. As you add cameras they are added to the menu. There is also code there to load and save "settings" which include the index of the selected camera and list of added cameras by name.

Basically a lot of UI-management code which I hope doesn't obscure the DirectShow-related logic itself.

The other ugly hunk of code in there is the BuildGraph() function, which is a small interpreter of a sort that processes a "filter script" and a "connection script" to add the necessary filters and connect them to create a webcam preview graph for DirectShow.


Form2

Since I can't find any way to find just the list of usuable webcams, the user has to pick them out from among the full list of available "filters" (as they are called)! Not practical at all for a real application, but it works for a test/demo program.

That's what Form2 in the demo Project is for, a dialog from which to pick new cameras.

Note that your camera might appear there once, twice, or even three or more times depending on how many "filters" of different kinds it supports. Just pick any of them, the demo program will just use the name and sort it out later.


Module1

This contains some GDI and OLE API calls to convert the captured frame from a "packed DIB" into a StdPicture object that can be used with PaintPicture, etc. This raw StdPicture is created using a "memory DC" so there are some limits on how you can use it, i.e. simply assigning it to a PictureBox.Picture has some issues.

But in this demo we need to scale it anyway since we can't control the actual capture dimensions.

You could rework this passing in the hDC of a Form, PictureBox etc. I suppose.


Running the DSMini1 Project

The attached ZIP archive contains the entire Project.

All you should need to do is unzip the archive, then open the Project in VB6. If you have a webcam connected, you can just go ahead and run it within the IDE.

From there you will have to "Add" your webcam by browsing the filter list.

After a valid add, the live preview starts immediately at the left.

Clicking on the Snap button should take a snapshot and display it in the PictureBox at the right.

If you have another webcam connectd you shuld be able to add that one too. Once you have two or more added you can choose among them via Form1's menu.

Settings are persisted in Settings.txt, so a subsequent run should save you the trouble of picking cameras again.


Remarks

I don't know what webcams this will work with, but I know it works with two very different ones I've tried so far.

To show that you can use these techniques to run multiple webcams, I give you DSMini2.

The menus are rearranged, the settings file contents are slightly different, and the snapshot function has been pulled out, but now if you have multiple webcams you can preview two at once. Pretty much all of the other comments about running DSMini1 apply to DSMini2.


One thing not mentioned about DSMini1 is that it scales the views to fit the camera's aspect ratio. The same applies in DSMini2, but it might be more noticeable if your webcams have different aspect ratio settings: one view will be "shorter" than the other one.

A little refinement. Mainly small bug fixes in Form menu handling, a tweak to the logic for creating a StdPicture snapshot, etc.

Big change: Replaced a bunch of inline DirectShow related code in Form1.frm by a new DSPreview.ctl UserControl.


DSMini3 is the improved version of the single cam/snapshot demo (DSMini1).

DSMini4 is the improved version of the dual-cam demo (DSMini2).

Hmm, DSMini3 has a small flaw.

When you select a camera to preview that has a different aspect ratio from the default one it expects, it fails to adjust the "snapshot" PictureBox. The result is some stretching or squishing of the snapshot.

Not a big deal but something to consider. If you need to deal with it I'm sure you can on your own. Not worth reposting an update I suppose. DSMini1 was handling this issue properly though.

I don't have a webcam attached to my PC but, nonetheless, I lifted some of your code into a VB6 project of my own as I was interested in your GetCurrentImage implementation. It does indeed work very well but is, however, a lot (noticably!) slower than using the SampleGrabber approach.

Is this because of your over-generosity of the buffer size or is it just intrinsically slower?

yes I have checked it but i only give me black picturebox, no image at all, only black. that is why I wonder why that ocx is having no problem except that it has no save to file or to db capability.

attach is the screenshot of the result

Quote:

---

Originally Posted by ColinE66

I don't have a webcam attached to my PC but, nonetheless, I lifted some of your code into a VB6 project of my own as I was interested in your GetCurrentImage implementation. It does indeed work very well but is, however, a lot (noticably!) slower than using the SampleGrabber approach.

Is this because of your over-generosity of the buffer size or is it just intrinsically slower?

---

SampleGrabber works without pausing the filter graph, but GetCurrentImage requires that. However I don't know of any way to use SampleGrabber in a VB6 program without additional helper DLLs, so GetCurrentImage is useful in "first steps" examples of working DirectShow programs.

Quote:

---

Originally Posted by ravemaster

yes I have checked it but i only give me black picturebox, no image at all, only black.

---

Could be lots of things. Might be that your webcam has default settings leading to a black picture. Or it might be that the filter graph I am building doesn't work with your camera. This is where you would need to experiement since there may not be a universal solution.

Start by working with the graphedt.exe utility from the DirectShow (now part of the Windows) SDK.

What camera do you have?

Quote:

---

Originally Posted by ravemaster

that is why I wonder why that ocx is having no problem except that it has no save to file or to db capability.

---

Ocx? What ocx?

Save to file or DB? This is a code sample. If you want a full blown program for some purpose you can add more code or hire a programmer. This is CodeBank, not UtilityBank. :p

Plus at this point saving the image isn't too useful. First you need control over the capture format or risk getting nothing but tiny low-res images. This kind of control also requires a 3rd party helper DLL.

Ok, here is a more elaborate example DSElaborate5, based on DSMini1 & DSMini3 (one camera, with snapshot capture).


Background Info

I have not found a way to get these features without a helper DLL that can wrap a few more DirectShow interfaces in "Automation" (ActiveX) form.

I decided to use what appears to be the widely used FSFWrap.dll from Geraint Davies Consulting Ltd. (GDCL). I says appears to be widely used, because oddly enough some heavy searching of the Web didn't turn up a single useful example of the use of this library. All I found was an example from GDCL that doesn't seems to work with cam-capture, and somebody's attempt to convert that same VB6 example to VB.Net 2XXX (not sure which VB.Net, don't care).

My conclusion:

This was never that popular, or it used to be and a lot of posted examples have disappeared since 2005 or so, or it is quite popular but most users are too lazy or greedy to share by posting helpful information and working code...

... or I'm just not that great at searching. :cool:


This New Example

In order to run this example yourself you will have to obtain and install this library. I'm attaching the instructions along with a .DEP file that the author failed to provide for the library. I can't provide the DLL, because (a.) we aren't supposed to attach binaries and (b.) it isn't mine to hand out.

So here are the new features:

• Camera selection dialog is now built selectively, i.e. it should list your cameras and only your cameras.
• Capture (pin) properties can be viewed and altered when a camera is started.
• Camera (filter) properties can be viewed and altered once a camera has been started, and these changes are "live."

I can't find a way to make the pin properties pages work properly except as part of building the filter graph and starting it. Perhaps somebody else has an alternative that allows changes to these while the graph is running.


Since I now have a way to configure the pin properties (mainly the capture dimensions) I have added an unrelated feature:

• Both Snap and Snap+Save (to JPEG file) buttons are present.

And "Snap to Byte array" could be added. The code is there, you just need Edanmo's olelib.tlb for that. See the new GPP2J.cls module's header comments for details.


I hope you find this new version interesting, if not useful.



mod comment - Link to FSFWrap removed as it's closed source. Its easy enough to google for though.

Quote:

---

Originally Posted by dilettante

SampleGrabber works without pausing the filter graph, but GetCurrentImage requires that. However I don't know of any way to use SampleGrabber in a VB6 program without additional helper DLLs, so GetCurrentImage is useful in "first steps" examples of working DirectShow programs.

---

Ok, so that's what the docs say.

But I found somebody skipping the pause yet doing GetCurrentImage() calls... so I tried it and things are working just fine!

Ok, one more time...

This version is the same as 5b above, but with a change to the filter graph and method by which the graph is connected. All told just a few lines difference.

It might address the "black picture" problem though.


ffdshow

It is also worth noting that if you have ffdshow installed, a dialog from it may appear when testing in the IDE and again for the compiled EXE. It seems to maintain a "blacklist" or something though, so you can choose "don't show this again for this program" and you won't be bothered again.

Of course you'll get that both for VB6.EXE (runs in the IDE) and the compiled program, separately. And you can always opt to be reminded each time instead if this matters to you.

I actually use capstill.dll in my program (link in sig) and I do recall seeing some code at his site for working with webcams but, if memory serves, it accompanied his fsfwrap.dll - you might want to take a look at that.

EDIT; sorry for confusion if you happened to read the pre-edit version of my post; capstill.dll is the one that facilitates the SampleGrabber, not fsfwrap.dll. Within one of the demo projects (can't remember if it was capstill or fsfwrap) I recall seeing some code related to webcams.

I still have to get around to looking at the Sample Grabber. I see that it is a deprecated filter with Merit set to MERIT_DO_NOT_USE, but what isn't deprecated by Microsoft these days?


The point of this thread was to try to demystify the use of DirectShow webcam capture in VB6. I'm not sure that this can be done once you start requiring extra helper DLLs.

My examples 3 and 4 above are refinements of 1 and 2 and don't introduce anything complex. They also get results as good or better than what most people are doing with the older VfW API anyway.

What 1 through 4 lack is the ability to set the most minimal capture params, such as the capture image size. While my several stabs at example 5 address this, it is indirect (i.e. via the properties dialogs).


So all I really care about beyond this is setting those within the program itself, in code instead of through dialogs. Well, that and trying to figure out where the "black picture" problem comes from for some cameras or users and fixing that if possible.

OK. I was just trying to help as earlier you said this:

Quote:

---

Originally Posted by dilettante

I decided to use what appears to be the widely used FSFWrap.dll from Geraint Davies Consulting Ltd. (GDCL). I says appears to be widely used, because oddly enough some heavy searching of the Web didn't turn up a single useful example of the use of this library. All I found was an example from GDCL that doesn't seems to work with cam-capture, and somebody's attempt to convert that same VB6 example to VB.Net 2XXX (not sure which VB.Net, don't care).

My conclusion:

This was never that popular, or it used to be and a lot of posted examples have disappeared since 2005 or so, or it is quite popular but most users are too lazy or greedy to share by posting helpful information and working code...

... or I'm just not that great at searching. :cool:

---

Thanks, I missed your link. I normally have signatures turned off since so many are huge blobs of images and other distractions.

I tried 5b with a laptop having a camera identifying itself as Chicony USB 2.0 Camera and it works there too.

One quirk I did see was that if I changed the capture dimensions from those it defaults to (which are never the dimensions marked "(default)" in the properties dialog???)... the image can come up very dark.

But with this dark image, if I then choose the Configure camera properties... dialog and once that pops up I click on the Default button there... the camera seems to automatically adjust the exposure to something usable.

I'm not saying this is the root of the "black picture" issue, but it did seem odd.

hi
first thank you a lot for the app it helped me a lot
i added it to my project
i still new to programming i have 5 month now
my only problem is :
is there a way to filter the list items to show only the camera drivers because there is a lot drivers shown
thanks for help

To limit the list of filters to capture filters (cameras) you need to use a 3rd party helper library. That is because the necessary interfaces to do this in VB6 were not provided by Microsoft.

See post #9 and later for examples of this, using the popular helper library FSFWrap (free). Those are the "Elaborate" examples: 5a, 5b, and 5c.

hi Mr delettante :
thank you a lot for the help
i did it it works great thanks a lot so much

hi delettante
i need an advice from you if possible
how i can learn how to use any library file
for example i want to learn how to use twain32.dll or FSFwrap.dll
or any other dll file what is the best way thanks

You need to get the DLL's documentation.

For FSFWrap there isn't much that I can find except what its author posted years ago. So to use it you have the few hints there, his sample programs there, what you can work out using the Object Browser in the VB6 IDE, and what you can guess based on the C++ interfaces documented in the MSDN Library.

As far as I can tell not many people ever did much with FSFWrap, or if they did they never wrote much about it that I could find on the Web.

Documentation can be as hard to create (or harder) than writing the code itself. So many free libraries don't have much.

The TWAIN API is very old (though still popular). But because it is old it can be very hard to find any Microsoft documentation for it now, plus it is "owned" by http://www.twain.org/ so you might try there.

hi
so to learn how to use any library i have to get its documentation because its always seems for me that the codes is hard to learn and understand
thank you for your advice
thanks a lot

xxxxxxxxxxxxxxxxxxxxxxxxxxx

What you have posted is an example of using AviCap in the most simplistic fashion possible.

I see you have edited this out of post #23 now.

This is extremely common and there are quite a few CodeBank examples already posted. Your program also makes use of the clipboard in way that programs never should when at all possible. There are far better AviCap examples here in the CodeBank that do not destroy the user's clipboard data.

And your attachment has nothing to do with using DirectShow from VB, which is what this thread is all about.


The reason to try to use DirectShow instead of AviCap is that it offers your program much more control over capture formats and camera settings, allows selection among multiple cameras, capture from more than one camera at a time, and offers other potential advantages.

That's why this thread is here: to help people start programming using DirectShow instead of the old AviCap API.

:Dsystem is overheating...............................................cool down

Hello,

First, thanks for this thread.

I tried 5C but no luck, I keep getting 'BlueGraph error' , tried with several webcams. (Win8 x64 btw)

downloaded the DSMini4.zip and find it works great with a USB cam, but not with a video to USB adapter.
In this event, the EasyCap adapter. It sees the cam as 'SMI grabber device' (which works as I can see the pic in other apps), but when I try preview I get-
----------------------------------
Selected camera for preview 0 failed, may not be connected
SMI grabber device
BuildGraph error 1
----------------------------------

Any suggestions?

Quote:

---

Originally Posted by SpaceDonkey

I tried 5C but no luck, I keep getting 'BlueGraph error' , tried with several webcams. (Win8 x64 btw)

---

Quote:

---

Originally Posted by Mike Scott

downloaded the DSMini4.zip and find it works great with a USB cam, but not with a video to USB adapter. In this event, the EasyCap adapter.

Any suggestions?

---

I don't have a Win8 test system set up but I would expect it to work there with no problems.

However these programs are only able to handle some generic cases so finding webcams that won't work is very likely. These sample programs are probably best treated as examples of how you can use DirectShow in VB6 programs.

DirectShow covers a large set of multimedia operations through "building blocks" and your programs need to "assemble" several blocks together to "spell a word" (to stretch an alphabet-block analogy). These programs are making assumptions about the "block" at the beginning and the "block" at the end and try to assemble the necessary "blocks" to span the gap between them.

It is a little more complicated even than that makes it sound. Every "block" can have zero to many inputs and zero to many outputs, and your program needs to string the blocks together by joining the right outputs to the right inputs.

Your capture device (camera) may not have the particular output "pin" as they're called that my programs here expect. Or it might have the right output pin, but it may require another intermediate filter block to transform its output data stream.


To handle things truly generically (to write a "universal" program) you'll probably need to understand the process better than I do, you'll need more complicated code, and it may not even be possible in VB6 since only a few items are made available in a form easily used in VB6. The FSFShow wrapper helps, but may not make enough of DirectShow available to do the entire job.


If you have the Windows SDK you'll find that the old DirectShow SDK has been merged into it. This gives you a tool to play with called graphedt.exe ("GraphEdit"):

Attachment 97575

This might give you something to experiment with so you can improve what I have tried to do in these sample programs.

Of course translating from there to a VB6 program can be tricky, and it will require that you study the DirectShow documentation in some detail. But perhaps my sample programs and the FSFWrap author's samples will help get you there.

Quote:

---

Originally Posted by dilettante

I don't have a Win8 test system set up but I would expect it to work there with no problems.

However these programs are only able to handle some generic cases so finding webcams that won't work is very likely. These sample programs are probably best treated as examples of how you can use DirectShow in VB6 programs.

DirectShow covers a large set of multimedia operations through "building blocks" and your programs need to "assemble" several blocks together to "spell a word" (to stretch an alphabet-block analogy). These programs are making assumptions about the "block" at the beginning and the "block" at the end and try to assemble the necessary "blocks" to span the gap between them.

It is a little more complicated even than that makes it sound. Every "block" can have zero to many inputs and zero to many outputs, and your program needs to string the blocks together by joining the right outputs to the right inputs.

Your capture device (camera) may not have the particular output "pin" as they're called that my programs here expect. Or it might have the right output pin, but it may require another intermediate filter block to transform its output data stream.


To handle things truly generically (to write a "universal" program) you'll probably need to understand the process better than I do, you'll need more complicated code, and it may not even be possible in VB6 since only a few items are made available in a form easily used in VB6. The FSFShow wrapper helps, but may not make enough of DirectShow available to do the entire job.


If you have the Windows SDK you'll find that the old DirectShow SDK has been merged into it. This gives you a tool to play with called graphedt.exe ("GraphEdit"):

Attachment 97575

This might give you something to experiment with so you can improve what I have tried to do in these sample programs.

Of course translating from there to a VB6 program can be tricky, and it will require that you study the DirectShow documentation in some detail. But perhaps my sample programs and the FSFWrap author's samples will help get you there.

---

Unfortunately, the SDK kit looks like it's for Win8 only. I'm on XP :-(

Quote:

---

Originally Posted by Mike Scott

Unfortunately, the SDK kit looks like it's for Win8 only. I'm on XP :-(

---

When you snooze you lose I guess. XP is dead and cold now with Vista on the chopping block next.

There should still be a Windows 7 SDK for a few months.

And you can still order old SDK CDs for a shipping fee from SDKs.


But as far as I know even the Win8 SDK download should install fine on an XP system. Just note that a lot of old stuff is gone and some of the new stuff won't run on XP.


Also note that your old MSDN Library CDs that VB6 uses for it online Help contain most of the C++ and VB6 DirectShow documentation that exists. The October 2001 issue is best, but any from shortly before then should be Ok too.

Quote:

---

Originally Posted by dilettante

However these programs are only able to handle some generic cases so finding webcams that won't work is very likely. These sample programs are probably best treated as examples of how you can use DirectShow in VB6 programs.

DirectShow covers a large set of multimedia operations through "building blocks" and your programs need to "assemble" several blocks together to "spell a word" (to stretch an alphabet-block analogy). These programs are making assumptions about the "block" at the beginning and the "block" at the end and try to assemble the necessary "blocks" to span the gap between them.

---

hello Dilletante!

This is Red from the Philippines.

I've tried your webcam demo number 2(DSMini2) and it worked for me.

However, when i tried doing some video saving stuff, it caused me several sleepless nights because
i can't seem to get it working. in fact, i don't know how to start. I Googled sample codes BUT it gave me
lots of C/C++/C# codes instead of VB6. The closest VB6 code that i tested are your sample codes posted here.

Some say that VB6 can't do deep webcam programming, instead they recommend C/C++/C#..
BUT i don't believe it. I've seen how you code and i know that you do webcam recording. You have done
capturing "pins" in your codes "but the saving to file" part is not included..

I know there are others out there that use classic VB6 BUT don't have webcam video recording in their programs.
Since you are an expert in this field, please share us a sample code on how to record the "capture pin" while the
"preview pin" is displaying the video. Another minimal code will do.

see attached images:
Attachment 102705Attachment 102707Attachment 102709Attachment 102711

Sorry Red,

I'm no expert, I was only playing with it a bit to see how far I could get without using helper libraries. Then I looked around and found one simple helper library and played with that a little.

It looks like you have dug a little deeper. Maybe you can get AVI writing working and post sample code for us to look at here.

There's a File Writer filter that comes with windows that can be added to the graph. I've never used it myself but have a Google....

Big thanks to your reply Dilettante..
sorry, mispelled your name from my previous post :)

i'll dig some AVI stuff then post the codes here when i'm done.
Again, the codes you posted are very helpful to non-experts like me (i consider you as an expert).

BTW, i tried FFMPEG to record webcam's video.
It did work but you need to "STOP" the graph from VB6 ==> fgmVidCap(0).STOP

From what i saw, there should ONLY BE 1 INSTANCE of an "OPEN webcam"
before it pushes with the recording.
Meaning, if you want to use FFMPEG to record a webcam's video, STEP 1 is to "close that particular webcam".
STEP 2 is the the FFMPEG execution.

Here's how i did the recording:
ffmpeg -t 00:00:30 -f dshow -i video="USB Video Device" -r 30 -s 480x320 -y sample_1.AVI


-t 00:00:30 time to record is 30 seconds
-f dshow it uses DirectShow? i'm not sure
-i video="USB Video Device" video input comes from my cheap USB Webcam
-r 30 rate is 30 frames per second
-s 480x320 video size
-y sample_1.AVI output name, -y means overwrite if file exists


Dilettante, i need to continue previewing my webcam WHILE the FFMPEG code is executed.
Any suggestion?

Thank you.

Thanks for your reply ColinE66!

:) yes, sure i will Google what you said.
Hope i can find it.

Quote:

---

Originally Posted by redp

Dilettante, i need to continue previewing my webcam WHILE the FFMPEG code is executed.
Any suggestion?

---

There may be DirectShow filters that can split the data into two paths (sort of a "Y adapter").

Yes Dilettante, i agree with you... That "data(video) splitter" exists somewhere. Many have done it using C/C++/.Net..

For now, I still want to do it with classic VB6.. Gut feel tells me that it can be done.

Anyway, when i'm done with this splitter thing, i will come back here and thank you again :)

- Red

There's two default-splitters in the DirectShow-Filterlist:
- one is the "Smart Tee"
- and the other one is the "Infinite Pin Tee Filter"

the Smart-Tee is suitable in Video-scenarios, whenever a given capture-device does not already offer two separate Capture- and Preview-Pins.
Internally the splitting is ensured - but with a preference of the stream which goes out on the Capture-Pin - that ensures a better behaviour with regards to dropped frames -
and that capture-pin is usually, where Video-encoders and another standard-filter, the "Avi Writer Filter" usually make one "downstream-path", whereas the Preview-Pin
leads into the usual "Video Renderer"-Filter as the other endpoint.

The "Infinite Pin Tee Filter" does not prefer one splitted stream over the other - it tries to provide the same stream-samples across all branches - it is the more generic one.

Below is a ScreenShot of my updated NewGraphBuilder-example, showing the "Smart-Tee in action"
The NewGraphBuilder-App (with the additional help of three typelibs) is now covering nearly all the functionality
of the original Builder-example which came with the FSFWrap.dll-Helper-lib.

I've also cleaned up the code of the original Builder-Example, which is now reduced to about half the lines it formerly had.

The used Typelibs are:
- ActiveMovie Control Typelib (that's the usual one, which is always useful in VB6/DirectShow-contexts)
- MS Video Control 1.0 Typelib (this was offering such nice interfaces as IBaseFilter, IGraphBuilder etc. - so no need to define them in ones own typelib)
- Edanmo's OleInterfaces and functions (for more generic OLE-interactions per IIDs - but also has IPersistStream- and other interfaces, allowing for *.grf loading/saving)

In the Zip-Archive I've included Eduardo Morcillos olelib.tlb (later on there's no need to include it into your setups) - and the other two are system-standard-libs.

Quote:

---

Originally Posted by Schmidt

Below is a ScreenShot of my updated NewGraphBuilder-example, showing the "Smart-Tee in action"
The NewGraphBuilder-App (with the additional help of three typelibs) is now covering nearly all the functionality
of the original Builder-example which came with the FSFWrap.dll-Helper-lib.

---

Schmidt, glad to hear from another expert(you are truly a master in this regard)..

I will try the attached code then come back.
And to Dilettante/ColinE66, finally Schmidt's code is the answer to the "splitter" problem..

Though I haven't tested it, i'm thanking you Schmidt for this contribution in behalf of those users who prefer classic VB6.
This is a huge help from non-experts like us.

No need for "praise in bold letters" (makes not only me feeling a bit uncomfortable I'd guess) ...

Your: "I will try the attached code then come back" - is already enough. :-)

As for playing around with the Builder-App ...
Anything you are able to "click together" (Graph-wise, with your Mouse), you should be
able to accomplish (finally, in your own Application) also per direct code.

If you were able to construct a certain, well-working graph (and know all the filter-members
who make up this graph) - then try to achieve the construction in as few "Click-steps" as possible.

Especially the [Connect Downstream...] button (with its CurrentPin.Render-call behind it)
can be a big help in attempts on "cutting down the amount of actions until a certain graph is running".

Also "inverse graph-construction" would be possible this way - e.g. when you use the
[Connect Downstream...]-Button to automatically construct larger parts up to their endpoints -
and then if the result is not satisfying, but only in a few "last parts" -> just step-backwards,
removing Filters on the graph - and then construct only what you deleted anew (with better
suiting filters, to reach your endpoints).

There's still a lot one could do with regards to "easing graph-construction even more for VB-Classic" -
but that would require (if done correctly) a special wrapping of all the important classes who take part
in such DirectShow-scenarios:
cGraph
cFilter
cPin

'more comfortable Source-classes
cVideoInput
cAudioInput
cFileInput

'comfortable to use Classes "in-between"
cSplitter
cMuxer
cEncoder
cDecoder
cSampleGrabber

'more comfortable to use EndPoint-Classes
cVideoEndpoint
cAudioEndpoint
cFileEndpoint


That's not all that much - but each of those Objects could (and should) offer nice Properties, nice
VB-friendly Enumerators (wrapped in VB-Collections) - and much better Find- and "Plug-together"-
comfort-functions ... best done in a way, so that all the used Typelibs and Interfaces remain
hidden (in case those new Classes are wrapped in a ActiveX-Dll-Project) - so that the end-user
of this DShow-wrapper-Dll would need only to check-in this single reference into his DirectShow
related projects (the references to quartz.dll, msvidctl.dll and olelib.tlb could remain hidden in the Dll-Project).

But maybe we should discuss this not in this thread, but start a new Thread for that here in the
code-bank. I'd be willing to do some ground-work and post Implementations for some of the
BaseClasses as: cGraph, cFilter, cPin and e.g. cVideoEndpoint and maybe also cSampleGrabber -
it would be up to the community, to fill in the blanks (the remaining comfort-classes + functionality
within those classes).
Especially when dilettante would join in, such an encapsulation could evolve nicely I'd think.

Olaf

I'd be happy to contribute to such an effort and have more experience than most with regard to graph-building in VB6. In particular, I am very interested in a robust SampleGrabber. Geraint Davies capstill.dll is fine up to a point, but will only accept 24bit RGB inputs and some upstream filters are not always willing to provide this! An overlay filter would be great too as would (getting greedy now!) a filter that one could use to adjust RGB, HSL on-the-fly.

Ahh, Colin ... since we know each other for so long now - and due to your Vee-Hive-background, I counted you in automatically already... sorry. :-)

Olaf

That's fine. I've been looking forward to the day that vbRichClient tackles DirectShow but didn't like to ask! ;-)

I might be able to help a little, but right now I have a contract that is eating up a lot of my time. I'll look for the new thread and try to contribute where I can.

I haven't followed how vbRichClient has progressed but I'm not sure a single gigantic DLL with a mixed bag of things in it meets everyone's needs. Perhaps I haven't given the idea enough thought but I prefer things to be more granular.

I have a hard time "selling" the idea of projects dependent on large 3rd party libraries. My clients have been bitten badly before by such things.

Quote:

---

Originally Posted by dilettante

I might be able to help a little, but right now I have a contract that is eating up a lot of my time. I'll look for the new thread and try to contribute where I can.

---

Ok - just in case... this new DirectShow-wrapper-stuff will not have a RichClient-dependency... ;-)

Quote:

---

Originally Posted by dilettante

I haven't followed how vbRichClient has progressed but I'm not sure a single gigantic DLL with a mixed bag of things in it meets everyone's needs. Perhaps I haven't given the idea enough thought but I prefer things to be more granular.

---

As for "giving the idea enough thought" - please do ...
- when you write "single gigantic DLL with a mixed bag of things" - then think: "VB-Runtime-alternative"
(-> msvbvm60.dll is pretty much the same "mixed bag", containing beside the "compiler-runtime-functions" also
- a Form- and a UserControl-engine with dynamic-add/remove,
- a GDI-based drawing-engine supported on different "Canvases",
- a set of Controls, a Collection and a few other classes I've perhaps forgot).

The RichClient-development aims at replacing the msvbvm60.dll in the long-run completely.
Because of that it is based on platform-independent libs already (in its two most "weighty" parts; the DB-engine and the Rendering- and Control-engine).

As for Deployment-size (in modern LZMA-format, 7zip-archived):
VBRuntime: msvbvm60.7z = 519KByte
RichClient: RC5BaseDlls.7z = 1634KByte - so roughly 1MB more "to ship or to download" (which is still OK these days for the "bunch of additional class-functionality")

Quote:

---

Originally Posted by dilettante

I have a hard time "selling" the idea of projects dependent on large 3rd party libraries. My clients have been bitten badly before by such things.

---

You mean "large 3rd party libs" as in e.g.: ... 'ADO' for example? ;-)

Just joking - but I think you see where I'm getting at ...
I mean, there *were* some problems with ADO-typelibs, caused by "the vendor" ...
and wellknown fixes for that in the meantime too - sure - but then... same thing recently with the CommonCtls...

Not sure what could go wrong in case of a RichClient-dependency in this regard ... what you (or your customers) should fear?
MS would need to break COM completely - to prevent the instantiation of COM-classes from the RichClient - but in this case no VBClassic-App would work anymore.
I'm the last person who has an interest in "breaking VBClassic-Apps" - and a bit of trust with regards to:
"Stuff from Schmidt" should be there in the VBClassic-community I hope (maybe not yet in this forum here, but I'm working to change that <g>)...

But before getting more Off-Topic - maybe we should continue per Mail?

It's just - there's a lot of still enthusiastic and young developers here in the Forum (to my surprise, being a late-comer to the party here).
Young guns, who have loads more "coding-power-per-day" compared to us middle-aged or "already somewhat older" devs who have to "make good with experience".

I'd like when more experienced VBClassic-devs would join the efforts to come up with a new IDE and a new Compiler
(sharing in the help-efforts of "channelizing and directing the enthusiasm of the younger devs" a bit).

So, yeah - I'd like when you could throw your weight into the idea as well - and as for "daily work" -
I'm moving slowly with all that too (as my spare-time allows) - but every year there's more groundwork done.
As said, a mail would be nice - maybe I'm able to convince you finally... :-)

Olaf

Quote:

---

Originally Posted by Schmidt

- when you write "single gigantic DLL with a mixed bag of things" - then think: "VB-Runtime-alternative"...

The RichClient-development aims at replacing the msvbvm60.dll in the long-run completely.

---

Yeah, I thought this might be the direction.

Quote:

---

Originally Posted by Schmidt

You mean "large 3rd party libs" as in e.g.: ... 'ADO' for example? ;-)

---

Well Microsoft did indeed recently cause some ADO grief (Win7 SP1 comes to mind) but I was thinking of large sets of 3rd party controls you can't get anymore.

Quote:

---

Originally Posted by Schmidt

I'm the last person who has an interest in "breaking VBClassic-Apps" - and a bit of trust with regards to:
"Stuff from Schmidt" should be there in the VBClassic-community I hope (maybe not yet in this forum here, but I'm working to change that <g>)...

---

Er, don't point at those UseNet groups if you want credibility. A veritiable Mos Eisley Space Port of the worst VB6 programmers in the universe in recent years.

Quote:

---

Originally Posted by Schmidt

But before getting more Off-Topic - maybe we should continue per Mail?

---

Thanks for the invitation, perhaps once I get more settled. I'm doing a lot of travel these days chasing contract work, and mostly come in here instead of vegetating watching television while sitting in motel rooms.

I'm not sure how else you might move forward though. VB Classic (A True VB 7.0) has been started though your goals may differ and I'm not sure how the rules work for threads in that forum.

But I will give it more thought.

As for "not pointing at those Usenet-groups if you want credibility"...

You're probably right with your "Mos Eisley Space Port"-analogy (the UseNet as a whole goes this route... sadly, I might add).
But that this automatically would imply an: "only the worst programmers imaginable post there" - I'd doubt.
I mean, 'Nobody' could reach your conclusion here, if not from occasional UseNet-lurking: ;-)

Quote:

---

Originally Posted by dilettante

If that Schmidt guy takes an interest he might have more detail to contribute. He dives deeper into COM and VB issues than most of us need to.

---

Sorry to dig that up, but a bit of "self-defense" is in order I think...? :-)

Quote:

---

I'm not sure how else you might move forward though. VB Classic (A True VB 7.0) has been started though your goals may differ and I'm not sure how the rules work for threads in that forum.

---

Just posted a reply in the thread you linked to - maybe we can continue the discussion (about "RichClient and stuff") there - because I've always seen (and developed) it in this larger context.


Olaf

Nothing to defend against.

You can find anything anywhere. My only point was that the VB newsgroups are dominated by people who don't ever seem to get very good at programming, almost as if nobody else will have them. I wasn't implying that anyone who ever posted there is hopeless though. There is just a bit of a reputation there.

It's Expert-to-Expert talking here :)
Count me in as one of your followers.

About my problem from this thread (Saving webcam video to AVI.. Capturing while Recording),
I'm resting my case. Olaf Schmidt's sample code is the answer though i can't figure what to do.
I can't figure how to "assemble/extract" that part where the codes remaining in the program(Dilettante's DSMini2)
are those that solve my problem..

I don't want to bother any of you guys since you have a more important things to take care of.
It's going to be too much if i still ask you to do it for me.
I'll continue playing with Olaf's code until i solve my problem.

BTW, Dilettante's sample code is very important.
It was an eye-opener for me to see other experts work like Olaf and ColinE66.

Lastly, to Olaf: i didn't use bold letters anymore but praises, yes. You all deserve it.
Thank You A Lot.

Red

Using the MS Video Control 1.0 Typelib is an eye-opener for me too. I've never done much with DirectShow and that little was a long time ago, so I was just trying to see what results I could get. My failure to mention it merely means I was completely ignorant of this second typelib, and wish I'd done more research in the first place.

I hope when I'm back home from my current "road show" I can take time to play with this a little bit again.

This was sort of a "Beginner's Introduction to DirectShow" code example thread. Maybe now we need an "Intermediate DirectShow" thread?

When will your current "road show" finish Dilettante? Will it take long?

if there will be an "Intermediate DirectShow" thread started by you, i'm thanking you in advance.
i doubt if Schmidt and ColinE66 will still see "that thread" because they're now busy contemplating
with a "new version" of VB6 Classic with other heavy experts. Are you joining Dilettante?

Well, back to the intermediate thread, i'm looking forward to seeing it in action :)

I'd like when I could open it with what I currently have with regards to the outlined Class-Structures from one of my posts above ...
@Colin - the cSampleGrabber is already working - but what is still missing is a cMediaType-implementation, to be able to comfortably
read-out and apply those settings on cPins who support this (to force certain resolutions and color-spaces)...

Can't tell when this will finally be finished...(maybe this week, maybe in two) - am currently a bit in a Round-Robin-Mode
(with short-outbursts here into the forum <g>).

But if dilettante or Colin already have something new, worthwhile enough to make a (somewhat enhanced) demo from -
no need to wait for me - I'll join you then.

Olaf

Most of my exposure to DirectShow has come about through my use of Geraint Davies' DLL's (fsfwrap, ovtool, and capstill). I am by no means an expert with the underlying DirectShow frame-work, although I am familiar with some of it in an 'if only VB6 had access to that' kind of way; I mean, it's all there just waiting for somebody (Olaf!) to expose it! Having said that, I am happy to contribute to an intermediate VB6 tutorial if dilettante expands upon what he has in mind for it to cover. I'm fine with graph-building, pin and filter enumerations etc. and can certainly contribute something in that respect.

@Olaf, is there anything that is currently 'usable' (notwithstanding the absence of cMediaType) that I can play around with, please? Oh, and is a cOverlay class planned?

Quote:

---

Originally Posted by redp

When will your current "road show" finish Dilettante? Will it take long?

---

I have to finish out this week here, then get to another customer's site and spend 3 days there. Then back home to work on things from there... then back to those sites, and so on.

I'm tied up quite a bit for a while, great news since it means a little money coming in. But for a while I won't be doing anything with VB6 except poking around to read questions here and make short replies in my spare time.

Quote:

---

Originally Posted by redp

if there will be an "Intermediate DirectShow" thread started by you, i'm thanking you in advance.
i doubt if Schmidt and ColinE66 will still see "that thread" because they're now busy contemplating
with a "new version" of VB6 Classic with other heavy experts. Are you joining Dilettante?

---

Right now most of my time is taken up with Android projects. I don't do any Windows programming anymore except for recreation unless I get a specific contract to do some Windows programming.

Right now I don't plan on writing more about DirectShow. I don't have enough experience with it to do a good job anyway.

I'll keep an eye on the "future VB" thread but I can't contribute right now.

So you're moving back and forth Dilettante.. That really takes time and effort. Why not use the power of "networking" in order for you not to go to your project site physically?

I just paused before typing this to pray that you, Olaf and ColinE66 will get huge projects in the near future and with huge amounts of course.. You all deserve to "get profits" because of your share/contributions on programming not to mention VB forums and the like..

And since you need to focus doing your projects, maybe this is the end of this thread.

Your fellow expert's replies from this thread will be read by other beginners in the future.. and will remember the names like Dilettante, Olaf Schmidt and ColinE66..

Hi everyone
Sorry for my poor english.
I am using windows 7. I try to show webcam on my vb6 form. I am using DSMini4.zip. It is working on my labtop without any problem. My labtop has embeded webcam. It works also I plug other webcam it work too. But when I plug same webcam to other desktop computer the program give a message "builtgraph error". How can I solve this problem. Thank You

Building the filter graph is the biggest problem faced when using this approach.

The code posted above tries to stich one together at runtime but it isn't perfect. Success can vary quite a bit from machine to machine, because not every machine has the same set of filters installed.

For all I know... it may be impossible to write a generic program to do this successfully on every PC even when using exactly the same webcam.

Thank you for your reply.
Are there any solution for using any other machines same program? Can I set filters or something else to run other machines?

Often the filters can be installed as part of installing video codec packages. There are some filter packages like DirectShow FilterPack 5.1 but i have not used them, and I couldn't say whether they contain the necessary filters.

Thank you for your information. When I try it, give my experience to you.