With the advent of Windows
95, VFW functionality was built into the core
operating system in the msvfw32.dll and
avicap32.dll. These dlls were also included
in Windows NT starting with version 3.1.
There are some things you need to be careful
about when designing VFW API code (or any
code really) for both WinNT and Win95.
However the API is there on both platforms
now, and it is possible to create one
EXE that will run on both platforms.
A bigger issue may
be finding hardware with drivers for WinNT
as a seperate driver must be written that
supports the true 32-bit environment of this
OS. Win95 VFW drivers, on the other hand,
still have some 16-bit components and require
a 16-bit compiler like MSVC++ version 1.52.
Fortunately, as WinNT has become more
prevalent, some hardware companies are now
writing drivers for both Win9x and WinNT.
One thing I have
learned from personal experience is that it
is best to find a balance between using
mature and stable technology and using the
latest tools and APIs. There comes a
point in time where support dries up for old
and "obsolete" technology. However,
it is also usually a bad idea to go with the
newest technology too quickly - unless you
have some overwhelming feature requirement or
other reason to "live on the bleeding
edge" during your development cycle.
Therefore I don't (yet) advocate the use of
DirectX for developing Video Capture
applications.
CASE IN POINT:
Microsoft Knowlwdge Base
Article ID: Q192112
Video Capture WDM driver does not work in
Windows 98
http://support.microsoft.com/support/kb/articles/q192/1/12.asp
VFW drivers are still
supported under Windows 2000 Beta 3
("the OS former known as WinNT5")
as well as the older Windows platforms
mentioned above and the VFW replacement
technology, DirectShow is, and will be, fully
backwards compatible. What this means is that
as of right now VFW is still the best
choice for hardware companies with
limited development resources because
hardware with VFW drivers will
function correctly on all the legacy software
and operating systems as well as on the newer
software which is based on
DirectShow and the new Windows Driver Module
(WDM). WDM drivers, on the other hand, will
work only on systems that have the DirectX
Media runtime installed. Not only is the
supported user base much broader for VFW, but
it is also much easier to develop for VFW. It
is a much more mature technology with most of
the bugs worked out. There is no need for
messing around with COM and Interfaces and
GUIDs. And there are several fully
functional sample applications and
documentation freely available in the
Microsoft Developer Network
Online
(MSDN).
For these reasons I will
concentrate mainly on using VFW for Win32. I
will provide a complete Visual Basic
version of the Microsoft VidCap32 application
with full documented source code.
This project, vbVidCap, is code only - with no external
controls or other dependencies and contains
an almost totally complete VB translation of
the vfw.h file used by C programmers. I
purposely used kept the code as simple as
possible and used only one callback function
(which can be disabled in debug mode) so that
beginners as well as expert VB programmers
would be able to gain some understanding from
this code. Even without extensive use
of subclassing and callbacks I was able to
almost completely reproduce the functionality
of the C program (since I don't have
an MCI-compatible VCR to test with, I
ommitted the MCI step-capture functions).
Go
to the vbVidCap project page now!
For those who are not
interested in the "nuts &
bolts" of the Win32 VFW API, but only
want a clean 32-bit capture solution for VB.
I am also providing a 32-bit freeware
Video Capture OCX, ezVidCap. Like the 16-bit CapWndx.vbx that
shipped with VB3, this component allows
you to change and preview all VFW settings in
design mode as well as runtime mode.
There are, however, significantly more
features in this new 32-bit component. I
believe it is a good example of the power of
VB5 for component building. On Win98, for
example, this OCX and the above EXE can be
run with no extra runtime or any other
dependency of any kind. This allows for an extremely
small distribution/download size and no
installation/version incompatibility issues.
Go
to the ezVidCap.ocx component page now!
DirectX Media
(a.k.a. DirectShow
- a.k.a. ActiveMovie 2.0)
Microsoft
stopped development on VFW almost immediately
after Win95 was released and announced that a
new technology, ActiveMovie, would replace
the MCI and VFW APIs. In theory,
this is a good thing. ActiveMovie supports
steaming media, has a true 32-bit
architecture, and fixes some problems with
VFW (like a 2GB file size limit and no
support for multi-threading). However, I
have been waiting for a 32-bit video capture
solution for VB for a couple of years now,
and its still not here.
When
ActiveMovie 1.0 was released, MS announced
that audio and video capture would be
supported in 2.0. Shortly thereafter, the
ActiveMovie team was reorganized and the
technology was renamed DirectShow. I
went to an MS game developer's conference
here in Yokohama about 2 years ago and spoke
with Christiano Pierry, who was, at that
time, the manager of the Active Movie
development team. He assured me that
ActiveMovie 2.0 would be released by
mid-summer at the latest and that it would
include support for video capture. What
he didn't tell me was that the typelibrary
for quartz.dll,
which is the VB interface for ActiveMovie
would offer no access to those functions. ThereforeVB
programmers still have absolutely no access
to the capture interfaces in ActiveMovie.
Well, as I
continued using VFW there were delays and
reorganizations in the ActiveMovie team, and
finally the technology was again
renamed, this time to DirectX Media
and DirectShow was lumped in with
DirectAnimation and DirectX Transforms. The
development team was merged with the DirectX
team and at the same time not merged. It's
kind of confusing because although DirectX is
supposed to be one big API, the DirectX Media
group is on their own schedule and have their
own beta program, etc... So, although the big
buzz lately has been that MS will
support VB in DirectX 7.0, I am still
not sure whether VB will be supported in
DirectX Media 7.0. No one from MS
has given me a straight answer on this. [*note:
(03/11/99) I have since learned that DirectX
Media is NOT on the list to have VB support
improved. I still haven't received my DX7
beta CD, so I'm not exactly sure what can be
done with DX7 yet - stay tuned.]
Because of
this, I have not focused much on DirectShow
yet. However, since I am on the DirectX Media beta program, I did decide
to see just how much support MS has included
for video capture under Visual Basic.
I wrote a sample application, DXVidCap, which displays a live video window
and can even switch to full-screen mode.
However, although I worked around some big
limitations like how to enumerate available
capture devices, there was no way to access
the properties of some of the most important
filters (like the FileWriter filter). So this
app cannot actually write an AVI file to
disk.
Recently
Patrice Scribe, of Visual Basic Area 51 fame, sent me a partially finished
typelibrary to access some of the functions
in DirectShow from VB. So with this as an
incentive I may soon post a better example
for DirectShow video capture from VB which
depends on Patrice's tlb file or one of my
own (if I can ever figure out how to tweak
those massive IDL files in the DirectShow6.0
SDK). And we can also hope that MS will support VB starting
with DirectX Media 7.0 so that we lowly
VB'ers don't have to keep reinventing the
wheel with our own versions of the
typelibrary. I thought that was the whole
philosophy behind DirectShow in the first
place. I guess this philosophy has not
extended to VB (so far).
Go
to the DXVidCap download page now!
Other VideoCapture
/ VB resources
I would like
to give credit to two VBer's whose work with
the VFW API was a motivating factor for me to
do this site. Prior to seeing these two
sites, I wasn't sure whether it was
even possible to do video capture in
"straight" VB. I used to
do all my video capture development in
mixed-code environments. I would write DLLs
in C/C++ and call them from my VB front-end.
This worked fine, but was difficult to debug
and forced me to ship extra dlls with every
project. I thought about writing translations
to the declares in VFW.H so that I could call
them directly from VB, but I didn't want to
go through all that work and find that some
critical function was VB-incompatible.
When I saw
these two guys put up web sites with programs
written in straight VB, I didn't have any
more excuses. I can't say that the code on
these sites is without errors (there are
errors - be careful!), but the sample
programs seem to work, and Bantz's site has
some good articles and a great VFW-VB
listserver mailing list to go with the code.
So check these out (carefully)!
E.J. Bantz's
VideoForWindows/VB Pages
Ian Storr's
VideoForWindows/VB Downloads
Where to contact
me
If you have
comments, questions, or bug reports directly
related to the samples on this site then by
all means contact me by email at raymer@shrinkwrapvb.com. However, if you have other
questions on video capture, or functions not
covered in the samples, then please use a
more public forum so that others can benefit
too. I am a full-time developer at a Japanese company and I get too many emails already
and I usually ignore programming questions
unless they are asked in a newsgroup.
I can usually
be found hanging around the Microsoft
newsserver in the microsoft.public.vb.winapi conference. I also regularly check
and answer questions at the DevX server in
the vb.multimedia_graphics conference. See you online!
