Virtual DirectShow sources have been a long time synonym of software-only camera implementation exposed to applications along with physical cameras in a way that applications consume the sources without making a difference whether the camera is real or virtual. Vivek’s template was a starting point for many:
Capture Source Filter filter (version 0.1) 86 KB zipped, includes binaries. A sample source filter that emulates a video capture device contributed by Vivek (rep movsd from the public newsgroups). Thanks Vivek! TMH has not tested this filter yet. Ask questions about this on microsoft.public.win32.programmer.directx.video.
(02-Dec-2020 update: the sample is no longer hosted at its original location, I put a copy into GitHub repository)
With API changes over years, the sample and the concept is still understood as the method of adding a virtual camera, however new scenarios exist where the concept no longer works. Typical problems:
- 64-bit applications cannot consume virtual 32-bit virtual sources
- Virtual sources are no visible and accessible to applications consuming video using Media Foundation API
The diagram below explains the applicability of virtual cameras:
Important is that virtual sources can only be consumed by the DirectShow-based applications of the same bitness.
If source developer needs to synchronize virtual source throughout multiple applications (e.g. video is synthesized by another application and needs to be deliverable to multiple clients), he needs to add interprocess synchronization on the backyard of virtual source.
If developer needs to support both 32- and 64-bit apps, he needs both variants of virtual sources registered, and possibly synchronization of the kind of the paragraph above.
The only virtual device which is visible to all video capture applications if implemented by kernel level driver (implementations are rare but exist).
See also: